1. PROJECTMANAGEMENT SUMMER SEMINAR 2010

2. Project management - Summer seminar 20102 Presentations Your trainer Presentation of each participant Structure of the training Timetable

3. Project management - Summer seminar 20103 Training structure Definitions Workshop 1: Project problems Initiating Workshop 2 : Creating the charter Planning Workshop 3: Deliverables & WBS Workshop 4 Risk Management Workshop 5 Deliverables schedule Execution Workshop 7 NASA Control Workshop 9 Reaction to changes General Workshop 10 Lessons learned (individual)

4. Project management - Summer seminar 20104 Part 1 - Definitions 1.1. A project is… 1.2. Project management is… 1.3. Project Management framework 1.3.1. Project Management Context 1.3.2. Project Management Processes 1.3.3. Project Management Practices

5. Project management - Summer seminar 20105 1.1. A Project Is… WORK !

6. Project management - Summer seminar 20106 1.1. A Project Is… WORK ! Processes Projects Temporary Unique Scope Uncertain Critical (Often) On going Repetitive Limited resources Planned Executed Controlled People

7. Project management - Summer seminar 20107 A project is a temporary endeavor undertaken to create a unique product, service or result. Often critical to the business, it always implies uncertainty, for its scope is progressively elaborated (Source: PM Body of Knowledge) 1.1. A Project Is…

8. Project management - Summer seminar 20108 1.2. Project management is … Project Meet expectations Project Management Competing Knowledge, skills, tools, techniques Stakeholders (Un)identified requirements Scope TimeCost Quality Find optimal balance Constraint => Project Manager’s challenge

9. Project management - Summer seminar 20109 1.3. The PM Framework 1.3.1. Project Management Context:  Project Phases & the Project Life-Cycle  Project Stakeholders  Organizational Influences 1.3.2. Project Management Processes:  All activities a Project Manager has to perform in order to describe, organise and complete the work of the project  PM Processes are organised into 5 Process Groups 1.3.3. Project Management Practices:  For each PM process, methods are available that reflect best practices in project management; Understanding project management

10. Project management - Summer seminar 201010 1.3.1 The project management context Project Phases & Lifecycle Sample project lifecycle

11. Project management - Summer seminar 201011 Phase : Why breaking down into phases ? Manageability – killpoints Each project phase is marked by completion and approval of deliverables review of project performance to date Prior to starting the next phase, the business case is (well, should be) re-validated to (re-) confirm project continuation 1.3.1 The project management context Project Phases & Lifecycle

12. Project management - Summer seminar 201012 This is the LIFE cycle, specific to the project type: IT, roll-out, facilities management. The management cycle is the same for any type of project and comes in addition to the life cycle: 1.3.1 The project management context Project Phases & Lifecycle

13. Project management - Summer seminar 201013 Typical Stakeholders: End user (client) Team Managers Steering Committee (Project Board) Performing organisation Project Manager Project Team members Government … Project stakeholders = individuals and organizations that are actively involved in the project whose interests may be positively or negatively affected as a result of project execution or completion that may also exert influence over the project and its results. 1.3.1 The project management context Project Stakeholders

14. Project management - Summer seminar 201014 What are the four main actors ? 1.3.1 The project management context Project Stakeholders

15. Project management - Summer seminar 201015 Roles & Responsibilities Sponsor Align project with strategy Involve in Business case/Charter Represents “hierarchy” for the whole project Customer Express requirements Involve in Reviews, Approvals Work on understanding impacts of change Project leader Communication between all actors Involve in all Project Management steps Give guidance Team member Report to Project leader + Supervisor Involve in Execution + control of the Project Show Project oriented attitude 1.3.1 The project management context Project Stakeholders

16. Project management - Summer seminar 201016 Projects are influenced by the performing organization Organizational Systems –Operations are project-based (e.g. Architects) vs. non-project- based (e.g. manufacturing) Organizational Culture and Style –Participative vs. Hierarchical –Risk Taking vs. Risk Averse Organizational Structure (!!) –From Functional to Projectized 1.3.1 The project management context Project Stakeholders

17. Project management - Summer seminar 201017 Influences From Organizational Structure

18. Project management - Summer seminar 201018 1.3.2. The Project Management Processes Each project (or phase) is managed going through the complete project management processes 12 43 5 All activities a Project Manager has to perform in order to describe, organize and complete the work of the project can be organized into 5 process groups Note: project management is an iterative endeavour. An action (or failure to take action), in one area will usually affect other areas.

