SW Project Management Organization and Scope - PowerPoint PPT Presentation


PPT – SW Project Management Organization and Scope PowerPoint presentation | free to view - id: 17af8b-ZDc1Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

SW Project Management Organization and Scope


Disadvantages can include. Unclear authority for a given project ... Disadvantages include. Project isolation from other project ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 35
Provided by: Gle780


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SW Project Management Organization and Scope

SW Project Management Organization and Scope
  • INFO 420
  • Glenn Booker

The human side of management
  • Areas involved in people issues include
  • HR planning when do we need what kind of
  • Acquire project team get them!
  • Develop project team additional training and
    team development
  • Manage project team across time zones,
    outsourcing, etc.

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

Functional organization
  • A functional organization breaks people into
    groups defined by their areas of technical
  • Networking, database, interface designers, system
  • In a non-techie setting, might have finance,
    manufacturing, marketing, sales, HR, etc.

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

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

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.

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

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

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

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

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

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

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

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?

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

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

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

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

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
  • Scope control how do we manage it?

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

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

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!

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

Project scope definition
  • As we start to define the project in more detail,
    we need to identify the project and product
  • Again, note the project vs. product distinction
  • Project-oriented deliverables include the
    business case, project charter, project plan, and
    other project life cycle artifacts

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
  • Identify the deliverable, its form or structure,
    who approves it, and what process or quality
    standards and resources are used to create it

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

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,

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

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
  • Is the MOV supported by the scope?
  • Are deliverables complete and appropriate?

Project scope verification
  • Are suitable quality or process standards being
  • Are milestones defined for each deliverable?
  • Are the sponsor and the development team both
    clear on what is expected from them?

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

Scope change control
  • Scope creep gradual but persistent changes in
    scope, often leading to large budget and schedule
  • 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

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
About PowerShow.com