SW Project Management
Organization and Scope
INFO 420
Glenn Booker
INFO 420
Chapters 4 and 5
1
The human side of management

Areas involved in people issues include
planning – when do we need what kind of
skills?
 Acquire project team – get them!
 Develop project team – additional training and
team development
 Manage project team – across time zones,
outsourcing, etc.
 HR
INFO 420
Chapters 4 and 5
2
Organizational structures

There are three main ways to organize
people
 Functional
 Project-based
 Matrix

None are strictly ‘better’ or ‘worse’ than the
others
INFO 420
Chapters 4 and 5
3
Functional organization

A functional organization breaks people
into groups defined by their areas of
technical expertise
 Networking,
database, interface designers,
system architects,
 In a non-techie setting, might have finance,
manufacturing, marketing, sales, HR, etc.
INFO 420
Chapters 4 and 5
4
Functional organization

This is good because it can provide
 More
flexibility in assigning people to projects
as needed
 More depth of knowledge in their field
 Less duplication of resources
INFO 420
Chapters 4 and 5
5
Functional organization

Disadvantages can include
 Unclear
authority for a given project
 Poor response time to cross layers of
management
 Poor integration, since each field is isolated
INFO 420
Chapters 4 and 5
6
Project organization
Here everyone reports to a project
manager for a specific system
 Each project manager collects the people
they need for their project requirements
 Some fields are very project-oriented, e.g.
construction

INFO 420
Chapters 4 and 5
7
Project organization

Advantages include
 Clear
authority and responsibility
 Improved communication
 Better team integration
INFO 420
Chapters 4 and 5
8
Project organization

Disadvantages include
 Project
isolation from other project
 May lead to duplication of effort, reinvent
wheel
 Too much attachment to the project
(“projectitis”)
INFO 420
Chapters 4 and 5
9
Matrix organization
Cross breed them to get the matrix
organization
 Your ‘home’ base is a functional
organization, but you are assigned to
projects as they need you
 Results in reporting to multiple managers,
violating ‘unity of command’

INFO 420
Chapters 4 and 5
10
Matrix organization

Several variations on the matrix exist
matrix – the PM defines project
tasks, but functional manager determines how
they will be done
 Functional or project matrix – focuses more
on that aspect of the relationship
 Balanced
INFO 420
Chapters 4 and 5
11
Matrix organization

Advantages include
 High
level of integration across functional
areas
 Improved communication
 Increased project focus
INFO 420
Chapters 4 and 5
12
Matrix organization

Disadvantages include
 High
potential for conflict among managers
 Poor response time if there are resource
conflicts
INFO 420
Chapters 4 and 5
13
Which is best?

No unique answer, it depends on the
business culture, industry, environment,
etc.
 Consulting
firms are often project-based
 Heavily interdisciplinary projects tend to like
matrix structures
 Some studies show preference for project or
project matrix structures
INFO 420
Chapters 4 and 5
14
Other stakeholders

The informal paths of communication
(such as?) can override the formal org
structure
 Key
stakeholders in a project might have a lot
of influence over the project

May have conflicting priorities
 What
strategy or controls do you establish to
handle this?
INFO 420
Chapters 4 and 5
15
The Project Team
Project manager needs a good blend of
technical, business, and people skills
 Team selection and acquisition

 Also
needs many of the same skills, but in
different people!

Team performance may be influenced by
its structure
INFO 420
Chapters 4 and 5
16
The Project Team

Teams may be
groups – one clear leader
 Real teams – more democratic, 2-12 people,
skills mesh, commitment and accountability
 Work

A lot more theory on team interaction has
been developed in the last decade or so
INFO 420
Chapters 4 and 5
17
Project environment

The physical environment is often
overlooked in its importance to a project
 Adequate
space, lighting, meeting areas
 Technology (computer, phone, collab. tools)
 Office supplies (yes, it matters!)

And what kind of culture do you create?
 Expectations,
INFO 420
roles, conflict resolution
Chapters 4 and 5
18
Project Scope

The next major activity is to define the
scope of what the project will accomplish
 Is

