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

2. Chapters 4 and 5 2 INFO 420 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. Chapters 4 and 5 3 INFO 420 Organizational structures There are three main ways to organize people  Functional  Project-based  Matrix None are strictly ‘better’ or ‘worse’ than the others

4. Chapters 4 and 5 4 INFO 420 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. Chapters 4 and 5 5 INFO 420 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. Chapters 4 and 5 6 INFO 420 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. Chapters 4 and 5 7 INFO 420 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. Chapters 4 and 5 8 INFO 420 Project organization Advantages include  Clear authority and responsibility  Improved communication  Better team integration

9. Chapters 4 and 5 9 INFO 420 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. Chapters 4 and 5 10 INFO 420 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. Chapters 4 and 5 11 INFO 420 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. Chapters 4 and 5 12 INFO 420 Matrix organization Advantages include  High level of integration across functional areas  Improved communication  Increased project focus

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

14. Chapters 4 and 5 14 INFO 420 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. Chapters 4 and 5 15 INFO 420 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. Chapters 4 and 5 16 INFO 420 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. Chapters 4 and 5 17 INFO 420 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. Chapters 4 and 5 18 INFO 420 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. Chapters 4 and 5 19 INFO 420 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. Chapters 4 and 5 20 INFO 420 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?

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

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

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

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

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

27. Chapters 4 and 5 27 INFO 420 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. Chapters 4 and 5 28 INFO 420 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. Chapters 4 and 5 29 INFO 420 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. Chapters 4 and 5 30 INFO 420 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?

31. Chapters 4 and 5 31 INFO 420 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. Chapters 4 and 5 32 INFO 420 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

33. Chapters 4 and 5 33 INFO 420 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 herehere

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