Abbott Project Management Playbook

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 C ONTENTS

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 1.5 Project Governance ................................................................................................................... 8 2 Identify and Analyze Stakeholders .......................................................................................... 12 2.1 DEFINITION: What is a Stakeholder: ....................................................................................... 12 2.2 Elements/Process/Details ....................................................................................................... 12 2.3 Power/Interest Grid ................................................................................................................ 14 2.4 Influence/Interest Grid............................................................................................................ 17 2.5 Stakeholder Management Plan............................................................................................... 18 3 Project Charter ........................................................................................................................ 19 3.1 Purpose / Goal Statement ....................................................................................................... 19 3.2 Project Description .................................................................................................................. 19 3.3 Scope ....................................................................................................................................... 20 3.4 Budget ..................................................................................................................................... 20 3.5 Timeline (Schedule) ................................................................................................................. 20 3.6 Assumptions/Constraints ........................................................................................................ 20 3.7 Alternative Solutions ............................................................................................................... 21 3.8 Risks......................................................................................................................................... 21 3.9 Key Success Factors ................................................................................................................. 21 3.10 Stakeholders ............................................................................................................................ 22 3.11 Communication Plan ............................................................................................................... 23 3.12 Decision Rights ........................................................................................................................ 23 3.13 Approval .................................................................................................................................. 23 4 Risk Management.................................................................................................................... 24 4.1 Plan Risk Management ............................................................................................................ 24 4.2 Identify Risks............................................................................................................................ 25 4.3 Perform Qualitative Risk Analysis............................................................................................ 25

3

4.4 Perform Quantitative Risk Analysis (As Required) .................................................................. 26 4.5 Plan Risk Response (Mitigation) Strategies ............................................................................. 27 4.6 Monitor And Control Risks ...................................................................................................... 28 5 Project Kick Off ........................................................................................................................ 30 5.1 Elements of Project Kick Off .................................................................................................... 30 5.2 Project Kick Off Preparation .................................................................................................... 30 5.3 Agenda..................................................................................................................................... 30 6 Project Planning....................................................................................................................... 32 6.1 Project Planning Options ......................................................................................................... 32 6.2 Front End Planning (FEP) ......................................................................................................... 32 6.3 Phase 0 .................................................................................................................................... 32 6.4 RAPID....................................................................................................................................... 33 6.5 Comparison of FEP and Phase 0 .............................................................................................. 33 6.6 Front End Planning Elements/ Process/Details: ...................................................................... 35 6.7 FEP Feasibility Phase ............................................................................................................... 38 6.8 FEP Concept Phase and Capital Plan Gate 2............................................................................ 40 6.9 FEP Preliminary Design Phase and RCE Gate 3........................................................................ 42 6.10 FEP Lite: Projects $2.49MM and Under .................................................................................. 45 6.11 Accelerated Project Definition ................................................................................................ 46 7 Request for Capital Expenditure (RCE) .................................................................................... 51 7.1 Corporate Engineering (CE) Support of FEP ............................................................................ 55 8 Project Execution..................................................................................................................... 58 8.1 Project Execution Guideline .................................................................................................... 58 8.2 Governance ............................................................................................................................. 61 8.3 PEG Scalability ......................................................................................................................... 62 8.4 Detailed Design........................................................................................................................ 63 8.5 Construction / Startup / Commissioning................................................................................. 65 8.6 Qualification / Validation ........................................................................................................ 67 9 Project Control ........................................................................................................................ 69 9.1 Scope Control – Scope Management Plan .............................................................................. 70 9.2 Performance Measurement .................................................................................................... 70 9.3 Schedule Control – Schedule Management Plan .................................................................... 70 9.4 Cost Control – Cost Management Plan ................................................................................... 72 9.5 Change Control – Integrated Change Management Plan........................................................ 73 9.6 Earned Value Management..................................................................................................... 73

4

10 Project Closure ........................................................................................................................ 75 10.1 Project Close Gate – Governance Requirements .................................................................... 76 11 References - Abbott project management.............................................................................. 78

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.

5

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

• Background: The Background should explain why the project is being initiated, what the prerequisites are, and what results are supposed to be obtained at thesuccessful 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.

6

• 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.

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 Define what success looks like for your project or you won’t know if you have achieved it. o M easure what’s important to your stakeholders . o Document success criteria and get everyone to agree to them. o Use continuous measurements where possible. o B aseline 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. 1.4 S UCCESS C RITERIA o

7

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: •

Business Case Template

1.5 P ROJECT G OVERNANCE Project governance provides an integrated structure to ensure project is delivered in accordance with expectations of the business, communications are structured to ensure information is provided to the right leadership in a timely manner and that there are clear structures for decision making. People who fill a governance function approve, reject or modify recommendations made by the project team and monitor project progress in achieving the desired outcomes. They maintain linkages between project teams and strategic or business objectives that can change over the course of the project.

Link: Governance of Portfolios, Programs, and Projects | PMI

The structure of the governance organisation for a project should be appropriate to the scale and complexity of the project (no one size fits all). The following are some examples of governance models for different types of projects.

Project Governance Model: Low Complexity

Project Definition - Low Complexity:

• Standardization and technology improvement (example equipment obsolescence). No impact to product or package design. Recommendations: Establish strategic partnerships with key vendors to expedite equipment procurement and services. Watch-outs: If assigning an overall technical lead, need to evaluate soft skills to work as a leader across areas.

8

Project Sponsor

DepartmentManagerOR Regional EngieeringManager.

Finance.

Project Engineer.

Plant Engineering /Ops' Team.

Project Controls.

Technical Lead (Support)

Process/Packaging/Utility/ Facility SME's

Project Specific.

Project Specific.

Equipment Engineers.

