The University of California Berkeley Extension X470 Project Management Lisa Bausell

1. The University of California Berkeley Extension X470 Project Management Lisa Bausell

2. X470 Project Management 1 Project Management Introduction Project Initiation 2 Project Planning Scope Workflow 3 Project Planning Resources Finalization 6 Project Management Review Presentations 4 Project Baseline Monitor & Control 5 Project Reporting & Communication Closure

3. Review Critical path shows you the forward pass backwards pass difference is ________ RACI = R, A, C, I, You can only have 1 person as ___

4. Review Risks Basic project risk management requires: • Identifying risks • Prioritizing risks through qualitative analysis • Probability, Impact = risk register • Responding to significant risks

5. Example Project Risks Schedule risks: • Critical path activities with long durations • Interfaces with other projects... Resource risks: • Loss of contributors with unique skills • Work requiring remote (or unknown) resources... Scope risks: • Activities requiring new, untried processes • Technical and performance challenges... General risks: • Communications problems • Reorganizations, loss of sponsorship...

6. Risk Probability Risks are associated with uncertain, future events. • Estimates of probability (likelihood) are between 0% and 100%. • Probabilities may be assessed as percentages or percentage ranges. Qualitative probability ranges (such as H/M/L) are generally sufficient for rank-ordering risks.

7. Risk Impact Impact estimates the consequences for your project, should the risk occur. • Impact may be assessed as ranges or categories of impact to one or more project objective parameters, or as estimates of time lost, money spent, extra effort, or other impact. • Impact measures may have no upper bound. Qualitative assessment based on defined categories is generally sufficient for rank-ordering risks, such as: • High: Threatening the project objective • Medium: Requiring significant replanning • Low: A nuisance

8. Example Risk Register Probability (H/M/L) Impact (H/M/L) Overall Risk Risks Software expert unavailable H M HM Contractor Incompetent M M M Purchased component late H M L ML Software development too slow M L Test gear not available L L L “Overall Risk” combines the estimates for probability and impact, and is used to rank order the risk register’s list.

9. Risk Responses Brainstorm responses to risks, considering: • Avoidance (Replan project to remove the risk) • Mitigation (Revise plans to lower risk probability and/or impact) • Transfer (Shift all or part of risk impact to others) • Acceptance (Leave plans unchanged, but monitor the risk, and where appropriate, establish contingency plans for recovery.)

10. Project Risk Responses • Identify specifics, not just general risks. • List the “Top 10”—Keep risks visible. • Document contingency plans. • Assign triggers and owners. • Plan responses to all big risks and document all risks. • Assess project size (effort months). • Establish project contingency reserves, based on risk (time and/or budget). Risks: 1. Key staff leaves 2. Earthquake 3. Test Failure

11. Team Project Opening a new restaurant in San Francisco • Do a basic WBS (4 by 3 at least) • Determine top risks • Complete Risk Register • Share with the class

12. Project Baseline and Execution • Negotiate Project Changes • Develop Schedule • Set the Project Baseline • Direct and Manage Project Execution

13. Negotiate Project Changes If you have a plan that is consistent with the project objective, commit to the project and use it. If your plans fail to meet the project objective, propose several project options, with a recommendation, to your sponsor. For example: • Adjust the deadline • Increase the budget • Reduce the scope or deliver it in phases • Improve (or train) resources • Make other project changes Negotiate agreement on a realistic, plan-based project with your sponsor and key stakeholders.

14. Adjust Project Plans Use project information: • High-level charter and summary of objectives • High-level WBS and summary project schedule • Assessment of resource requirements and capacities • Major assumptions and risks Knowledge is power. Use project information to clearly show what is and is not feasible, and use fact-based, principled negotiation to avoid “the impossible project.”

15. Develop Schedule “Analyze activity sequences, durations, resource requirements, and schedule constraints to create the project schedule.” (PMBOK 6.5) “Develop Schedule” is a process that permeates project planning, using progressive elaboration. When finalizing your planning efforts, collect your results to produce a credible, workflow-based schedule for your project.

16. Assemble Project Documents Project definition documents • Project Charter • Requirements, constraints, assumptions, and priorities • Staffing roster Project planning documents • WBS, schedule, resource plans, and risk register • Quality, communications, procurement and other ancillary plans Project status documents: • Status reports • Change logs, issue reports, and project reviews

17. Set the Project Baseline • Get sponsor and stakeholder approval • Freeze project specifications • Initiate change control • Set the baseline in computer scheduling tool • Publish and distribute approved plans

18. Sponsor and Stakeholder Approval Validate your project plans. Sponsor (Customers/Stakeholders) Project Plan Plan Objectives Project Manager/ Team

19. Freeze Project Specifications Project deadlines, resource commitments, and scope are linked. For your baseline plan, (or at a minimum for the upcoming phase of work), clearly document the specific scope requirements that are “In Plan” and define the project Statement of Work (SOW).

20. Initiate Change Control Gain agreement on a sufficiently formal change control process: • Log and publicly document all change requests. • Identify who will be responsible for change management decisions. • Determine how to analyze all proposed changes. • Establish criteria for accepting, rejecting or deferring a change; reject most of them. • Communicate and document status of all requested changes.

21. Scheduling Tool Baseline If using a computer scheduling tool, lock the baseline schedule in the tool’s database. Begin tracking all activities and using the tool to highlight all variances.

