Project Management OPER 576

1. Project Management OPER 576 Definition/Initiation Greg Magnan, Ph.D. Spring 2004

2. Session Agenda • Check-in • Initiation / Planning Phase • Team formation / Projects • Report out

3. Project Management Tradeoffs Project Priorities?

4. Project Life Cycle Stages

5. 12 Rules of PM • Thou shalt gain consensus on project outcomes • Thou shalt build the best team you can • Thou shalt develop and comprehensive and viable plan and keep it updated • Thou shalt determine the resources needed to get the project done (Source: Baker and Baker, 2000)

6. 12 Rules of PM • Thou shalt have a realistic schedule • Thou won’t try to do more than can be done • Thou will remember that people count • Thou will gain the formal and ongoing support of management and stakeholders (Source: Baker and Baker, 2000)

7. 12 Rules of PM • Thou must be willing to change • Thou must keep others informed of what you’re up to • Thou must be willing to try new things • Thou must become a leader (Source: Baker and Baker, 2000)

8. Project Initiation: Processes • Determine Project Purpose • Identifying Stakeholders / Project Team • Expectations? • Create Project Charter • Define Project Goals/Deliverables • Define Project Scope (CSSQ) • Develop Initial Project Plan • Statement of Work • Project Schedule • Determine Communications Plan • Define Project Operating Principles

9. Statement of Purpose • Why are we here? • Objectives? • Business Need • Product Family • What customer problem is being solved? • “What will this look like at the end?” • May reference business case

10. Stakeholders • Project Leader • Project Team Member • Sponsor • Grants authority • Project Customer • Resource Managers • “Manage upward” • Contractor/Supplier

11. Project Charter • “A formaldocument providing authority to a project manager to conduct a project within scope, quality, time and cost and resource constraints as laid down in the document.” • [Max Wideman Glossary]

12. Project Charter • Elements (from New York State OFT) • Background • Project Objectives & Deliverables • Critical Success Factors (CSF) • Required Resources • Constraints • Authority • Review with Sponsor AND Team

13. Deliverables • “The physical items to be delivered for a project. This may include organizationattributes, reports and plans, as well as physical products or objects.” • “Deliverables include intermediate products or services that are necessary for achieving the project’s final results. Deliverables are always measurable because they can be counted or observed in some way.” • Max Wideman’s PM Glossary • http://www.pmforum.org/library/glossary/index.htm

14. Deliverables: Criteria • Must be Specific • Must be Realistic • Must have a Time component • Must be Measurable • Must be Agreed Upon • Must identify Responsibility for achieving

15. Deliverables: Establishing • Make a list (brainstorm) • Remove those that are a step in meeting goals and not part of the “end result” [milestone?] • Ensure meet criteria • Part of THIS project? • Doable? • Written down/agreed to

16. Milestones • A point in time representing a key or important intermediate event in the life of a project. A milestone should be capable of validation by meeting all of the itemsprescribed in a defining checklist as agreed with the stakeholders. • A clearly identifiable point in a project or set of activities that commonly denotes a reporting requirement or completion of a key component (DELIVERABLE!) of a project. • Max Wideman’s Glossary

17. Scope (General) • CSSQ • Resources ($, people, supplies, equipment) • “The workcontent and products of a project or component of a project. Scope is fully described by naming all activities performed, the resources consumed and the end products which result, including quality standards. A statement of scope should be introduced by a brief background to the project, or component, and the general objective(s).” [Max Wideman’s Glossary]

18. Risk Identification • Create list • Eventually: Event (likelihood) and Impact (time or $) • Possible Drivers (NYS OFT) • culture of the Performing Organization • the level to which the end result is defined (the more complete the definition, the lower the possibility of risk) • technology used on the project (proven vs. new) • relationships among team members • impact on work units • Constraints

19. Initial Project Schedule • Estimates of Major Deliverables / Dates • Milestones • Major Tasks • Precedence Relationship • First Cut at Timeline

20. Initial Project Plan Checklist • Project Objectives / Purpose • Success Factors • Charter / Authority • Team Members • Reviews with Stakeholders • CSSQ (cost, scope, schedule, quality) • Deliverables • Milestones • Technical Requirements • Cost Estimates • Constraints • Risk Identification • Initial Project Schedule

21. II. Project Planning To organize the work / avoid future problems • Assemble Team • Determine Tasks (Work Breakdown Structure) • Assign Responsibility (Resp. Assign. Matrix) • Sequence Deliverables • Schedule Milestones / Deliverables • Schedule Resources • Identify Risks / Protect the Plan (mitigation plans)

22. II. Project Planning • Assemble Project Team / Kickoff • Who will be on the team? • Team Phases • Forming/Storming/Norming/Performing • Motivation throughout project • Kickoff Meeting • Icebreaker / Sponsor / Team contract • Inclusive / “Parking Lot” for issues • Review Charter w/ team / Feedback