GES Support/Interface.

Capital Purchasing.

Legal Support.

Plant QA Team.

Validation.

Plant EHS Team

Construction /Installation Site Management Team.

Construction Site Safetymgt'

Construction Site Team.

Project Governance Model: Medium Complexity >$10 MM.

Project Definition - Medium Complexity:

• Cross-functional projects with product or process development (example line extension). Impact to product and/or package. Recommendations: Establish role of workstream leads and expectations for management of risks, scope/schedule/budget escalation. Watch-outs: Transfer of ownership with site team requires clear boundaries and assignments prior to installation and start up.

9

ProgramManager

Steering Committee / Project Sponsor

NPDProjectManager OR ANSC Project Manager.

Engineering ProjectManager.

Admin/PMO.

Finance.

R&D Project Team

Process Engineering.

Project Controls.

Planning/ALOG/NOLA.

Equipment Engineering.

Utility/Facility Engineering.

Label Development.

HR Support.

PackagingDevelopment.

Legal Support.

Regulatory Team.

Business Systems.

IT Project Team

Materials/Sourcing& Purchasing.

QA Project Team.

Validation.

Commercial/Business Interface.

Operations/Regional Interface.

GES Support/Interface.

EHS Support.

Plant Engineering Interface.

Capital Purchasing.

Construction /Installation SiteManagement Team.

Construction Site Team.

Construction Site Safetymgt'

Project Governance Model >$25 MM and Break Through.

Project Definition - Highly Complex Maintenance/Breakthrough/Evolutionary:

• Highly disruptive, logical progression, significant business impact (example greenfield or brownfield). • Impact to product and/or package - Stage Gate process. Recommendations: Standardized steering meetings and robust communication plan. Experienced program manager needed to align functional needs.

10

Watch-outs: Project sponsor role is critical to Stakeholder Management at executive level and timely resolution of high risks.

HR Support.

Steering Committee / Project Sponsor.

Commercial/Business Interface.

Steering Committee.

Legal Support.

ProgramManager/Director. Supply Chain

Operations/Regional Interface.

AN Engineering Director.

Admin/PMO.

FinanceManager.

R&D ProjectManager.

RegulatoryManager.

Engineering ProjectManager.

EHS Manager.

IT ProjectManager.

Planning

Purchasing Manager.

QA ProjectManager.

GES Support/Interface.

Validation.

Team

Technical Lead .

Team

Team

Process Engineer.

Materials/Sourcing& Purchasing.

Capital Purchasing.

Team

GES SME's.

Packaging Engineers.

NPD Member

Process SME's.

Utility/Facility Engineers.

Packaging SME's.

Others.....

Project Controls.

Construction Site Manager.

Construction Site Team.

Construction site safetymgt'

A key element of Project Governance is communication, most project problems result from lack of communication, and there is a strong relationship between the project progress and the project manager’s ability to manage communication. Communicating effectively means that project information is provided and available in the appropriate format, at the right time and to the right audience. See Section 4.11 Communications Plan. The development of a project’s communication plan sets expectations with stakeholders for how communications will be managed and how it is expected involved parties will interact with each other. Indeed project managers may need support and education on what is expected from them in relation on the project and their role in ensuring that governance expectations are complied with. Expectations should be established early, at project start and properly documented, for how project team members communicate, including various communication methods such as email, telephone, meetings, and technology-related platforms. See Chapter 3. Identify and Analyze Stakeholders. A properly prepared communications plan promotes consistency, productivity, and successful outcomes. The communications plan should be prepared only after there is sufficient understanding of the project requirements and stakeholder expectations. Frequency of communication of different information to different stakeholders and project team including regular status update should be defined in a communications plan. The types of information to communicate/update typically include project status,

11

project scope statements and updates, project baseline information, risks, action items, performance measures, etc. An example of a Communication Plan Template is the table below.

Stakeholder (to Whom)

Stakeholder Need (Why)

What

Where

How

Who

When

In Person

Sponsor, Steering Committee

Informational, Continued support

Management status review

Executive conference room Small conference room

Project Manager

First Monday in a month

Sponsor

Informational

In Person

High level project status

Project Manager

Last Friday of each month

Project team

N/A

Each Thursday

Status sharing and project updates

Project team progress

Video conference

Project Manager

Informational

SharePoint

Document

Bi- weekly

Project team and stakeholders

Project review meeting minutes

Project Manager

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.

12

Identify Stakeholders

Plan Stakeholder Management

Manage Stakeholder Engagement

Monitor Stakeholder Engagement

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 PMBOK methodologies 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

13

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. 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

14

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.

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?

15

• 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.

16

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

17

low level of complexity, based on arguments, discussions, and formal/informal meetings, not any technique.

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)

18

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.

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.

19

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 in order 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 in order to release the product under its specifications, what is verified by the project 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. 3.6 A SSUMPTIONS /C ONSTRAINTS The most common definition for assumption is a hypothesis that is considered true in order 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. The project manager and his team must be aware of the milestones of the project in order to guarantee they happen according to the dates listed in the schedule and do not impact the project success.

20

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

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 in order 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

21

• 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 • 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 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 • Company • Suppliers • Procurement 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 al l your client’s needs as client and sponsor, keeping their engagement. 3.10 S TAKEHOLDERS See Section 2.0 for Stakeholder Analysis assessment guidance.

Useful Links:

• Procurement Documentation Required for PR Approval by L2 – Guide for preparation to engage Procurement

22

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: 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 team members 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. • 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

Useful Links:

Project Charter Template 1 Basic Project Charter Template 2 Detailed

• •

• IT Specific Templates (Business & Technology Services PMO Processes and Templates Library)

23

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

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 r esponsibilities 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

24

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 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.

25