22. Publish and Distribute Plans Inform all stakeholders of the details of the project baseline decisions. Store all project baseline documents in a public “Project Management Information System” (PMIS) that is easily assessed by all project team members and stakeholders.

23. Project Executing (PMBOK)

24. Direct and Manage Project Execution “Perform the work defined in the project management plan to achieve the project’s objectives.” (PMBOK 4.3) Execution prerequisites: • Baseline validated • Communications ready • Tools on-line • Committed staffing and funding • PMIS available to all stakeholders

25. Project Execution Decisions Finalize and document: • Frequency and methods for collecting status • Frequency and types of reporting • Frequency of meetings • Practices for storing project information • Tools and systems to be used • Other significant project processes

26. Project Checkpoints For each defined project checkpoint (life cycle phase transition, cycle or iteration completion, interim scope delivery, or stage-gate), verify: • Timing • Required data and other input deliverables • Stakeholder involvement • Decisions to be made • Decision criteria • Checkpoint output deliverables

27. Project Metrics Chose metrics that: • Support overall project objectives • Positively influence team behavior • Assist good decision-making • Focus on process performance, not punishment Some typical metrics: • Critical path activity slippage • Issues opened and closed • Number of approved scope changes • Excess consumption of effort or funds • Missed milestones

28. KPI Key Performance Indicators • Scope • Budget • Schedule Define Project Status Critical path activity slippage • Green = all 3 on target • Yellow = There is an issue that might affect 1 of the 3 • Red = 1 of the three is off or there is an issue that is affecting 1

29. Project Dashboard

30. Project Dashboard

31. Project Dashboard

32. Develop a Project Dashboard • What are your KPI’s • Develop content • How do you want to present the information • Mock up a dashboard for your project

33. Project Monitoring and Control • Monitor And Control Project Work • Define and Perform Integrated Change Control • Control Scope • Control Schedule and Control Costs • Collect Status • Analyze Variances • Manage Issues and Escalate Problems

34. Monitor And Control Project Work “Track, review, and regulate the progress to meet the performance objectives defined in the project management plan.” (PMBOK 4.4) Benefits: • Real-time progress recognition • Early identification of problems while small; avoidance of later big problems • Timely communication • Reduced uncertainty and stress • Better future projects

35. Define and Perform Integrated Change Control “Perform integrated change control: Review all change requests, approve changes, and manage changes to the deliverables, organizational process assets, project documents, and project management plan.” (PMBOK 4.5) Even for “Agile” projects, success depends on understanding and limiting change based on business value.

36. Control Scope “Monitor the status of the project and product scope and manage changes to the scope baseline.” (PMBOK 5.5) Scope change management process includes: • Proposal • Analysis • Decision • Follow-up

37. Scope Change Management Process No Proposal Complete? Document Proposed Change Yes Log the Change Approved with Modifications? Approved? Analyze the Proposed Change No No Yes Yes Publicize, Document, and Implement Change Reject or Defer the Change; Communicate Resolution

38. Change Proposals Document proposed changes, including: • Description of the change • Business justification for the change, including credible estimates • Known consequences of making the change • Stakeholder support for the change

39. Assessment of Scope Changes • Log changes requested • Verify proposal information • Characterize the change • Mandatory (Analysis gap, Dependency, Problem) • Discretionary, Scope Creep • Analyze the proposed change • Benefits • Costs • Other impact

40. Disposition of Changes Evaluate all changes promptly • Reject (default) • Accept • Accept with modification • Defer

41. Change Follow-up Communicate decisions: • If rejected, document the reason. If accepted, take action: • Update planning documents • Implement accepted changes • For major changes, review and update the project baseline.

42. Status Tracking and Reporting Follow a complete tracking process each cycle: • Collect status. • Analyze variance. • Manage issues and escalate problems • Report project status. Commit to a tracking frequency (generally weekly). • Track activities from WBS. • Monitor status every cycle. • Intensify collection when needed. • Focus on schedule, cost, and other significant metrics.

43. Control Schedule “Monitor the status of the project to update project progress and manage changes to the schedule baseline.” (PMBOK 6.6) Track schedule metrics every status cycle, and respond promptly to variances from the planned baseline.

44. Control Costs “Monitor the status of the project to update the project budget and manage changes to the cost baseline.” (PMBOK 7.3) Track cost and other resource metrics every status cycle, and respond promptly to variances from the planned baseline.

45. Collect Status What has happened? (Hard data, facts and figures) • Activities, Milestones • Resources • Issues Why did it happen? (Soft data, stories) • Environment • People

46. Status Strategies Too much status information : • Information overload • Lots of work • Creates confusion Too little status information: • No information • Low effort • Creates confusion So: • Keep your process simple • Collect important data you will use • Be consistent

47. Status Collection Methods • Electronic Mail • One-on-One Discussions • Online Collection Systems • Reports and Forms • Project Office

48. Status Collection Pitfalls • Lack of Discipline / Frequency • Not Using Collected Data • Killing the Messenger • Poor Data Quality

49. Analyze Variances • Compare actual status data with the expectations of the baseline plan. • Calculate differences and identify significant variances. • Identify any trends in the project that may impact later work.

50. Variance Trends Identify: • All slippage on the critical path. • Excess consumption of money or effort. • Slippage on non-critical tasks that are similar to critical tasks later in the project. • Staff performance problems. • Other significant problems.