19. Project management - Summer seminar 201019 Each project (or phase) is managed going through the complete project management processes Initiating Defines and authorizes the project (phase) Controlling Measure & monitors progress to identify variances from the project plan so that corrective actions can be taken when necessary to meet the project objectives Closing Formalizes acceptance of the final deliverables and brings the project (phase) to an orderly end Execution Integrate people and other resources to carry out the project plan Planning Refine objectives and create plan required to attain the project objectives and scope 12 43 5 1.3.2. The Project Management Processes

20. Project management - Summer seminar 201020 Project Charter Project Plan Work Breakdown Structure Deliverables, status Change Requests Approved Change Requests Project Performance Reports Initiating Planning Execution “Business Case” Controlling Closing Accepted Deliverables Project Performance Project Deliverables Lessons Learned 1.3.2. The Project Management Processes

21. Project management - Summer seminar 201021 1.3. The PM Framework 1.3.1. Project Management Context:  Project Phases & the Project Life-Cycle  Project Stakeholders  Organisational Influences 1.3.2. Project Management Processes:  All activities a Project Manager has to perform in order to describe, organise and complete the work of the project  PM Processes are organised into 5 Process Groups 1.3.3. Project Management Practices:  For each PM process, methods are available that reflect best practices in project management;  PMI has grouped these best practices into 9 knowledge areas

22. Project management - Summer seminar 201022 1.3.3 Project Management Practices Knowledge areas (results + means) I. RESULTS Scope : ensure that the project includes all the work required, and only the work required, to complete the project successfully Time : ensure timely completion of the project Cost : ensure that the project is completed within the approved budget Quality : ensure that the project will satisfy the needs for which it was undertaken

23. Project management - Summer seminar 201023 II. MEANS Integration management : ensure that the various elements of the project are properly coordinated Human resources : make the most effective use of the people involved in the project Communication : ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information Risk : Identify, analyze, and respond to project risk Procurement : acquire goods and services from outside the performing organization 1.3.3 Project Management Practices Knowledge areas (results + means)

24. Project management - Summer seminar 201024 Workshop 1 – Project problems How –In groups Time –15 minutes What –Brainstorm 10 minutes on the problems you encounter in your projects –Be specific –Select your top ten list and put them on the flipchart

25. Project management - Summer seminar 201025 Part 2 - Initiating (creating successful projects) 2.1. A successful project 2.2. Business Case 2.3. From the Business Case to the charter 2.4. The project charter 2.5. Kick-off meeting (Go / No go)

26. Project management - Summer seminar 201026 2.1. What is a successful project Customer Deliverables Budget & Staffing Skills & knowledge Lessons learned SATISFIED ON TIME INCREASE BENEFITS RESPECTED Example

27. Project management - Summer seminar 201027 2.2. “Business Case” - contents 1.Introduction Subject: What is the business case about? Purpose: What will the business case be used for? Motivation: Objectives, opportunities, threats, problems,... 2.Business Impacts Cash flow projections Financial indicators (NPV, IRR & Payback) Non-financial impacts + rationales (strategic alignment, contributions to business objectives) 3.Sensitivity, Risks and Contingencies Sensitivity analysis: which assumptions are important in determining results? Risk analysis: How likely are the projected and other results? Which factors must be watched? Contingency analysis: Which factors must be managed? 4.Conclusions and recommendations Choice of scenario(s) for action 5.Signature Reviewed by authorized executive

28. Project management - Summer seminar 201028 2.3. From Business Case to Project Charter Stakeholders Objectives scope, accept Organize team Plan milestones Estimate cost Kick-off Approved Project Charter Write-up project charter Risk analysis Business Case

29. Project management - Summer seminar 201029 2.4. Project charter : the main deliverable Main deliverable of initiation the project charter Explains what is to be done, why and by whom Needs to be high level Should be written by the project sponsor Is quite often written by the project manager Should be signed off by the sponsor

30. Project management - Summer seminar 201030 2.4. Project charter : contents A.Project scope and objectives B.Customers Acceptance Criteria C.Stakeholders and project team D.Reviews and approvals E.Reports F.Risk limits G.Deadlines H.Costs & Spending I.Constraints & Priorities

31. Project management - Summer seminar 201031 2.5. Kick off meeting Purpose To make sure project manager and project executive have the same expectations for this project. To formalize project start. Objectives Obtain formal approval (signature) of the project charter by the project executive. Approach Go through the project charter with project executive and other key stakeholders. Take enough time to clarify anything that is not clear! Work through points for decision-making. Make sure the project executive understands and agrees upon what is stated in the project charter

32. Project management - Summer seminar 201032 Workshop 2 – Charter How –In groups Time –20 minutes What –Complete the charter

