SW Project Management Organization and Scope

INFO 420 Chapters 4 and 5 1

SW Project ManagementOrganization and Scope

INFO 420Dr. Jennifer Booker

Chapters 4 and 5 2INFO 420

The human side of management

Areas involved in people issues includeHR planning – when do we need what kind of

skills?Acquire project team – get them!Develop project team – additional training and

team developmentManage project team – across time zones,

outsourcing, etc.


Organizational structures

There are three main ways to organize peopleFunctionalProject-basedMatrix

None are strictly ‘better’ or ‘worse’ than the others


Functional organization

A functional organization breaks people into groups defined by their areas of technical expertiseNetworking, database, interface designers,

system architects, In a non-techie setting, might have finance,

manufacturing, marketing, sales, HR, etc.



This is good because it can provideMore flexibility in assigning people to projects

as neededMore depth of knowledge in their fieldLess duplication of resources



Disadvantages can includeUnclear authority for a given projectPoor response time to cross layers of

managementPoor 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. construction



Advantages includeClear authority and responsibility Improved communicationBetter team integration



Disadvantages includeProject isolation from other projectMay lead to duplication of effort, reinvent

wheelToo 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 existBalanced 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 includeHigh level of integration across functional

areas Improved communication Increased project focus


Matrix organization

Disadvantages includeHigh potential for conflict among managersPoor 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-basedHeavily interdisciplinary projects tend to like

matrix structuresSome studies show preference for project or

project matrix structures


Other stakeholders

The informal paths of communication (such as?) can override the formal org structureKey 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 acquisitionAlso needs many of the same skills, but in

different people! Team performance may be influenced by

its structure


The Project Team

Teams may be Work groups – one clear leaderReal 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 projectAdequate space, lighting, meeting areasTechnology (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 project’s scope? Scope verification – make sure we didn’t

miss anything 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 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


Scope planning

The scope boundary defines what will support the project’s MOV, and what will notAgain, link back to the MOV as our focal point

Want a brief statement of the project’s scope, kind of an elevator summary


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!


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


Project scope definition

As we start to define the project in more detail, we need to identify the project and product deliverablesAgain, 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 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


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 diagramThe use case diagram is from the Rational

Unified Process (RUP) and UML notationThe context diagram is a context-level data

flow diagram (DFD) You remember these from INFO 200 and

INFO 355, right?


Product-oriented scope

Many techniques can be used to develop the scope, such as Brainstorming InterviewsJAD (Joint Application Development) sessions

Try to capture scope at a consistent level of detail


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?


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?


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 occurScope grope – can’t get a handle on the

scope of the product



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 processSee example from the FAA here

http://cci.drexel.edu/faculty/gbooker/Reference/mgmt/ptr-process.doc



A good change control process includesClearly define the proposed changeVerify that the change is understoodAnalyze the change for feasibility, cost, effortApprove the change (or not) Implement and test the changeVerify change works in conjunction with other

changes before production release

Documents

SW Project Management Organization and Scope