Abbott Project Management Playbook

Abbott Project Management Playbook Intent

The intent of the Project Management Playbook is to provide a start to finish guide for managing Abbott projects. The content of the Playbook can be scaled to accommodate any type of Abbott project. This can be a resource for anyone performing project related responsibilities at Abbott and has been offered through the Project Management Community of Practice (PM CoP).

Abbott Project Management Playbook

T ABLE OF C ONTENTS Table of Contents.................................................................................................................................. 3 1 Project Initiation, Building Business Case.................................................................................. 5 1.1 Executive Summary ................................................................................................................... 5 1.2 Business Strategy....................................................................................................................... 6 1.3 Project Business Objectives....................................................................................................... 7 1.4 Success Criteria.......................................................................................................................... 7 2 Identify and Analyze Stakeholders ............................................................................................ 8 2.1 DEFINITION: What is a Stakeholder: ......................................................................................... 8 2.2 Elements/Process/Details ......................................................................................................... 8 2.3 Power/Interest Grid .................................................................................................................. 9 2.4 Influence/Interest Grid............................................................................................................ 12 2.5 Stakeholder Management Plan............................................................................................... 13 3 Project Charter ........................................................................................................................ 13 3.1 Purpose / Goal Statement ....................................................................................................... 14 3.2 Project Description.................................................................................................................. 14 3.3 Scope ....................................................................................................................................... 14 3.4 Budget ..................................................................................................................................... 15 3.5 Timeline (Schedule) ................................................................................................................. 15 3.6 Assumptions/Constraints ........................................................................................................ 15 3.7 Alternative Solutions ............................................................................................................... 16 3.8 Risks......................................................................................................................................... 16 3.9 Key Success Factors ................................................................................................................. 16 3.10 Stakeholders............................................................................................................................ 17 3.11 Communication Plan ............................................................................................................... 17 3.12 Decision Rights ........................................................................................................................ 17 3.13 Approval .................................................................................................................................. 18 4 Risk Management.................................................................................................................... 18 4.1 Plan Risk Management ............................................................................................................ 19 4.2 Identify Risks............................................................................................................................ 19 4.3 Perform Qualitative Risk Analysis............................................................................................ 19 4.4 Perform Quantitative Risk Analysis (As Required) .................................................................. 20

3

4.5 Plan Risk Response (Mitigation) Strategies ............................................................................. 21 4.6 Monitor And Control Risks ...................................................................................................... 22 5 Project Kick Off ........................................................................................................................ 23 5.1 Elements of Project Kick Off .................................................................................................... 23 5.2 Project Kick Off Preparation.................................................................................................... 23 5.3 Agenda..................................................................................................................................... 24 6 Project Planning....................................................................................................................... 25 6.1 Project Planning Options......................................................................................................... 25 6.2 Front End Planning (FEP) ......................................................................................................... 25 6.3 Phase 0 .................................................................................................................................... 26 6.4 RAPID....................................................................................................................................... 26 6.5 Comparison of FEP and Phase 0 .............................................................................................. 26 6.6 Front End Planning Elements/ Process/Details: ...................................................................... 28 6.7 FEP Feasibility Phase ............................................................................................................... 30 6.8 FEP Concept Phase and Capital Plan Gate 2............................................................................ 33 6.9 FEP Preliminary Design Phase and RCE Gate 3........................................................................ 35 6.10 FEP Lite: Projects $2.49MM and Under .................................................................................. 37 7 Request for Capital Expenditure (RCE).................................................................................... 39 7.1 Corporate Engineering (CE) Support of FEP ............................................................................ 42 8 Project Execution..................................................................................................................... 44 8.1 Project Execution Guideline .................................................................................................... 45 8.2 Governance ............................................................................................................................. 47 8.3 PEG Scalability ......................................................................................................................... 47 8.4 Detailed Design........................................................................................................................ 48 8.5 Construction / Startup / Commissioning................................................................................. 50 8.6 Qualification / Validation ........................................................................................................ 52 9 Project Control ........................................................................................................................ 53 9.1 Scope Control – Scope Management Plan .............................................................................. 54 9.2 Performance Measurement .................................................................................................... 55 9.3 Schedule Control – Schedule Management Plan .................................................................... 55 9.4 Cost Control – Cost Management Plan ................................................................................... 56 9.5 Change Control – Integrated Change Management Plan........................................................ 57 9.6 Earned Value Management..................................................................................................... 57 10 Project Closure ........................................................................................................................ 58 10.1 Project Close Gate – Governance Requirements .................................................................... 59 11 references - Abbott project management .............................................................................. 62