33. Project management - Summer seminar 201033 Part 3 - Planning 3.1. Project management plan – What ? 3.2. Project management plan - content 3.2.1. Scope definition 3.2.2. WBS 3.2.3. Risk management 3.2.4. Scheduling 3.2.5. Cost estimating 3.2.6. Communication plan

34. Project management - Summer seminar 201034 3.1. What is the Project Management plan ? Project Management Plan Document used to manage and control project execution Describes the project management procedures ≠ Project Schedule ≠ Project Charter Charter = mainly for Project Board/Sponsor/Customer/… Plan = mainly for Project Team Project Planning is an iterative process Project plan change(s) over time. It will guide the team throughout the project Devising and maintaining a workable scheme to accomplish the business need that the project was undertaken to address - a Project Management Plan

35. Project management - Summer seminar 201035 3.2. Building the Project Management plan Scope definition Project Charter Scheduling Cost budgeting Risk mgmt. Org. & Comm. Planning Project Plan

36. Project management - Summer seminar 201036 3.2.1. Scope Definition Define the work that must be done in this project. - TOP DOWN PLANNING - Scope Definition is the process of progressively elaborating and documenting the project work (project scope) that produces the product Inputs are –Project Charter –(Approved Change Requests) Outputs are –Work Breakdown Structure –Additional project details

37. Project management - Summer seminar 201037 A deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. Subdivide the work of the project into more manageable pieces of work: Components (e.g. HW, SW, Training,...) Deliverables (e.g. 100 PC’s, Training manual,...) Work Packages at the lowest level of the WBS can be: Scheduled Cost estimated Monitored and controlled Work Packages Components DC B A Project 3.2.2 The WBS as a scope definition device

38. Project management - Summer seminar 201038 Practical tips for the WBS 1st level should be project phase unless the project is very large and subdivided into subprojects Always include Project Management as a separate branch Work packages at lowest level should have one clearly identifiable responsible within the organization Not too many levels (5 would be a maximum) Work packages must be not too big not too small Not 1 or 2 hours Not much more than 10 to 20 days Not fully detailed – rolling wave/planning horizon Kerzner says good sign is 0,5 to 2,5% of total project (See other related topics in the training) 3.2.2 The WBS as a scope definition device

39. Project management - Summer seminar 201039 EXAMPLE 3.2.2 The WBS as a scope definition device

40. Project management - Summer seminar 201040 3.2.2. Workshop 3 – WBS How In groups Time 15 minutes What See Workshop document

41. Project management - Summer seminar 201041 3.2. Building the Project Management plan Scope definition Project Charter Scheduling Cost budgeting Risk mgmt. Org. & Comm. Planning Project Plan

42. Project management - Summer seminar 201042 3.2.3. Risk - PMBOK definition uncertain effect A risk is an uncertain event or condition that, if it occurs, has positive or negative effect on at least one project objective, such as time, cost, scope or quality. We are not sure whether it will occur or not It has one or more causes and one or more impacts on time, cost, scope or quality Risks could be a threat or an opportunity e.g. uncertainty whether or not a newly hired resource will fit in the team

43. Project management - Summer seminar 201043 3.2.3. Risk Management Defined “Risk management is a systematic approach to evaluate uncertainty, isolate the critical ones, and formulate cost effective methods for minimizing those uncertainties and, thus, is an essential element of a complete and effective project management approach” (Effective Risk Management for Project Managers, Nghi M. Nguyen, PMI - Risk Management Newsletter Sept 99)

44. Project management - Summer seminar 201044 3.2.3. Risk Management Processes Risk management planning Risk identification Risk analysis Risk response planning

45. Project management - Summer seminar 201045 3.2.3. Risk Management Planning Risk Management Methodology Decide/choose approaches, tools and data sources Definition of Roles and Responsibilities Define lead, support and risk management team membership for each type of activity in the RM plan Assign people to the roles Clarify responsibilities Budgeting Assign resources and estimate costs for risk management To include in the cost baseline Timing of risk management activities When and how often will the activities take place, i.e. actual timing and dates To include in the project schedule

46. Project management - Summer seminar 201046 3.2.3. Risk Planning output At global or project level: Risk categories Definitions of risk probability and impact Tailor the general levels of Probability and Impact to the project: PI-scoring system PI Matrix Matrix used to prioritize risks Revised stakeholders’ tolerances Reporting formats Tracking How will all facets of risk activities be recorded? Whether and how RM processes will be audited

