By William Allen
When I first became a project manager, it did not take long to realize the pain associated with a lack of resource availability and cross-functional cooperation. This includes a lack of direct project support from functional areas and having the project work low on their priority lists. There simply had to be a better way for the teams to succeed. A few years later, I became a PMP (project management professional) and then grew into the manger of project management role. As manager of multiple project managers, it made sense to me to attempt to apply project management best practices across all tech transfer projects. After all, I thought, why reinvent the wheel? I made it my goal to apply the PMBOK(Project Management Body of Knowledge) best practices. Initially it seemed daunting, but I gradually realized I only needed to apply those principles which truly added value to project teams which manage the technical transfer process.
For those unfamiliar with the PMBOK, there are five process groups: initiating, planning, executing, monitoring and controlling, and closing. Also, there are 10 knowledge areas, project management of: integration, scope, time, cost, quality, human resources, communication, risk, procurement, and stakeholders.
The resulting project management guidelines are organized according to knowledge areas and contain only those items which best facilitate tech transfer projects. For example, there is a scope document, a timeline, a communications plan, and a risk assessment plan. A scope document lists all deliverables and their associated activities and is organized according to functional areas. The project management office (PMO) is responsible for training team members from all of the functional areas on their responsibilities according to the project management guidelines.
One point to make perfectly clear is that organizational project management guidelines will not work if the organization, from the top, does not endorse and support them. Assigning a project manager to a project, in and of itself, without guidelines, provides no assurance that a project will be successful. My organization at the time fully endorsed and supported the guidelines because they provided a level of assurance that tech transfer projects would be successful, a strategic goal of the organization. After all, a PMO, by definition, defines and maintains project management standards within the organization in order to facilitate organizational objectives.
Pharma organizations are organized into functional areas (i.e., manufacturing, validation, engineering, quality, regulatory, purchasing), as specialized dedication and expertise are required in each area. The guidelines need to provide project responsibilities and expectations for each functional area. Functional areas, like the organization as a whole, have reporting structure including directors, managers, supervisors, and specialists. The assignment of human resources to projects and resulting cross-functional cooperation are necessary for successful CMO project management.
A major CMO objective is to successfully carry out tech transfer projects for their clients. Each functional area has a responsibility within that objective. This requires that functional areas provide resources to project teams to carry out their specialized project goals. The assigned team members are, subsequently, held accountable for project performance by their functional area management.
The guidelines provide specific responsibilities for each functional area. For example, engineering will spec a tank, provide drawings for approval, and perform factory acceptance testing and installation qualification, operational qualification, and performance qualification (IQ/OQ/PQ). Purchasing will ensure the components, excipients, etc. are available per the timeline. Validation will ensure all of their deliverables and associated documents are prepared and executed per the timeline.
When a new project is identified, the project manager contacts each pertinent functional area manager with a preliminary scope of work for that area and requests that resources be assigned to the project. Managers assign resources based on individual workloads and capabilities.
The responsibilities of the various functional area team representatives are outlined in the guidelines. The project manager reviews the responsibilities at the beginning of each project and holds the team members accountable to the deliverables and agreed-upon timeline. General team member responsibilities include attending team meetings, providing action item updates, keeping functional area management informed, and advising of any potential timeline delays. The project becomes part of the assigned team members’ annual performance reviews. Thus, functional area objectives are directly tied to organizational objectives. The project manager continuously keeps the project scope in check and gains buy-in from management if the scope changes. If a resource is not available or if workload exceeds capabilities, the issue can be escalated.
The project manager must take responsibility for managing cross-functional cooperation. This includes strong communication with each team member about expectations and scope, but also includes communication with the management team to assure continued success for the team members, and, ultimately, the team. Gaps in support are escalated by the project manager and by the team member if the scope changes without controls in place. The timeline created by the project manager contributes to an understanding of cross-functional cooperation in that it is organized according to functional areas and shows the interdependencies among functional areas.
Regularly scheduled organizational management project review with managers and directors includes discussions on individual performance issues, functional area workloads, and resource availability. In this way, project goals support organizational goals and functional area goals.
About The Author:
William Allen is a pharmaceutical industry professional with 20 years of parenteral CMO experience. He has managed aseptic manufacturing operations and multiple technical transfer and manufacturing scale-up and compliance projects, gaining and applying expertise in project/program management of start-to-finish parenteral manufacturing.
William has managed multiple cross-functional project teams with all pharmaceutical functional areas, thereby gaining considerable practical industry knowledge. Additionally, he has 10 years’ experience working in clinical laboratories, including clinical microbiology. He has also been a military and college instructor.
William has an undergraduate degree with a major in medical technology and a master’s degree in communications with emphases in technical writing and professional training and development. He has been a PMI (Project Management Institute) certified PMP (Project Management Professional) since 2007.
Visit Audio Recordings for the audio version of this section.
- Identify the major elements in managing project risk.
- Describe the processes for identifying project risk.
- Describe the processes for evaluating risk.
- Describe the processes for mitigating risk.
Managing risks on projects is a process that includes risk assessment and a mitigation strategy for those risks. Risk assessment includes both the identification of potential risk and the evaluation of the potential impact of the risk. A risk mitigation plan is designed to eliminate or minimize the impact of the risk events—occurrences that have a negative impact on the project. Identifying risk is both a creative and a disciplined process. The creative process includes brainstorming sessions where the team is asked to create a list of everything that could go wrong. All ideas are welcome at this stage with the evaluation of the ideas coming later.
A more disciplined process involves using checklists of potential risks and evaluating the likelihood that those events might happen on the project. Some companies and industries develop risk checklists based on experience from past projects. These checklists can be helpful to the project manager and project team in identifying both specific risks on the checklist and expanding the thinking of the team. The past experience of the project team, project experience within the company, and experts in the industry can be valuable resources for identifying potential risk on a project.
Identifying the sources of risk by category is another method for exploring potential risk on a project. Some examples of categories for potential risks include the following:
The people category can be subdivided into risks associated with the people. Examples of people risks include the risk of not finding the skills needed to execute the project or the sudden unavailability of key people on the project. David Hillson1 uses the same framework as the work breakdown structure (WBS) for developing a risk breakdown structure (RBS). A risk breakdown structure organizes the risks that have been identified into categories using a table with increasing levels of detail to the right.
In John’s move, John makes a list of things that might go wrong with his project and uses his work breakdown structure as a guide. A partial list for the planning portion of the RBS is shown in Figure 11.1.
Figure 11.1 Risk Breakdown Structure (RBS)
The result is a clearer understanding of where risks are most concentrated. Hillson’s approach helps the project team identify known risks, but can be restrictive and less creative in identifying unknown risks and risks not easily found inside the work breakdown structure.
After the potential risks have been identified, the project team then evaluates the risk based on the probability that the risk event will occur and the potential loss associated with the event. Not all risks are equal. Some risk events are more likely to happen than others, and the cost of a risk event can vary greatly. Evaluating the risk for probability of occurrence and the severity or the potential loss to the project is the next step in the risk management process.
Having criteria to determine high impact risks can help narrow the focus on a few critical risks that require mitigation. For example, suppose high-impact risks are those that could increase the project costs by 5% of the conceptual budget or 2% of the detailed budget. Only a few potential risk events met these criteria. These are the critical few potential risk events that the project management team should focus on when developing a project risk mitigation or management plan. Risk evaluation is about developing an understanding of which potential risks have the greatest possibility of occurring and can have the greatest negative impact on the project. These become the critical few.
Figure 11.2 Risk and Impact
There is a positive correlation—both increase or decrease together—between project risk and project complexity. A project with new and emerging technology will have a high-complexity rating and a correspondingly high risk. The project management team will assign the appropriate resources to the technology managers to assure the accomplishment of project goals. The more complex the technology, the more resources the technology manager typically needs to meet project goals, and each of those resources could face unexpected problems.
Risk evaluation often occurs in a workshop setting. Building on the identification of the risks, each risk event is analyzed to determine the likelihood of occurring and the potential cost if it did occur. The likelihood and impact are both rated as high, medium, or low. A risk mitigation plan addresses the items that have high ratings on both factors—likelihood and impact.
A project team analyzed the risk of some important equipment not arriving to the project on time. The team identified three pieces of equipment that were critical to the project and would significantly increase the costs of the project if they were late in arriving. One of the vendors, who was selected to deliver an important piece of equipment, had a history of being late on other projects. The vendor was good and often took on more work than it could deliver on time. This risk event (the identified equipment arriving late) was rated as high likelihood with a high impact. The other two pieces of equipment were potentially a high impact on the project but with a low probability of occurring.
Not all project managers conduct a formal risk assessment on the project. One reason, as found by David Parker and Alison Mobey2 in their phenomenological study of project managers, was a low understanding of the tools and benefits of a structured analysis of project risks. The lack of formal risk management tools was also seen as a barrier to implementing a risk management program. Additionally, the project manager’s personality and management style play into risk preparation levels. Some project managers are more proactive and will develop elaborate risk management programs for their projects. Other managers are reactive and are more confident in their ability to handle unexpected events when they occur. Yet others are risk averse, and prefer to be optimistic and not consider risks or avoid taking risks whenever possible.
On projects with a low complexity profile, the project manager may informally track items that may be considered risk items. On more complex projects, the project management team may develop a list of items perceived to be higher risk and track them during project reviews. On projects with greater complexity, the process for evaluating risk is more formal with a risk assessment meeting or series of meetings during the life of the project to assess risks at different phases of the project. On highly complex projects, an outside expert may be included in the risk assessment process, and the risk assessment plan may take a more prominent place in the project execution plan.
On complex projects, statistical models are sometimes used to evaluate risk because there are too many different possible combinations of risks to calculate them one at a time. One example of the statistical model used on projects is the Monte Carlo simulation, which simulates a possible range of outcomes by trying many different combinations of risks based on their likelihood. The output from a Monte Carlo simulation provides the project team with the probability of an event occurring within a range and for combinations of events. For example, the typical output from a Monte Carlo simulation may reflect that there is a 10% chance that one of the three important pieces of equipment will be late and that the weather will also be unusually bad after the equipment arrives.
After the risk has been identified and evaluated, the project team develops a risk mitigation plan, which is a plan to reduce the impact of an unexpected event. The project team mitigates risks in the following ways:
- Risk avoidance
- Risk sharing
- Risk reduction
- Risk transfer
Each of these mitigation techniques can be an effective tool in reducing individual risks and the risk profile of the project. The risk mitigation plan captures the risk mitigation approach for each identified risk event and the actions the project management team will take to reduce or eliminate the risk.
Risk avoidance usually involves developing an alternative strategy that has a higher probability of success but usually at a higher cost associated with accomplishing a project task. A common risk avoidance technique is to use proven and existing technologies rather than adopt new techniques, even though the new techniques may show promise of better performance or lower costs. A project team may choose a vendor with a proven track record over a new vendor that is providing significant price incentives to avoid the risk of working with a new vendor. The project team that requires drug testing for team members is practicing risk avoidance by avoiding damage done by someone under the influence of drugs.
Risk sharing involves partnering with others to share responsibility for the risk activities. Many organizations that work on international projects will reduce political, legal, labor, and others risk types associated with international projects by developing a joint venture with a company located in that country. Partnering with another company to share the risk associated with a portion of the project is advantageous when the other company has expertise and experience the project team does not have. If the risk event does occur, then the partnering company absorbs some or all of the negative impact of the event. The company will also derive some of the profit or benefit gained by a successful project.
Risk reduction is an investment of funds to reduce the risk on a project. On international projects, companies will often purchase the guarantee of a currency rate to reduce the risk associated with fluctuations in the currency exchange rate. A project manager may hire an expert to review the technical plans or the cost estimate on a project to increase the confidence in that plan and reduce the project risk. Assigning highly skilled project personnel to manage the high-risk activities is another risk reduction method. Experts managing a high-risk activity can often predict problems and find solutions that prevent the activities from having a negative impact on the project. Some companies reduce risk by forbidding key executives or technology experts to ride on the same airplane.
Risk transfer is a risk reduction method that shifts the risk from the project to another party. The purchase of insurance on certain items is a risk transfer method. The risk is transferred from the project to the insurance company. A construction project in the Caribbean may purchase hurricane insurance that would cover the cost of a hurricane damaging the construction site. The purchase of insurance is usually in areas outside the control of the project team. Weather, political unrest, and labor strikes are examples of events that can significantly impact the project and that are outside the control of the project team.
The project risk plan balances the investment of the mitigation against the benefit for the project. The project team often develops an alternative method for accomplishing a project goal when a risk event has been identified that may frustrate the accomplishment of that goal. These plans are called contingency plans. The risk of a truck drivers’ strike may be mitigated with a contingency plan that uses a train to transport the needed equipment for the project. If a critical piece of equipment is late, the impact on the schedule can be mitigated by making changes to the schedule to accommodate a late equipment delivery.
Contingency funds are funds set aside by the project team to address unforeseen events that cause the project costs to increase. Projects with a high-risk profile will typically have a large contingency budget. Although the amount of contingency allocated in the project budget is a function of the risks identified in the risk analysis process, contingency is typically managed as one line item in the project budget.
Some project managers allocate the contingency budget to the items in the budget that have high risk rather than developing one line item in the budget for contingencies. This approach allows the project team to track the use of contingency against the risk plan. This approach also allocates the responsibility to manage the risk budget to the managers responsible for those line items. The availability of contingency funds in the line item budget may also increase the use of contingency funds to solve problems rather than finding alternative, less costly solutions. Most project managers, especially on more complex projects, will manage contingency funds at the project level, with approval of the project manager required before contingency funds can be used.
- Risk management is a creative process that involves identifying, evaluating, and mitigating the impact of the risk event.
- Risk management can be very formal, with defined work processes, or informal, with no defined processes or methods. Formal risk evaluation includes the use of checklists, brainstorming, and expert input. A risk breakdown structure (RBS) can follow the work breakdown structure (WBS) to identify risk by activity.
- Risk evaluation prioritizes the identified risks by the likelihood and the potential impact if the event happens.
- Risk mitigation is the development and deployment of a plan to avoid, transfer, share, and reduce project risk. Contingency planning is the development of alternative plans to respond to the occurrence of a risk event.
 David Hillson, “Using a Risk Breakdown Structure in Project Management,” Journal of Facilities Management 2, no. 1 (2003): 85–97.
 David Parker and Alison Mobey, “Action Research to Explore Perceptions of Risk in Project Management,” International Journal of Productivity and Performance Management 53, no. 1 (2004): 18–32.