4

1 P ROJECT I NITIATION , B UILDING B USINESS C ASE Building Business Case DEFINITION: What is a business case? A business case presents information to a person or group of people which persuades them to decide one way or another. • Business cases should be based on adding value to the corporation – what is the right thing for the business • Financial evaluation is one component of the Business Case; however, it is only one of many factors to consider • A Business Case should consider: o Business Need: Why is the project being proposed to be executed? o Project Scope: What is the definition of the project scope that will be delivered to meet the business need o Business Strategy: How does what is being planned align with the business strategy of the company

Business Need

Project Scope

Business Strategy

Business Case

1.1 E XECUTIVE S UMMARY The Executive Summary must provide a concise, but complete explanation of the justification for the project in as brief a manner as possible, while including all the information necessary to reach an informed decision. The Executive Summary will include the following sections:

• Proposal: Your proposal should outline the costs and benefits of the project clearly and succinctly. Ensure it contains sufficient detail to satisfy management needs. Proposals can include but are not limited to: o Project goal o Key financial and other benefits o Funding and resources, you are requesting o

Links between your project and business priorities

5

• Background: The Background should explain why the project is being initiated, what the prerequisites are, and what results are supposed to be obtained at the successful completion. • Alternatives: This section should contain a brief description of each of the viable alternatives and a discussion of the reasons for rejecting each alternative in favor of the proposed project. This section should include an exhaustive evaluation of all practical alternatives. The proposed project should not be listed as one of the alternatives. • Justification: Include a discussion of the importance of implementing the project and realizing its expected benefits. If your project has financial elements, the justification should include both the financial and non-financial benefits and objectives. • Reconciliation: Describe the reasons for any significant differences between a project's "Capital – Requested” vs. "Capital - Planned" and "Capital Latest Update". Also, indicate the source of funds for unbudgeted projects. • Cash Flow: Is the total amount of money being transferred into and out of the business. Include the timing of capital and expense spend. • Scope: The work performed to deliver a product, service, or result with the specified features and functions • Financial Assumptions: Detailed financial assumptions including sources of estimates included in the business case • Schedule: Summary timeline for execution or project and reporting milestones identified • Planning Documentation and Assessment: Requirements for compliance with Front End Planning (FEP), IT Phase 0, or IT RAPID (as applicable) documented and included with business case artifacts including, but not limited to: stakeholder approvals of scope, time etc., risk assessments, design concepts, flexibility considerations, layouts, Monte Carlo assessments of cost & schedule estimates, regulatory / safety / security considerations, permitting requirements, quality considerations and compliance

1.2 B USINESS S TRATEGY Example Business Strategy Statement: From our investor website: Abbott is a globally diversified healthcare company with a central purpose to help people live their healthiest possible lives . Business Strategy should include the following elements: • Balance: Well-balanced business diversity. • Global Presence: Details on global footing and growth.

• Relevance: Statement on global positioning to serve expanding markets. • Leading: Identify business leadership in the scientific and commercial arenas in multiple geographies. • Consistent and Reliable Performance: Identify consistent and reliable performance in innovation, productivity, and growth with consistency and reliability.

6