47. Project management - Summer seminar 201047 3.2.3. Risk Identification Talk with the project stakeholders interviews, brainstorming,… Review the project documents use of checklists, diagramming techniques, … Each participant to the project can identify risks and have them added to a risk register (templates can/should be provided to them) Open Issues Questions we currently cannot answer. Decisions Selection of one alternative amongst many, without necessarily having all required information at hand. Assumptions Things we take for granted that need to be in place in order for this project to succeed. How to find risks? What to do?What to look for?

48. Project management - Summer seminar 201048 3.2.3. Risk Identification - example

49. Project management - Summer seminar 201049 3.2.3. Risk Planning Processes Risk management planning Risk identification Risk analysis Risk response planning

50. Project management - Summer seminar 201050 3.2.3. Basic Risk Analysis The severity of any risk can be defined in terms of: impact - the effect that a risk will have on the project if it occurs. probability - the extent to which the risk effects are likely to occur. Risk Severity (exposure) = f (impact, probability)

51. Project management - Summer seminar 201051 3.2.3. Typical risk scale P-I Scoring system

52. Project management - Summer seminar 201052 3.2.3. P-I Matrix VHI 0,050,090,180,360,72 HI 0,040,070,140,280,56 MED 0,030,050,100,200,40 LO 0,020,030,060,120,24 VLO 0,01 0,020,040,08 VLO LO MEDHIVHI Impact Probability < 0,08 = Low 0,08 – 0,21 = Medium > 0,21 = High Thresholds

53. Project management - Summer seminar 201053 3.2.3. Risk Priority Number (RPN) RPN = P x I x D, where P = probability I = Impact D = Detectability (D is a numerical subjective estimate of the effectiveness of the controls to prevent or detect the cause or failure mode before the failure reaches the customer)

54. Project management - Summer seminar 201054 3.2.3. RPN versus Risk score

55. Project management - Summer seminar 201055 3.2.3. Risk Planning Processes Risk management planning Risk identification Risk analysis Risk response planning

56. Project management - Summer seminar 201056 3.2.3. Risk Response Planning Risk responses are planned: Appropriately to the severity Which severity is going to be taken into account Cost effectively in meeting the challenge The response cannot cost more than the risk Timely Occurrence AND countermeasure should be timelined Realistically within the project context Changing the whole management staff of the company might NOT be an option Agreed upon by all involved parties Executive management must approve countermeasures Owned by somebody (a named person) taking the responsibility to monitor the evolution of the risk and the implementation of the countermeasure

57. Project management - Summer seminar 201057 3.2.3. Risk Response Planning Avoidance: changing the project plan to eliminate the risk or to protect the project objectives from its impact Transfer: seeking to shift the consequence of a risk to a third party together with ownership of the response (e.g. insurance) Mitigation: seeking to reduce or prevent the probability and/ or consequences of an adverse risk event to an acceptable threshold Acceptance: indicating that the project team has decided not to change the project plan to deal with a risk or is unable to identify any other suitable response strategy Passive acceptance Active acceptance (with contingency plan) Response Strategies

58. Project management - Summer seminar 201058 3.2.3. Risk management - Decision framework

59. Project management - Summer seminar 201059 3.2.3. Types of decisions Accepting or rejecting a proposal or project Selecting from a set of non-mutually exclusive alternatives Selecting the best decision from a set of mutually exclusive alternatives Choosing a best decision strategy when a sequence of choices and chances events may occur

60. Project management - Summer seminar 201060 3.2.3. Decisions involving a single alternative Net present value (NPV) Internal rate of return (IRR) Expected Monetary Value (EMV)

61. Project management - Summer seminar 201061 3.2.3. Decisions involving non-mutually exclusive alternatives Ranking criteria Return on investment (ROI) ROI = Annual cashflow/Initial investment Cost/benefit ratios Expected Monetary Value (EMV)

62. Project management - Summer seminar 201062 3.2.3. Decisions involving non-mutually exclusive alternatives Scoring models Multi-attribute utility (MAU) models Analytic Hierarchy Process (AHP)

63. Project management - Summer seminar 201063 3.2.3. Decision making under uncertainty List alternative courses of action List possible events or outcomes or states of nature Determine “payoffs” Associate a payoff with each course of action and each event pair Adopt decision criteria Evaluate criteria for selecting the best course of action

64. Project management - Summer seminar 201064 3.2.3. List Possible Actions or Events Two methods of listing : Pay-off table Decision tree

65. Project management - Summer seminar 201065 3.2.3. Pay-off table Consider a food vendor determining whether to sell soft drinks or hot dogs. xij = payoff (profit) for event i and action j

66. Project management - Summer seminar 201066 3.2.3. Decision Tree Food Vendor Profit Tree Diagram X11 = 50 EUR X21 = 200 EUR X12 = 100 EUR X22 = 125 EUR

