1. What’s a Project? AD642

2. Copyright 2011 John Wiley & Sons, Inc. Why the Emphasis on Project Management? 2 ❑ Many tasks do not fit neatly into business-as-usual ❑ Organizations need to assign responsibility and authority for the achievement of their goals

3. Copyright 2011 John Wiley & Sons, Inc. Characteristics of Projects 3 ❑ Unique ❑ Specific deliverables ❑ Specific due date

4. Copyright 2011 John Wiley & Sons, Inc. Other Common Characteristics of Projects 4 ❑ Multidisciplinary ❑ Complex ❑ Often involve conflicts ❑ Part of programs

5. Definition of a Project “A project is a temporary endeavor undertaken to create a unique product or service.” Project Management Institute, 2007

6. Definition of Project Management 6 “The application of knowledge, skills, tools, and techniques to a broad range of activities in order to meet the requirements of a particular project.” Project Management Institute 2007

7. Why Do We Do Projects?

8. The Triple Constraint

9. A more realistic view

10. And even more so…

11. Copyright 2011 John Wiley & Sons, Inc. The Life Cycle of Projects 11 ❑ All organisms have a life cycle (i.e., they are born, grow, wane, and die) … and so do projects ❑ Some projects follow an S-shaped curve … they start slowly, develop momentum, and then finish slowly ❑ Other project follow a J-shaped curve … they start slowly, proceed slowly, and then finish rapidly

12. PMBOK Process Groups ● PMI describes the project lifecycle in five groups ● Initiating ● Planning ● Executing ● Monitoring and controlling ● Closing

13. Initiating ● Defining a new project ● Developing charter ● Identifying stakeholders ● Obtaining authorization

14. Planning ● Scope ● Requirements analysis ● Work Breakdown Structure ● Define activities and milestones ● Estimate resources and duration ● Develop project schedule and budget

15. Executing ● Manage the project ● Perform quality assurance ● Manage stakeholders ● Manage team

16. Monitoring and Controlling ● Change management ● Monitor actuals and baseline ● Scope ● Budget ● Schedule ● Risk management

17. Closing ● Obtain acceptance ● Post-project audit ● Document and archive

18. Initiating a project: SOW ● Projects typically start with a Statement of Work ● Describes the business need ● Has fairly broad scope ● Overall strategic plan ● SOW is often part of the response to an RFP when a third party is to be involved

19. Business case ● Part of the SOW ● The justification for the project ● Might contain competitive analysis, high-level ROI, opportunities for market expansion, regulatory requirements, and more

20. SOW signoff ● A signed SOW is the document that kicks off a project ● In third-party arrangements (such as consulting) it is a contract ● Information from the SOW is used to develop the Project Charter

21. Time for Meetings! ● Once a SOW has been signed, the project formally exists ● If a PM hasn’t been involved yet, now is the time ● Initial meetings are to help the PM understand the project, the players, and the resources ● No project plan yet ● A kickoff meeting introduces all the players

22. Initial Project Coordination and the Project Charter ● Early meetings are used to decide on participating in the project ● Used to “flesh out” the nature of the project ● Outcomes include: ● Technical scope ● Areas of responsibility ● Delivery dates or budgets ● Risk management group

23. Outside Clients ● When it is for outside clients, specifications cannot be changed without the client’s permission ● Client may place budget constraints on the project ● May be competing against other firms

24. Project Charter Elements ● Purpose ● Objectives ● Overview ● Schedules ● Resources ● Personnel ● Risk management plans ● Evaluation methods

25. Cut the Red Wire… ● But first… ● The SOW might (and often does) contain language that provides for a period of analysis and prototyping ● It isn’t always clear what approach should be taken to solve a problem ● It’d be a waste of time to plan a project and then realize that the approach was wrong ● More than one prototype might be developed 25

26. …After Cutting the Blue Wire ● Even before the prototype there might be a period of high-level requirements gathering ● These are often two-pronged ● Business requirements ● Technical requirements ● The requirements analysis drives the prototyping phase, which leads to a proposal, which THEN can be developed into a more robust project plan ● In an RFP/RFQ environment, the SOW might cover only work to this point, and competing groups would present proposals to win the work 26

27. Starting the Project Plan: The WBS ● Once the high-level requirements and prettying are complete we can start to think about the work ● From a PM perspective we need to understand ● What is to be done ● When it is to be started and finished ● Who is going to do it

28. WBS Constraints ● Some activities must be done sequentially ● Some activities may be done simultaneously ● Many things must happen when and how they are supposed to happen ● Each detail is uncertain and subjected to risk

29. Hierarchical Planning ● Major tasks are listed ● Each major task is broken down into detail ● This continues until all the activities to be completed are listed ● Need to know which activities “depend on” other activities ● There’s no time or resource against these yet

30. The Work Breakdown Structure (WBS) ● A hierarchical planning process ● Breaks tasks down into successively finer levels of detail ● Continues until all meaningful tasks or work packages have been identified ● These make tracking the work easier ● Need separate budget/schedule for each task or work package

31. A Visual WBS

32. Steps to Create a WBS 1. List the task breakdown in successive levels 2. Identify data for each work package 3. Review work package information 4. Cost the work packages 5. Schedule the work packages 6. Continually examine actual resource use 7. Continually examine schedule

33. Human Resources ● Useful to create a table that shows staff needed to execute WBS tasks ● One approach is a organizational breakdown structure ● Organizational units responsible for each WBS element ● Who must approve changes of scope ● Who must be notified of progress ● WBS and OBS may not be identical

34. The Responsibility (RACI) Matrix ● Another approach is the Responsible, Accountable, Consult, Inform (RACI) matrix ● Also known as a responsibility matrix, a linear responsibility chart, an assignment matrix, a responsibility assignment matrix ● Shows critical interfaces ● Keeps track of who must approve what and who must be notified

35. Sample RACI Matrix

36. Agile Project Planning and Management ● When scope cannot be determined in advance, traditional planning does not work ● Agile project management was developed to deal with this problem in IT ● Small teams are located at a single site ● Entire team collaborates ● Team deals with one requirement at-a-time with the scope frozen

37. Interface Coordination Through Integration Management ● Managing a project requires a great deal of coordination ● Projects typically draw from many parts of the organization as well as outsiders ● All of these must be coordinated ● The RACI matrix helps the project manager accomplish this

38. Bottom line ● For a PM to succeed, it’s crucial for them to be involved as early as possible in the project lifecycle ● The reality is that PMs are often brought in well after the WBS and scheduling is complete ● It’s up to the PM to carefully balance the triple or quad constraints with the expectations of the stakeholders