1.3 P ROJECT B USINESS O BJECTIVES • Identify specific quantifiable deliverables, directly linked to the business case which must be achieved to consider the project complete and successful. • Focus on gaining a clear understanding of the business objective before creating a solution • Tips for developing clear objectives: o Identify what ‘good’ looks like o Be concise o Be conscious of technical jargon & acronyms o Specific Measurable Attainable Relevant Time Bound (SMART goals) • The following should be included in the Projects Business Objectives (PBO): o Statement: A brief narrative description of what you want to achieve o Measures: Indicators you’ll use to assess your achievement o Performance specifications: The value(s) of each measure that define success 1.4 S UCCESS C RITERIA o Define what success looks like for your project or you won’t know if you have achieved it. o Measure what’s important to your stakeholders. o Document success criteria and get everyone to agree to them. o Use continuous measurements where possible. o Baseline today’s performance so you know where you are starting from. o Track as appropriate and report on your progress. Note: Definition of success criteria is not a one-time exercise, it is important to re-confirm the business objectives and success criteria periodically throughout project execution (e.g. Stakeholders, business environment, marketing (quicker to market), changes (additions, modifications), external factors, and changes in assumptions. Typically, this can be done as part of the stakeholder and sponsor periodic meetings.

Identify Stakeholders

Define Business Goals & Objectives

Periodically Review to ensure Success Criteria Still Valid

Identify Constraints

Derive Project Success Criteria

Deliverables/Output/Next Steps: • Completed Business Case document (possible formats include PowerPoint, Word, PDF) • Communication of Business Case – TBD Useful Links:

7

• Business Case Template

2 I DENTIFY AND A NALYZE S TAKEHOLDERS

2.1 DEFINITION: W HAT IS A S TAKEHOLDER : Keep in mind what the “stakeholder” word means. The “stake” refers to interest, participation, while “holder” refers to the one who detains. Soon, the stakeholder is a person/community who has interest/participation on what is being done, even if only he believes that he is a stakeholder. However, there is a common habit of neglect some stakeholders during the initiation of a project who have some impact in it. What happens is they are requested only when they are needed, but, by this time, the impact is already in place. People working with projects tend to always use their own routine as reference, where they are, in most of cases, specialists, only delegating activities, not managing stakeholders. When it is necessary to work with people from other departments, other companies, government and even communities, some parts are usually left aside, and this denying has future consequences. To avoid this kind of problematic situation, it is encouraged to think about any project like it is “large” (500 hundred people, at least five different departments, international culture conflict, etc.), forcing you to think “out of the box” and list every possible stakeholder for this project. A stakeholder who is not identified during the initiation of the project might request changes later which could impact the project’s delivery.

2.2 E LEMENTS /P ROCESS /D ETAILS PMI includes the stakeholder management as one of the knowledge areas, and the PMBOK describes the details of the process involved on chapter 13 (6th Edition). This edition brings four different processes that involved stakeholder management, as shown in the picture below.

Identify Stakeholders

Plan Stakeholder Management

Manage Stakeholder Engagement

Monitor Stakeholder Engagement

8

Another important reference for project management studies describes important process that should be performed when managing stakeholders. Rita Mulcahy’s diagram presents the critical activities not to be overlooked for stakeholder management. For the stakeholder management, see the picture below.

The idea of this section in the Abbott PM Playbook is to briefly transcribe the highlights and important concepts and techniques to perform an appropriate stakeholder management. The process of identifying and engaging stakeholders for the benefit of the project is iterative. The four processes should be reviewed and updated routinely; but most importantly when the project moves through different phases in its life cycle, stakeholders change (either current ones are no longer involved in the work of the project or new stakeholders join the team), or when there are significant changes in the business needs, organization, or the wider stakeholder community. Each project has its own specificities and Abbott’s internal environment depending on the type/area/size of the project. As a result, not all PMBOKmethodologies are not applicable to Abbott projects. Considering this, it is also important to identify the stakeholder diversity of the project (how diverse is the culture within the stakeholder community). Also, it is important to identify the complexity of stakeholder relationships considering the network involved and the technology used for project communication (tools available and effectiveness, how transparent is the relationship between the stakeholders, etc.). Another current need is to perform projects as agile as possible. To facilitate in a timely manner, it is important to manage the project guiding productive discussion and decision making, where teams can "walk with their own legs" rather than going through layers of management to go ahead with the project. Furthermore, as previously stated, regular interactions with the stakeholders throughout the project helps mitigate potential risk, builds trust, and supports changes, increasing the likelihood of success for the project. 2.3 P OWER /I NTEREST G RID First, when identifying the stakeholders, it is important to generate a stakeholder register, where information about them will be maintained. This information is important for future evaluations to confirm that the behavior of each stakeholder is following as expected. For a successful stakeholder management, it is not only important the identification of the stakeholders, but also determine their requisites, expectations, interests, level of influence, and, subsequently, plan how they will be managed, communicated, and have their engagement managed. Every kind of interaction with them will confirm they understand what the project is about.

9

All the info obtained can be compressed in a matrix and should be saved in the Stakeholder Management Plan as part of the project scope. Some highlights are: • Name • Interest on the project • Expectations/requisites on the project

• Level of power over the activities throughout the project • Level of influence over the activities throughout the project • Necessary engagement for project development • Skills which could be useful

• Responsibilities over the project • Risks related to this stakeholder • Communication method effective • Formal acceptance

After all the stakeholders’ information is collected, an analytical technique that classifies them is recommended. This classification can be included in the stakeholder register. They are usually classified in five types: • Unaware: No knowledge and no impact over the project

• Resistant: Aware of the project and its impact, but resistant to changes • Neutral: Aware of the project but does not provide support or resistance • Supportive: Aware of the project and its impact and provides support to changes

• Leading: Aware of the project and its impact and works with engagement for project success Some of these stakeholders may have the power either to block that work or to advance the project. Some may be interested in what you are doing, while others may not care, so the Project Manager needs to determine priorities. The power/interest grid maps out your stakeholders and classifies them according to their power over your work and their interest in it.

10

The position that you allocate to a stakeholder on the grid shows you the actions you need to take with them. The table below exemplifies each scenario.

Some questions will assist you when allocating each stakeholder in one of these four quadrants and on identifying which ones your key stakeholders are, such as: • What financial or emotional interest do they have in the outcome of your work? Positive or negative? • What information do they want from you, and what is the best way of communicating with them? • Who influences their opinions generally, and who influences their opinion of you? • If they aren’t likely to be positive, what will win them around to support your project? • If you don't think that you’ll be able to win them around, how will you manage their opposition? Key stakeholders need more attention. A suggestion is to use a specific color for each of the five types described above, so you can identify clearly who are the stakeholders who need your actions focused on, like in the example below.

11

2.4 I NFLUENCE /I NTEREST G RID An analogue technique to the power/interest grid presented in the section above is the Interest/Influence grid. The main difference is that instead of understanding and prioritizing your actions as project manager over the stakeholder, the influence/interest grid assists you on the communication and change aspects. The greater the influence over the project, the greater is the project manager effort to keep this stakeholder engaged in the project and in its baseline. The grid and the action plan are presented as below.

It is equally possible to perform a categorization, followed by prioritization of the stakeholders to allocate them in the influence/interest grid. These are not all the stakeholder management techniques available. The PMBOK also lists the stakeholder cube, salience model, and directions of influence. It is understood that the techniques presented here are enough for projects where it is necessary to identify the stakeholders and control their engagement in a low level of complexity, based on arguments, discussions, and formal/informal meetings, not any technique.

12

2.5 S TAKEHOLDER M ANAGEMENT P LAN The stakeholder engagement plan is a component of the project management plan that identifies the strategies and actions required to promote productive involvement of stakeholders in decision making and execution. It can be formal or informal, highly detailed, or broadly framed, based on the needs of the project and the expectations of stakeholders. The stakeholder engagement plan should include the strategies or approaches for engaging with the stakeholders. It can also contain what information should be shared, how often it will be done and what are the most effective ways to communicate with the stakeholders, such as meeting calendar, performance report and project visits. Lastly, all the information acquired with the stakeholders, including their register and analysis should be included in the stakeholder management plan. The table below lists the main differences between a stakeholder management plan and a communication plan, which are closely aligned.

Useful Links: • Stakeholder Management Plan template • Stakeholder Analysis-Engagement Template • Stakeholder Power Interest Classification Grid Template • IT Specific Templates (Business & Technology Services PMO Processes and Templates Library)

3 P ROJECT C HARTER DEFINITION: What is a project charter?

A project charter is a condensed project overview that acts as a preliminary outline of the project’s scope and objectives. It formally authorizes the existence of a project and provides the project manager with the authority to apply resources to the project. The project charter can also serve as a formal written and signed agreement between stakeholders.

13

Elements/Process/Details The below sections provide detail of the many elements that make up a Project Charter.

3.1 P URPOSE / G OAL S TATEMENT The Purpose, or Goal Statement, of a project should: • Explain the business needs • Clarify the product of the project

• Tell how the project aligns with the organization’s strategic plan

3.2 P ROJECT D ESCRIPTION The project description should:

• Provide a high-level overview of the project and what it will achieve • Align the project team on the purpose of the project • Briefly capture business rationale and key deliverables

Example: The GES project team will deliver a new facility for AN, capable of manufacturing 80MM cans of Ensure per year, supporting the expansion of the Nutrition business in India. The facility has been designed and is being constructed to facilitate 100% future expansion without disruption to the ongoing operations. It will be completed on schedule in Jan ’19 with registration and first lots to stock expected in March ’19. The project is predicted to be completed at the agreed budget cost of $89MM. 3.3 S COPE The scope is what is going to be done during the project, a detailed description of the products and/or services to be delivered to attend the project goals. It is important to notice the difference between product scope and project scope. While the first one is a description of all the characteristics and functionalities of the product and/or service verified by its requisites, the second one is the work which should be performed to release the product under its specifications, what is verified by the project

14

management plan. A well-defined scope is considered extremely important because a scope that is not well-defined will lead to an unsuccessful project. Both scope and WBS is the basis for all the other processes and PM knowledge areas. 3.4 B UDGET The total cost of a project is the sum of all resources necessary to execute all the activities listed in the WBS, expressed in a monetary value. They add up to the cash flow and, with the gains of the project, determine the project feasibility. During the initiation, a cost evaluation is performed to elaborate a project preliminary budget to approve or not approve the project itself. This budget is detailed later, among the processes of cost management, and will be part of the cost baseline, which will be used to monitor/measure the project performance by tools, such as the earned value calculation. 3.5 T IMELINE (S CHEDULE ) The project schedule documents the project activities, the respective initial and end dates, the allocated resources, and schedule restrictions. For the project charter, it is recommended to focus primarily on the milestones of the project, to facilitate a management decision. A milestone (no duration considered) is a very important moment during the project, because when it is concluded, and it is effective, it means a goal for the entire team was achieved. The project manager and his team must be aware of the milestones of the project to guarantee they happen according to the dates listed in the schedule and do not impact the project success. 3.6 A SSUMPTIONS /C ONSTRAINTS The most common definition for assumption is a hypothesis that is considered true to reach a conclusion. Every project involves uncertainties which may be dependent on other parts not under control. It is important to state these assumptions to go forward with the project. The project assumptions are factors considered true without any evidence for planning goals. If they are not managed, the schedule and the budget can be compromised. The most important thing about any assumption is the risk evaluation supporting it. If the assumption is not in control or not true. The planning will not happen as predicted and the project is compromised. The constraints are project limitations imposed to the project team that might not affect the project performance at all, but cannot be violated and must be respected, analysed, and treated correctly. They can be organizational, environmental and/or external. They are extremely important as well because if they are not attended, the project success is compromised again. When it is known that it is not possible to attend a constraint, the project must be cancelled or have its scope redefined. Common examples of constraints: • Limited head count

• Lack of or limited knowledge • Short window of opportunity • Staffing constraints • Delivering the product within a specific time frame • Delivering the product within a limited cost

15

3.7 A LTERNATIVE S OLUTIONS Having the assumptions and constraints listed, it could be possible to identify potential alternatives for accomplishing the project. For each alternative, there must be a general description that includes what the alternative is, how it would be implemented, and how it would work after implementation. Include additional details such as specific interfaces, tools required, legal requirements, support, etc. If possible, also include an estimated time frame, to which specific assumptions and/or constraints specific to the considered alternative(s), and any other advantages/disadvantages. In the end, select one of the alternatives to be carried forward, providing a reasonable justification for why you chose this alternative. Provide preliminary costs to develop and maintain the proposed solution. 3.8 R ISKS A risk inside a project is an event with a probability of happening in the future, impacting the project in a negative way (threat) or in a positive way (opportunity). It can occur because of one or more causes and can generate one or more positive or negative impacts. Do not forget that risks are related with the other knowledge areas and must be treated in an integrated way, considering the best practices of each area. Risks can be known (identified, analysed, and considered within the project planning) or unknown (not identified previously, and when they happen should be treated immediately). The project manager should take the corrective actions, identify the root cause, and take the preventive actions to avoid recurrence. Moreover, all the actions must be documented, and the responsible parties notified, guaranteeing commitment and the effectiveness of the action. 3.9 K EY S UCCESS F ACTORS Below is a list of critical success factors important for all projects. Additionally, each project should develop a unique set of clearly understood success factors or criteria that the project team agrees to and strives to achieve, for example a common business need to deliver the project results as planned. Defining these upfront and documenting them in the Project Charter, will help to gain alignment and work collectively towards project success. • Have a clear mission for each project phase • Involve all the possible stakeholders • Have a trustworthy and engaged top manager and sponsor for the project • Project management professionals with experience in every area of knowledge • A well-defined scope, considering the team, the methodology, time, and client participation • A trusted and competent leader • Calculate risks before the beginning of the project • Formal establishing of the project manager and the project team

• Recognize people and make them understand their value for the project • Correct resources allocation to attend stakeholder’s expectations • Realistic schedule • Be aware of the milestones

• Have an effective and approved communication plan • Motivate the project team and the project manager

• Have the same project manager in the project planning and execution phases • Perform constant reviews to keep the client aware of the project status • Make yourself presentable (take care of your image) in appropriate ways for each situation

16

• Be realistic throughout the development of the project, evaluating its performance • Never despise minor details • Openness to look for help when necessary • Know the correct time to say yes and no • Monitor every process implemented • Know the right time to delegate • Be open for negotiations • Be polite and confident when speaking • Project controls: change control, cost/schedule control, risk management • Recognize limits/boundaries • Do not avoid conflicts • Deal with mistakes and communication properly/timely • Exercise active listening

3.10 S TAKEHOLDERS See Section 2.0.

The stakeholders are individuals or organizations that are somehow engaged with the project. The project should attend to their needs and the Project manager is responsible of identifying and analysing them. Like risks, they can have positive or negative influence/impact on the project. The most important stakeholders are: • Client • Sponsor • Project manager • Project team The stakeholders usually have more than one function inside the project and the project manager should differentiate them and treat each stakeholder in a unique way. For example, the sponsor can also be your client and you, as project manager, must attend all your client’s needs as client and sponsor, keeping their engagement. 3.11 C OMMUNICATION P LAN The communication is certainly one of the most important knowledge areas for the Project manager, because it represents around 90% of his time, as he is the link between people, ideas, and information. Most of the problems result from lack of communication, and there is a strong relation between the project development and the project manager’s ability to manage communication. The project charter can provide an idea of the communication necessary to achieve project success. The best practices for communication are focused on who (person who is responsible for delivering the communication), what (the type of communication), why (the rationale for the communication plan), where (the location where the recipient will find the communication, if specified), when (the time and/or frequency at which the communication is delivered), how (the delivery mechanism that will facilitate the communication), and to whom (the audience or recipients of the communication). 3.12 D ECISION R IGHTS Express the logic about who is authorized to make what types of decisions inside the project, both in terms of everyday effectiveness and the bottom line. Four steps can assist the decision rights: • Company • Suppliers • Procurement

17

• Routinely review and update how decision authority is distributed • Avoid too much centralization and too much democracy • Assign decision rights unequivocally • Don't confuse a particular outcome with the process itself

3.13 A PPROVAL The project charter is formally accepted and approved by the project sponsor and other designated stakeholders. Formal approval acknowledges the completion, review, and acceptance of all the deliverables produced during the initiate stage. Signatures on the project charter document, final approval of the charter, is the go-forward agreement to continue project planning. The applicable teammembers are usually the project manager, project sponsor, and project stakeholders. A formal approval process encourages the completion and acceptance of the deliverables/results from project Initiation to project charter development. The distribution and review of the project charter to the project sponsor/stakeholders and appropriate team members will provide an opportunity for making any necessary changes before finalizing the project charter deliverables. The project sponsor should indicate the reasons for rejecting the project if the decision is a no-go. If the project is a go, signatures from the project sponsor and any other designated stakeholder must be obtained. Useful Links: • Project Charter Template 1 Basic • Project Charter Template 2 Detailed • IT Specific Templates (Business & Technology Services PMO Processes and Templates Library)

4 R ISK M ANAGEMENT Project Risk Assessment

Project risk management endeavors to identify and prioritize risks in advance of their occurrence and provide action-oriented information to project managers and other team members. Risk Assessment requires identification of events that may or may not occur and are therefore described in terms of likelihood or probability of occurrence, as well as their impact on objectives. It’s important to note that risk assessment is an iterative process that occurs throughout the project lifecycle and serves as a basis for effective project governance.

The Risk Management Process, the six processes are broadly defined as follows:

1.0 Plan Risk Management 2.0 Identify Risks

3.0 Perform Qualitative Risk Analysis 4.0 Perform Quantitative Risk Analysis 5.0 Plan Risk Responses 6.0 Monitor and Control Risks

18

4.1 P LAN R ISK M ANAGEMENT Defines the scope and objectives of the Project Risk Management process and ensures that the risk process is fully integrated into wider project management. The results of risk management planning are documented in the risk management plan. The plan serves to provide all project stakeholders with a common view of how the risk-related activities of the project will be handled, the degree of resources and effort to be committed, and a description of the stakeholders’ involvement and responsibilities in these activities. Depending upon the size and complexity of the project, some or all the following elements will be present in a risk management plan.

• Introduction • Project description

• Risk management methodology • Risk management organization • Roles, responsibilities, and authority • Stakeholder risk tolerance • Criteria for success

• Risk management tools and guidelines for use • Thresholds and corresponding definitions • Templates • Communications plan • Strategy • Risk breakdown structure

4.2 I DENTIFY R ISKS A risk cannot be managed unless it is first identified. Consequently, after risk management planning has been completed, the first process in the iterative Project Risk Management process aims to identify the knowable risks to project objectives. It is, however, impossible to identify all the risks at the outset of a project. Over time, the level of project risk exposure changes. The purpose of risk identification is to identify risks to the maximum extent that is practicable. The fact that some risks are unknowable requires the Identify Risk process to be iterative, repeating to find new risks which have become knowable since the previous iteration of the process. When a risk is first identified, potential responses may also be identified at the same time.

Examples of how risks are identified include: • Use lessons learned from previous projects • Create a SWOT (Strengths, Weakness, Opportunities, Threats) • Interview relevant experts

• Perform assumptions analysis • Perform document reviews • Use brainstorm sessions • Use checklists

Once a risk is identified it must be added to the risk register with a risk owner.

4.3 P ERFORM Q UALITATIVE R ISK A NALYSIS The Perform Qualitative Risk Analysis process assesses and evaluates characteristics of individual

19

project risks and prioritizes (classifies) risks based on agreed-upon characteristics. Assessing individual risks using qualitative risk analysis evaluates the probability that each risk will occur and the effect of each individual risk on the project objectives. As such it does not directly address the overall risk to project objectives that results from the combined effect of all risks and their potential interactions with each other. This can however be achieved through use of quantitative risk analysis techniques. The methods of qualitative risk analysis are applied to the list of risks created or updated by the Identify Risks process to provide project management with the characteristics of the risks that have the most influence on achieving the project’s objectives. Risks that are assessed as very high priority as per Figure 4.3 - Heat Map are those that threaten the achievement of project objectives and will be an important focus in the Plan Risk Responses process. They may be further analyzed, such as in the analysis of the overall project risk that is discussed in Perform Quantitative Risk Analysis process.

Figure 4.3 - Heat Map

4.4 P ERFORM Q UANTITATIVE R ISK A NALYSIS (A S R EQUIRED ) The Perform Quantitative Risk Analysis process provides a numerical estimate of the overall effect of risk on the objectives of the project, based on current plans and information, when considering risks simultaneously. Results from this type of analysis can be used to evaluate the likelihood of success in achieving project objectives and to estimate contingency reserves, usually for time and cost that are appropriate to both the risks and the risk tolerance of project stakeholders. It is generally accepted that analyzing uncertainty in the project using quantitative techniques such as Monte Carlo simulation may provide more realism in the estimate of the overall project cost or schedule than a non-probabilistic approach which assumes that the activity durations or line-item cost estimates are deterministic. However, it should be recognized that quantitative risk analysis is not always required or appropriate for all projects. For example, qualitative risk analysis may provide enough information for development of effective risk responses, especially for smaller, less complicated projects. Therefore, during the Plan Risk Management process, the benefits of quantitative risk analysis should be weighed against the effort and resources required to implement. Partial risk analyses, such as qualitative risk analysis, aim at prioritizing individual risks viewed one at a time and therefore cannot produce measures of overall project risk when all risks are considered simultaneously. Calculating estimates of overall project risk is the focus of the Perform Quantitative Risk Analysis process. The implementation of overall risk analysis using quantitative methods requires the application of a scoring system such as Risk Priority Number or Monte Carlo simulation that incorporates multiple risks simultaneously in determining overall impact on the overall project objective.

The following is an example of Monte Carlo Project Cost Risk Estimate:

20

Figure 4.4A - Summary of Cost Estimate

Figure 4.4B - Simulation Results, Cost In this example the Base capital cost is $2.07 MM. There is a 70% to 90% Probability that your cost will be at or under that estimate as seen in Figure 4.4B. Using this probability Abbott estimates the Base cost must have a contingency of between 10% and 14% per Figure 4.4A. Results of the quantitative analysis will be compared to the project plan (baseline or current) to provide the project teams an estimate of the overall project risk and will answer important questions such as: • How much contingency in time and cost is needed to provide the organization with its desired degree of confidence in the results? • What are the individual risks that seem to be the most important in determining the overall project risk? Estimating overall project risk using quantitative methods helps distinguish those projects where quantified risks threaten objectives beyond the tolerance of the stakeholders, from those for which the objectives are within acceptable tolerances even when risk is considered. The former may be targeted for vigorous risk responses aimed at protecting those objectives most important to the stakeholders. 4.5 P LAN R ISK R ESPONSE (M ITIGATION ) S TRATEGIES The project manager should develop risk response strategies for individual risks, sets of risks, and project level risks. The affected stakeholders should be involved in determining the strategies. There are generally four widely recognized strategies which address individual risks for threats and opportunities. • • How likely is the project to complete on the schedule date or earlier? How likely is the project actual cost to be the budgeted cost or less?

21

I. Avoid a Threat or Exploit an Opportunity This strategy involves taking the actions required to address a threat or an opportunity to ensure either that the threat cannot occur or can have no effect on the project, or that the opportunity will occur, and the project will be able to take advantage of it. Transfer a Threat or Share an Opportunity This strategy entails transference to a third party that is better positioned to address a particular threat or opportunity. Mitigate a Threat or Enhance an Opportunity Mitigation and enhancement are the most widely applicable and widely used response strategies. Here, the approach is to identify actions that will decrease the probability and/or the impact of a threat and increase the probability and/or the impact of an opportunity. Accept a Threat or an Opportunity This strategy applies when the other strategies are not considered applicable or feasible. Acceptance entails taking no action unless the risk occurs, in which case contingency or fallback plans may be developed ahead of time, to be implemented if the risk presents itself. Documenting the Results of the Plan Risk Responses Process Risk response planning is based on the information placed in the risk register during execution of the Identify Risks and Perform Analysis processes. The corresponding risk response (mitigation) information is often referred to as the risk response plan, although it may in fact be an integral part of the risk register. Add Risk Responses to the Risk Register The response-related information for each risk is recorded in the risk register and updated regularly, Figure 4.5A is an example of a Risk Register. Any interested stakeholder should be able to rapidly access all the information required to verify their responsibilities and manage the risk in accordance with the risk response plan. II. III. IV.

RISK REGISTER

RISK IDENTIFICATION

RISK MANAGEMENT

ANALYSIS

Monitoring & Updating

Category of Impact

Pre-Mitigated Risk Mean Value

Pre-Mitigated Risk Ranking

Post-Mitigated Risk Mean Value

Post-Mitigated Risk Ranking

Item Status Date Identified Brief Risk Description

CII Project Phases

Response Action/Strategy Description Responsible Individual

Risk Resolution Date

Trigger Events

1

Active

07/14/12

Brief risk description text

Front End Planning

Cost

$1,200,000

High

Detailed Description

Tom

Brief Description

10/01/12

$165,000

Med

2

Active

07/15/12

Brief risk description text

Procurement

Schedule

$100,800

Med

Detailed Description

Fred

Brief Description

10/02/12

$46,600

Med

Figure 4.5A - Example of a Risk Register

Add Corresponding Risk Responses to the Project Management Plan While developing the detailed set of risk responses, the project-related implications are evaluated for inclusion in a modified project management plan. These include costs, resource assignments, scheduling details, and changes to project documentation.

4.6 M ONITOR A ND C ONTROL R ISKS Purpose and Objectives of the Monitor and Control Risks Process

The primary objectives of risk monitoring and controlling are to track identified risks, monitor residual risks, identify new risks, ensure that risk response plans are executed at the appropriate time, and evaluate their effectiveness throughout the project life cycle. In addition to tracking and managing the risk response actions, the effectiveness of all the Project Risk Management processes should be reviewed to provide improvements to the management of the current project as well as future ones.

22

Integrate Risk Monitoring and Control with Project Monitoring and Control From the start, the project management plan should include the actions required to monitor and control project risk. This should be set up early in the project planning cycle, and then adjusted in view of the risk response planning decisions adding, for example, the actions associated with monitoring specific conditions or metrics. Once risk response planning has been carried out, the project schedule should include all the agreed-upon, response-related actions so that they can be carried out as a normal part of project execution and tracked accordingly. Managing Contingency Reserves Reserves may have been allocated separately to cover time-related and cost-related risks. Techniques are required that allow the project manager to assess at any point in the project whether these provide the required level of confidence in the success of the project. Tools for managing time buffers should be closely integrated into the project’s scheduling techniques, whereas those for managing cost should be compatible with the financial practices. Tools are required to identify trends and forecast future outcomes to determine whether the reserves will remain sufficient.

Useful Links:

• GES Guideline for Risk Management • Risk Register Template • GES Guidelines for Monte Carlo Simulation Workshops for Project Teams • IT Specific Templates (Business & Technology Services PMO Processes and Templates Library)

5 P ROJECT K ICK O FF DEFINITION: What is the Project Kick Off?

The Project Kick off meeting is of critical importance to the success of the project. The initial meeting occurs at the on-set of the Project Planning Phase. Elements/Process/Details

5.1 E LEMENTS OF P ROJECT K ICK O FF • Set a clear agenda: why, who, what, where when and how

• Ensure the right participants are invited • Prepare to make a good first impression • Set a clear communication plan

5.2 P ROJECT K ICK O FF P REPARATION Content (the ‘why’, ‘what’):

• Develop / review business case & project charter, including project business objectives. • Develop project execution plan. • Develop milestone schedule. • Develop team communication / alignment plan.

23