67. Project management - Summer seminar 201067 3.2.3. Decision Criteria Expected Monetary Value (EMV) = The expected profit for taking an action Aj Expected Opportunity Loss (EOL) = The expected loss for taking action Aj Expected Value of Perfect Information (EVPI) = The expected opportunity loss from the best decision

68. Project management - Summer seminar 201068 3.2.3. Expected Monetary Value (EMV) EMVj = expected monetary value of action j Xi,j = payoff for action j and event i Pi = probability of event i occurring

69. Project management - Summer seminar 201069 3.2.3. Expected Monetary Value (EMV) Example: Food Vendor Highest EMV = Better alternative EMV Soft Drink = 125 EUR EMV Hot Dog = 112.50 EUR

70. Project management - Summer seminar 201070 3.2.3. Expected Opportunity Loss (EOL) EOLj = expected opportunity loss of action j li,j = opportunity loss for action j and event i Pi = probability of event i occurring

71. Project management - Summer seminar 201071 3.2.3. Expected Opportunity Loss (EOL) Highest possible profit for an event Ei -Actual profit obtained for an action Aj = Opportunity Loss (lij ) Event: Cool Weather Action: Soft Drinks Profit x11 : 50 EUR Alternative Action: Hot Dogs Profit x12 : 100 EUR Opportunity Loss l11 = 100 EUR – 50 EUR = 50 EUR Opportunity Loss l12 = 100 EUR – 100 EUR = 0 EUR

72. Project management - Summer seminar 201072 3.2.3. Opportunity Loss: Table

73. Project management - Summer seminar 201073 3.2.3. Expected Opportunity Loss Example: Food Vendor Lowest EOL = Better Choice EOL Soft Drink = 25 EUR EOL Hot Dog = 37,50 EUR

74. Project management - Summer seminar 201074 3.2.3. EVPI Expected Profit Under Certainty - Expected Monetary Value of the Best Alternative = EVPI (should be a positive number) Represents the maximum amount you are willing to pay to obtain perfect information

75. Project management - Summer seminar 201075 3.2.3. EVPI computation Expected Profit Under Certainty =.50 * 100 EUR +.50 * 200 EUR = 150 EUR Expected Monetary Value of the Best Alternative = 125 EUR EVPI = 150 EUR - 125 EUR = 25 EUR = Lowest EOL = The maximum you would be willing to spend to obtain perfect information

76. Project management - Summer seminar 201076 3.2.3. Decision tree

77. Project management - Summer seminar 201077 How In groups Choose a spokesperson Time 30 minutes What See Workshop document 3.2.3. Workshop 4 – Risks

78. Project management - Summer seminar 201078 3.2. Building the Project Management plan Scope definition Scheduling Cost budgeting Risk mgmt. Org. & Comm. Planning Project Plan Project Charter

79. Project management - Summer seminar 201079 3.2.4. Scheduling: dropping the stones Deliverable & milestone based scheduling + Final deliverables + interim deliverables + organizational & external constraints = the skeleton of your schedule Why do we propose this approach?

80. Project management - Summer seminar 201080 3.2.4. Scheduling: activities Each deliverable is produced by 1 or more activities Activities depend on deliverables = more stability The WBS and the schedule should match somehow.. Sizing to be made with Expert judgement Ask people who have previous experience with similar activities Interview stakeholders Analogous estimating (top-down) Look at previous similar projects Quantitatively based durations e.g. meters of cable x hours/meter Reserve time (contingency) Develop an “optimistic”, “realistic” and “pessimistic” scenario The most realistic value can be calculated as (Optimistic + 4 * Realistic + Pessimistic) / 6

81. Project management - Summer seminar 201081 3.2.4. Scheduling : Activities and deliverables

82. Project management - Summer seminar 201082 3.2.4. Scheduling : Input Milestones & recurring

83. Project management - Summer seminar 201083 3.2.4. Scheduling : Assigning Resources

84. Project management - Summer seminar 201084 3.2.4. Scheduling : Rolling wave planning For the next 2 / 3 Months Activity size = 5 to 15 Work days Allocations = 5 to 15 Work days Up to 2 / 3 Months Estimate planning Estimate allocations Rolling Wave

85. Project management - Summer seminar 201085 3.2.4. Scheduling : Planning ready = time for baseline Explanation on red activities

86. Project management - Summer seminar 201086 3.2.4. Schedule : Planning ready = time for baseline 2 planning presentations Can be used for different audience Critical path = that sequence of activities which causes a delay for the project if one of the activities of the sequence has a delay In schedules mostly presented by activities in “red” Special attention for the activities on the critical path Critical chain = the sequence of activities, scheduled on their “optimistic time”, which is the longest sequence from start to finish This method works with a buffer which can be used for “contingency”

