SW Project Management Organization and Scope

1
SW Project ManagementOrganization and Scope

• INFO 420
• Glenn Booker

2
The human side of management

• Areas involved in people issues include
• HR 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.

3
Organizational structures

• There are three main ways to organize people
• Functional
• Project-based
• Matrix
• None are strictly better or worse than the
  others

4
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.

5
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

6
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

7
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

8
Project organization

• Advantages include
• Clear authority and responsibility
• Improved communication
• Better team integration

9
Project organization

• Disadvantages include
• Project isolation from other project
• May lead to duplication of effort, reinvent wheel
• Too much attachment to the project (projectitis)

10
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

11
Matrix organization

• Several variations on the matrix exist
• Balanced 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

12
Matrix organization

• Advantages include
• High level of integration across functional areas
• Improved communication
• Increased project focus

13
Matrix organization

• Disadvantages include
• High potential for conflict among managers
• Poor response time if there are resource conflicts

14
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

15
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?

16
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

17
The Project Team

• Teams may be
• Work groups one clear leader
• Real teams more democratic, 2-12 people, skills
  mesh, commitment and accountability
• A lot more theory on team interaction has been
  developed in the last decade or so

18
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, roles, conflict resolution

19
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

20
Scope management processes

• Scope planning how it will be done
• Scope definition define it!
• Create WBS what tasks are needed to achieve the
  projects scope?
• Scope verification make sure we didnt miss
  anything
• Scope control how do we manage it?

21
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
  isnt 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

22
Scope planning

• The scope boundary defines what will support the
  projects MOV, and what will not
• Again, link back to the MOV as our focal point
• Want a brief statement of the projects scope,
  kind of an elevator summary

23
Scope planning

• Need to determine what broad functionality is or
  isnt 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!

24
Scope planning

• The scope statement can be accompanied by what
  isnt in the scope of the project
• Out of scope statements
• Both scope and out of scope statements should be
  very high level

25
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

26
Project-oriented deliverables

• Most of the projects 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

27
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

28
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?

29
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

30
Project scope verification

• This step is to make sure everyones 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?

31
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?

32
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
• Scope grope cant get a handle on the scope of
  the product

33
Scope change control

• Scope 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
• To avoid all of these problems, need a good
  change control process
• See example from the FAA here

34
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