23. II. Project Planning • Develop Work Breakdown Structure (WBS) • A graphic or outline depicting how major deliverables relate to sub-elements • Establish specific outputs & accomplishments • Hierarchical listing of all project elements • Lowest level detailed tasks (work packages) • Work that can be assigned to individual or group • Measurable outcome • List major Deliverables (DBS) • Enables planning, scheduling, budgeting

24. Work Breakdown Structure (WBS) • A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of project work. (PMI)

25. Work Breakdown Structure (WBS) • Involve project team in creation • Creative / Brainstorming / Post-its • “Mindmapping”…examples to follow • At lowest level, work packages should include a verb and a noun (e.g., “meet w/ customers”) • Short duration tasks that have a definite start and stop point, consume resources, and represent cost. • A control point in the project • Use a consistent level of detail throughout WBS

26. Work Breakdown Structure (WBS) • Represent work as an activity that has a tangible result • Arranged in a hierarchical structure • Has an objective or tangible result (deliverable) • Provides a graphical picture OR textual outline of the project scope • Provides the foundation for subsequently integrating the work package details and deliverables with all other aspects of the PM life cycle phases.

27. Work Breakdown Structure (WBS) • Decomposes the overall project scope in to deliverables and supports the definition of the work effort required for effective management. • Clearly and comprehensively defines the scope of the project in terms of deliverables that the project participants and stakeholders can clearly understand. • Separates the deliverable into its component parts to ensure the project plan matches the approved project scope and that unnecessary work is not included. • Supporting decomposition into simpler components, providing one of the primary methods for managing complex projects.

28. Work Breakdown Structure (WBS) • Supports planning and the assignment of responsibilities. • Assists in determining resource requirements (i.e., skills, characteristics, etc.) • Assists in tracking the status of resources allocations, cost estimates, expenditures, and performance. WBS drives the processes of Resource Planning, Cost Estimating, Cost Budgeting, Risk Management. • Facilitates REPORTING of information by either life-cycle phase, deliverable, work package or a combination of the three. Again, cost, schedule scope risk and quality perspectives can be addressed. Information can be rolled up or decomposed depending on audience. • The depth of a WBS is dependent upon the size and complexity of the project and the level of detail needed to plan and manage it.

29. WBS: How to… • Think through the entire project (divide high-level deliverables?) • Think deliverables • Think with the end in mind (how will this component contribute to the finished deliverable?) • What methods or special processes may be required? Quality methods?

30. WBS: How to… • Step 1: Identify the final product(s)—what must be delivered to achieve success. A thorough review of high-level project scope documents. • Step 2: Define a project’s major deliverables. • Step 3: Decompose major deliverables to a level of detail appropriate for management and integrated control. These WBS elements normally tie to clear and discrete identification and stand-alone deliverable products. • Step 4: review and refine the WBS until project stakeholders agree that project planning can be successfully completed.

31. WBS: Factors to Consider • Purpose of WBS is to define the project’s scope through the decomposition of deliverables. • Each WBS element should represent a single, tangible deliverable • Each WBS element should represent an aggregation of all subordinate WBS elements listed immediately below it. • Each WBS elements must belong to only one single parent (or superior) WBS element. • The deliverables should be logically decomposed to a level that represents how they should be produced

32. WBS: Factors to Consider • Deliverables must be unique and distinct from their peers • All deliverables are explicitly included in the WBS • A coding scheme for WBS elements should be used. • Eventually, all work in the WBS must be estimated, resources, scheduled, budgeted, and controlled while progress is reported. • Each WBS element should have one person responsible for its completion.

33. WBS: How Low to Go? • Is there a need to improve the accuracy of the cost and duration estimates of the WBS element? Or to precisely know the timing? • Is more than one group responsible for the element? • Does the WBS element include more than one type of work process or more than one deliverable? • Are there dependencies between deliverables within a WBS element to another WBS element? • Do resource requirements change over time within a WBS element? • Do prerequisites differ among internal deliverables within the WBS element? • Adequate for resource allocation purposes? (e.g., individual work assignments)

34. A deliverable at the lowest level of the WBS, when that deliverable may be assigned to another PM to plan and execute. This may be accomplished through the use of a sub-project where the work package may be further decomposed into activities. (PMI) Defines work (what) ID’s task duration ID the budget (WP cost) ID resources (how much) ID person responsible ID monitoring points Coding for info systems Work Packages

35. Mindmapping Examples

36. WBS Example

38. II. Project Planning • Responsibility Assignment Matrix • To make responsibilities clear and visible • WBS elements down left side • Note Deliverables • Names of individuals/groups along top • Mark Primary responsibility (P) • One for each terminal element • Negotiate commitment from each person

39. Responsibility Assignment Matrix (RAM) P=Primary resp.; S=Secondary resp.; R=Review required