87. Project management - Summer seminar 201087 3.2.4. Schedule : Planning ready = time for baseline Example on rescheduling

88. Project management - Summer seminar 201088 3.2.4 Schedule : From cost model to throughput model Cost model Paradigm is to look for the most efficient way to perform task Number of resources Time per resource (weeks) Total time (weeks) Total project cost (1000 EUR per week) 1100 100.000 2459090.000 340120120.000 435140140.000

89. Project management - Summer seminar 201089 Workshop 5 - Schedule How In groups Time 60 minutes What See Workshop document

90. Project management - Summer seminar 201090 3.2. Planning Process Project Charter Scope definition Scheduling Cost budgeting Risk mgmt. Org. & Comm. Planning Project Plan

91. Project management - Summer seminar 201091 3.2. Planning Process Scope definition Project Charter Scheduling Cost budgeting Risk mgmt. Org. & Comm. Planning Project Plan

92. Project management - Summer seminar 201092 3.2.6. Communications Planning Communications planning aims at providing –the required information –in the right form –on the right moment –to the project’s stakeholders The information requirements cover –content –frequency –format

93. Project management - Summer seminar 201093 3.2.6. Communications Plan EXAMPLE

94. Project management - Summer seminar 201094 Part 4 - Execution 4.1. The PMBOK 4.2. Preparing for execution 4.3. What is a team 4.4. High performing teams 4.5. Team development stages – Tuckman model 4.6. Functional and team roles 4.7. Procurement Why ? Because after good initiation and planning, the most important for a project leader is to have a good team

95. Project management - Summer seminar 201095 4.1. PMBOK processes Initiating Processes Planning Processes Controlling Processes Executing Processes Closing Processes Where trouble begins….

96. Project management - Summer seminar 201096 4.2. Preparing for Execution & Control What will you do to Engender participation? Elicit feedback from team members and other stakeholders? Real (good) choices are made? Make sure the right work is done? Check risks along the project? Anticipate on project possible behavior?

97. Project management - Summer seminar 201097 4.3. What is a team ? T - Together E - Everyone A - Achieves M - More Team building is one of the primary responsibilities of the project manager

98. Project management - Summer seminar 201098 4.4. Developing High Performing Teams Each team member has Functional roles (project mgr., analyst, developer, etc.) Team roles (tendency to behave and interrelate with others) Each team needs an optimum balance in both functional and team roles Team building in the Tuckman model

99. Project management - Summer seminar 201099 4.5. Team Development Stages

100. Project management - Summer seminar 2010100 4.5.1. The Team Development Stages performance development stages formingstormingnormingperformingdisbanding Assess team readiness Define team goals and roles Clarify customer requirements Define processes Direct or coach & supervise Foster relationship building working group

101. Project management - Summer seminar 2010101 4.5.2. The Team Development Stages

102. Project management - Summer seminar 2010102 4.5.3. The Team Development Stages

103. Project management - Summer seminar 2010103 4.5.4. The Team Development Stages

104. Project management - Summer seminar 2010104 4.5.5. The Team Development Stages

105. Project management - Summer seminar 2010105 4.6. Functional & team roles Functions PM, Lead analysts, developers « easy »: experience, profiles, job description,… Team roles Probable/expected/required behavior in the group Less clear To help for behaviors, several models; MBTI Thomas (www.thomasinternational.net), Belbin (www.belbin.com)

106. Project management - Summer seminar 2010106 4.7. Procurement

107. Project management - Summer seminar 2010107 4.7. Procurement

108. Project management - Summer seminar 2010108 Part 5 - Control 5.1. Change management 5.2. Scope verification 5.3. Performance management 5.4. Risk management 5.5. Communication

109. Project management - Summer seminar 2010109 5.1. Change management Scope changes are normal Various sources: Insufficient requirements analysis Additional insight of problems External market conditions Evolving business needs, … It affects Cost (from 1 to 50 times) Schedule whereas resources are diverted from original scope Quality via quick fixes Morale via loss of control

110. Project management - Summer seminar 2010110 5.1. Change management Playing the roles (see process for context specific) PM: proactive change identification Active (early) role of project manager instead of reactive (late) customer request Sponsor: approving changes Every change or batch needs review & approval Team members Playing by the rules and showing excessive client focus Customers Accessing team members or playing by the rules Change control board for large projects

