SW Project Management Organization and Scope

1. SW Project ManagementOrganization and Scope INFO 420 Glenn Booker Chapters 4 and 5

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. Chapters 4 and 5

3. Organizational structures • There are three main ways to organize people • Functional • Project-based • Matrix • None are strictly ‘better’ or ‘worse’ than the others Chapters 4 and 5

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. Chapters 4 and 5

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 Chapters 4 and 5

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 Chapters 4 and 5

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 Chapters 4 and 5

8. Project organization • Advantages include • Clear authority and responsibility • Improved communication • Better team integration Chapters 4 and 5

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”) Chapters 4 and 5

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’ Chapters 4 and 5

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 Chapters 4 and 5

12. Matrix organization • Advantages include • High level of integration across functional areas • Improved communication • Increased project focus Chapters 4 and 5

13. Matrix organization • Disadvantages include • High potential for conflict among managers • Poor response time if there are resource conflicts Chapters 4 and 5

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 Chapters 4 and 5

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? Chapters 4 and 5

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 Chapters 4 and 5

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 Chapters 4 and 5

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 Chapters 4 and 5

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 Chapters 4 and 5

20. 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? Chapters 4 and 5

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 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 Chapters 4 and 5

22. 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 Chapters 4 and 5

23. 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! Chapters 4 and 5

24. 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 Chapters 4 and 5

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 Chapters 4 and 5

26. 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 Chapters 4 and 5

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 Chapters 4 and 5

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? Chapters 4 and 5

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 Chapters 4 and 5

30. 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? Chapters 4 and 5

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? Chapters 4 and 5

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 – can’t get a handle on the scope of the product Chapters 4 and 5

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 Chapters 4 and 5

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 Chapters 4 and 5