this the same as the product scope?
There are five kinds of activity designed to
help define and manage project scope
INFO 420
Chapters 4 and 5
19
Scope management processes
Scope planning – how it will be done
 Scope definition – define it!
 Create WBS – what tasks are needed to
achieve the project’s scope?
 Scope verification – make sure we didn’t
miss anything
 Scope control – how do we manage it?

INFO 420
Chapters 4 and 5
20
Scope planning
Failure to define and manage the scope of
a project is almost a guarantee of failure
 Scope includes basic definitions of what is
and isn’t part of the product that will be
created, and of the project as a whole
 A scope management plan describes how
project scope will be defined & managed

INFO 420
Chapters 4 and 5
21
Scope planning

The scope boundary defines what will
support the project’s MOV, and what
will not
 Again,

link back to the MOV as our focal point
Want a brief statement of the project’s
scope, kind of an elevator summary
INFO 420
Chapters 4 and 5
22
Scope planning
Need to determine what broad
functionality is or isn’t included
 The scope ‘statement’ can be several
sentences (e.g. p. 137)
 Like the MOV, need all major stakeholders
to agree on the scope statement!

INFO 420
Chapters 4 and 5
23
Scope planning

The scope statement can be accompanied
by what isn’t in the scope of the project
 ‘Out

of scope statements’
Both scope and out of scope statements
should be very high level
INFO 420
Chapters 4 and 5
24
Project scope definition

As we start to define the project in more
detail, we need to identify the project and
product deliverables
 Again,

note the project vs. product distinction
Project-oriented deliverables include the
business case, project charter, project
plan, and other project life cycle artifacts
INFO 420
Chapters 4 and 5
25
Project-oriented deliverables
 Most
of the project’s plans, prototypes,
reports, and training materials fall into the
project deliverable category

Summarize them in a deliverable definition
table (DDT?)
 Identify
the deliverable, its form or structure,
who approves it, and what process or quality
standards and resources are used to create it
INFO 420
Chapters 4 and 5
26
Project-oriented deliverables

The deliverables can be mapped to the
project life cycle phases, using a
deliverable structure chart (DSC)
 This
could help create the WBS in the
next step
INFO 420
Chapters 4 and 5
27
Product-oriented scope

The high level product scope is typically
captured in a use case or context diagram
 The
use case diagram is from the Rational
Unified Process (RUP) and UML notation
 The context diagram is a context-level data
flow diagram (DFD)

You remember these from INFO 200 and
INFO 355, right?
INFO 420
Chapters 4 and 5
28
Product-oriented scope

Many techniques can be used to develop
the scope, such as
 Brainstorming
 Interviews
 JAD

(Joint Application Development) sessions
Try to capture scope at a consistent level
of detail
INFO 420
Chapters 4 and 5
29
Project scope verification
This step is to make sure everyone’s in
agreement on the project and product
scopes
 Review with the sponsor and other key
stakeholders

 Is
the MOV supported by the scope?
 Are deliverables complete and appropriate?
INFO 420
Chapters 4 and 5
30
Project scope verification
 Are
suitable quality or process standards
being used?
 Are milestones defined for each deliverable?
 Are the sponsor and the development team
both clear on what is expected from them?
INFO 420
Chapters 4 and 5
31
Scope change control
Every project will incur changes in scope
 Therefore it is wise to have a process for
controlling those changes
 Otherwise, any or all of three problems
can occur

grope – can’t get a handle on the
scope of the product
 Scope
INFO 420
Chapters 4 and 5
32
Scope change control
creep – gradual but persistent changes
in scope, often leading to large budget and
schedule problems
 Scope leap – huge sudden changes in scope,
completely changing the intent of the project
 Scope

To avoid all of these problems, need a
good change control process
 See
INFO 420
example from the FAA here
Chapters 4 and 5
33
Scope change control

A good change control process includes
 Clearly
define the proposed change
 Verify that the change is understood
 Analyze the change for feasibility, cost, effort
 Approve the change (or not)
 Implement and test the change
 Verify change works in conjunction with other
changes before production release
INFO 420
Chapters 4 and 5
34