111. Project management - Summer seminar 2010111 5.1. Change management Dealing with scope changes – facilitated by: Batching small requests Taken to the sponsor when hitting a threshold Project Manager discretion Official decision making authority from the sponsor to the PM Scope change contingency budget Allocate a percentage of project NOT estimating contingency; this is for uncertainty Freeze Gate where each additional request is kept in backlog

112. Project management - Summer seminar 2010112 5.1. Change Management Managing changes is about integrating change control Determining that a change has occurred Smooth & structured process or during meetings Identify: date, source, description, reason, impact on scope, WBS, effort or schedule, Ensure changes are agreed upon Most probably during a meeting Accepted, amended or rejected Formal and incorporated into revised baseline

113. Project management - Summer seminar 2010113 5.1. Change management Rescheduling

114. Project management - Summer seminar 2010114 5. Control 5.1. Change management 5.2. Scope verification 5.3. Performance management 5.4. Risk management 5.5. Communication

115. Project management - Summer seminar 2010115 5.2. Scope Verification Scope verification is the process of obtaining formal acceptance of the project scope by the stakeholders It requires reviewing deliverables and work results to ensure that all were completed correctly (= quality control, verification) and satisfactorily (validation) For each major project deliverable (product or PM document), a formal acceptance needs to be obtained (Project clients can be very reluctant to approval – why?)

116. Project management - Summer seminar 2010116 5. Control 5.1. Change management 5.2. Scope verification 5.3. Performance management 5.4. Risk management 5.5. Communication

117. Project management - Summer seminar 2010117 5.3. Performance Management Performance monitoring & measuring Taking corrective action: Identify significant variances from the plan Adjust the plan by repeating the appropriate planning processes Taking preventive action In anticipation of potential problems

118. Project management - Summer seminar 2010118 5.3. Performance Management Performance reporting & Managing stakeholders PM and Executive determine way of internal reporting External reporting (Project Board and Executive Management) via “Management by exception”: Info about Effort: status, progress and forecast info Info on Risks, Change Requests and Activities

119. Project management - Summer seminar 2010119 5.3. Performance Reporting Status – Describing where the project now stands Progress – Describing what the team has accomplished Forecasting – Predicting future project status and progress Collecting and disseminating information to provide stakeholders with information on how resources are being used to meet project objectives!

120. Project management - Summer seminar 2010120 5.3. Project Dashboard Establish clear link between colour scheme in dashboard and more detailed progress report Names hidden for confidentiality reasons

121. Project management - Summer seminar 2010121 5.3. Guidelines for Progress Reports Colour scheme for status Green: no significant problems Orange: important problem; impact beyond tolerances can be avoided if corrective actions are taken in time Red: Project performance is beyond tolerance; immediate action needed to stop “bleeding” and minimize further impact Example for cost (similar for time) –Green: Estimate at complete (EAC) remains within original budget –Orange: EAC remains within original budget + 10% but there are issues that endanger surpassing the 10% tolerance –Red: EAC passed the project budget + 10% Tolerance levels should be set by the business executive

122. Project management - Summer seminar 2010122 Example for Scope/Quality Green: No discussions on scope Orange: Customer is raising additional (change) requests which are not planned for but which do not impact the cost & timing beyond their tolerance level Red: High frequency of change requests or change request with significant impact on cost and timing Example for Risk Green: Project and its uncertainties are under control; Orange: Risks are identified for which issues need to be discussed at the project board and action need to be taken that are outside the span of control of the project manager Red: Immediate action needed; Event is about to happen that will put the project status beyond its tolerance levels (cost, timing, scope or quality)

123. Project management - Summer seminar 2010123 5.3. Project Baseline for Performance Monitoring Comments: The 0-100 approach is the most realistic but it engages more work (tracking deliverables statuses) and can lead to some bad news reporting: The ETC can be calculated but should be reevaluated by project team What is interesting is not the spot value, it is the trend of both SPI and CPI What is even more interesting is to know the actual cause of both SPI and CPI variances Reminder: to do good EVA we need …

124. Project management - Summer seminar 2010124 5. Control 5.1. Change management 5.2. Scope validation & verification 5.3. Performance management 5.4. Risk management 5.5. Communication

125. Project management - Summer seminar 2010125 5.4. Risk Management Risk monitoring & control Assumption = risks have been scored during planning and recorded in “risk register” Progress meetings MUST track occurence of the risks If a risk occurs, the sponsor should be informed The process includes Keeping track of identified risks Monitoring residual risks Identifying new risks Ensuring the execution of risk plans Evaluating the effectiveness of risk plans in reducing risk

126. Project management - Summer seminar 2010126 5.5. Communication Management Assumption: Communication plan has been built in the planning phase Monitoring communication: MUST be included in the progress meeting is a clear project manager’s responsibility

127. Project management - Summer seminar 2010127 12-6-2016www-delta-i.be127 5.5. Summary project documents X = indicates who receives the document Color code indicates which responsability the concerned person/organ must take up Yellow= write Blue= collaborate Red= approve

128. Project management - Summer seminar 2010128 6. Closing 6.1. Why is closing important 6.2. What aspects 6.3. Minimum closing process Why ? Because learning from this one project can avoid making the same mistakes on the next one Initiating Processes Planning Processes Controlling Processes Executing Processes Closing Processes

129. Project management - Summer seminar 2010129 Customer oriented motivation –To formalize acceptance of the product of the project by the project sponsor or client Internal motivation –Try and enhance the way we do projects… Obstacles to closing process –From the customer: reluctance to sign off and accept –Internally Fear for finger pointing No time to waste Next project already started –In some companies the same errors keep coming back … 6.1. Closing - why?

130. Project management - Summer seminar 2010130 6.2. Closing - many aspects Time for post calculations Examples for post-project effort distribution; Project contribution calculation; Project team member (and sub-contractors) evaluations; Capture and distribute lessons learned and recommendations Action planning to get the benefits (measure program, etc.) Formal project acceptance and closure (criteria in project charter) Action planning for remaining open issues Administrative closure (archiving and clean up project dir, time registration,...) Party Time for final client satisfaction measurement Time for generating follow-up contracts

131. Project management - Summer seminar 2010131 6.3. Closing - minimum Check if all activities are finished Check if there is a formal acceptance for each product Clean the issue list so that only issues that require further action are in the list Formulate the lessons learned and distribute these Derive ratios from the activities and related planning and timesheets for future use Review the project management process and determine how it was applied & can be improved Clear and archive the project file

132. Project management - Summer seminar 2010132 6.3. Closing - measurements A project « post mortem » report should contain: Globally on Scope, Time, Cost & Quality How did the project « behave » If different than expected – why ? Suggested improvements Same from a number of perspectives Team = how did the team function Risk = what risks occured and how efficient was the plan Communication = how well did communication go Procurement = did we get required resources, on time, on budget?

133. Project management - Summer seminar 2010133 7. General 7.1. Ten ways to sink a project ! 7.2. Project success factors according to Gartner

134. Project management - Summer seminar 2010134 1. Be vague ! : the most generic scope keeps your client away from asking for details 2. Begin the execution as soon as possible (why spend time planning if you already know that a lot of changes will happen?) 7.1. Ten ways to sink a project !

135. Project management - Summer seminar 2010135 3. Focus on the team’s work – talking too much with the client will distract you 4. Don’t document the changes – this will save you from discussions with the client 5. Exceed the client’s expectations: add extras to the project scope 7.1. Ten ways to sink a project !

136. Project management - Summer seminar 2010136 6. Risk Management? Counting on your luck is the only way out! 7. Giving attention to quality matters most only in the final stage of the project; after all, what really counts is the ‘finished product’ 7.1. Ten ways to sink a project !

137. Project management - Summer seminar 2010137 8. Avoid bureaucracy – filling forms is a waste of time! This documentation will only fill up the archives! 9. Make the team work hard to avoid delays – overtime is essential to keep the team focused 7.1. Ten ways to sink a project !

138. Project management - Summer seminar 2010138 10. Get rid of the paperwork after the project close out! Past information will only take up too much space in your office! 7.1. Ten ways to sink a project !

139. Project management - Summer seminar 2010139 7.2. Success factors Business Sponsorship each project must have a nominated business sponsor with a stake in the outcome. Business Case includes the objectives, the benefits and how to measure success. It should describe the solution, the scope and the limitations. Business risk, business justification, appraisal of return on investment Project Oversight what are the processes and who are the people used to oversee the project, release funds and make the “go and no-go” decisions throughout the life cycle.

140. Project management - Summer seminar 2010140 7.2. Success factors Organization participants from all sides should be named, roles must be defined, estimate of the amount of time and duration of commitment. Project Plan No comment Risk Assessment Emphasis on risks associated with project size (time and resources), business requirements, capabilities (skills) and technologies Checkpoints There should be an end-of-project checkpoint and regular checkpoints throughout to ensure the business case still exists and to review the progress and risks.

141. Project management - Summer seminar 2010141 7.2. Success factors Requirements Concise vision and specification of requirements and deliverables, together with change control Communications Clear plan for communicating project objectives and tasks. Capabilities Capability gap analysis Motivation All those contributing to the project should be suitably motivated, measured and rewarded appropriately for its success.