At the end of the second life cycle stage of this project, detailed planning, a meeting is held with just the project manager and the project sponsor. The purpose of the meeting is to review the detailed plan and identify any future problem areas that will require involvement by the project sponsor.
Don’t feel like reading? Listen to the answers instead:
BACKGROUND
Acme Corporation embarked upon an optimistic project to develop a new product for the marketplace. Acme’s scientific community made a technical breakthrough and now the project appears to be in the development stage, more than being pure or applied research. The product is considered to be high tech. If the product can be launched within the next four months, Acme expects to dominate the market for at least a year or so until the competition catches up. Marketing has stated that the product must sell for not more than $150 to 160$ per unit to be the cost-focused market leader. Acme uses a project management methodology for all multifunctional projects. The methodology has six life cycle phases:
- Perliminary planning
- Detailed planning
- Execution / Design Selection
- Prototyping
- Testing/Buyoff
- Production
At the end of each life cycle phase a gate/phase review meeting is held with the project sponsor and other appropriate stakeholders. Gate review meetings are formal meetings. The company has demonstrated success following this methodology for managing projects. At the end of the second life cycle stage of this project, detailed planning, a meeting is held with just the project manager and the project sponsor. The purpose of the meeting is to review the detailed plan and identify any future problem areas that will require involvement by the project sponsor.
THE MEETING
Sponsor: “I simply do not understand this document you sent me entitled ‘Risk Management Plan.’ All I see is a work breakdown structure with work packages at level 5 of the WBS accompanied by almost 100 risk events. Why am I looking at more than 100 risk events? Furthermore, they’re not categorized in any manner. Doesn’t our project management methodology provide any guidance on how to do this?”
PM: “All of these risk events can and will impact the design of the final product. We must be sure we select the right design at the lowest risk. Unfortunately, our project management methodology does not include any provisions or guidance on how to develop a risk management plan. Perhaps it should.”
Sponsor: “I see no reason for an in-depth analysis of 100 or so risk events. That’s too many. Where are the probabilities and expected outcomes or damages?”
PM: “My team will not be assigning probabilities or damages until we get closer to prototype development. Some of these risk events may go away altogether.”
Sponsor: “Why spend all of this time and money on risk identification if the risks can go away next month? You’ve spent too much money doing this. If you spend the same amount of money on all of the risk management steps, then we’ll be way over budget.”
PM: “We haven’t looked at the other risk management steps yet, but I believe all of the remaining steps will require less than 10 percent of the budget we used for risk identification. We’ll stay on budget.”
Was the document given to the sponsor a risk management plan?
The document provided to the sponsor does not qualify as a comprehensive risk management plan. A well-constructed risk management plan is typically organized, categorizing risks often by their type, severity, or impact. This categorization was notably absent in the document, as highlighted by the sponsor. Additionally, vital components such as the likelihood of each risk occurring, its potential impact, mitigation strategies, and contingency plans are standard inclusions in such a plan. These elements weren’t mentioned in the sponsor-PM conversation. Furthermore, the Project Manager’s intention to assign probabilities or damages only closer to prototype development suggests the document’s preliminary nature. Moreover, there’s no indication that the document entails responses to the identified risks. The Project Manager’s own admission that their company’s project management methodology lacks guidance on risk management plan development implies that the document might not align with standard practices. Thus, it seems the document might be more of an initial risk identification effort rather than a full-fledged risk management plan.
Did the project manager actually perform effective risk management?
While the Project Manager (PM) took an important step by identifying risks, which is foundational to risk management, the approach showcased some deficiencies. A well-executed risk management process typically involves categorizing and prioritizing risks. However, the PM presented a list of almost 100 risk events without any clear categorization or prioritization, making it challenging to ascertain the most pressing risks. Additionally, the decision to delay assigning probabilities and potential outcomes until closer to prototype development raises concerns. Understanding the likelihood and potential consequences of risks early on is pivotal for informed decision-making. Moreover, a holistic risk management plan would encompass strategies to mitigate, transfer, or accept risks and include contingency plans — elements absent from the PM’s conversation with the sponsor. The sponsor’s concerns about the budget used for risk identification further indicate that resources might not have been utilized optimally, especially if some risks become irrelevant in subsequent stages. Finally, the PM’s inclination to rely on future project stages to naturally mitigate some risks suggests a reactive, rather than proactive, approach to risk management.
Was the appropriate amount of time and money spent identifying the risk events?
The Project Manager identified close to 100 risk events, suggesting a comprehensive process. If these risks are genuine threats, this thoroughness might justify the expenditure. However, the sponsor’s concerns highlight a potential inefficiency. The sponsor was particularly wary about the significant resources dedicated to this stage, especially since some risks might lose relevance as the project progresses. The depth of the current analysis is also in question. While numerous risks were listed, the absence of associated probabilities or potential impacts at this stage might indicate an imbalance in resource allocation. It’s essential to weigh these concerns against the project’s high stakes. As a high-tech venture, Acme Corporation’s potential market dominance hinges on a timely launch, making thorough risk identification potentially invaluable. The Project Manager’s assertion that subsequent risk management stages would cost significantly less than the identification phase can provide some context; if these subsequent stages are adequately thorough and stay within budget, then the initial expenditure might align with the project’s overall risk management budget. In essence, while there are concerns about the expended resources, the project’s context and the potential repercussions of overlooked risks need to be factored in to genuinely assess the suitability of the investment
Are there any significant benefits to the amount of work already done for risk identification?
The extensive work undertaken for risk identification in the project offers multiple significant benefits. First and foremost, the identification of nearly 100 risk events offers a comprehensive overview of potential challenges, laying a solid foundation for subsequent risk analysis and management activities. This proactive approach allows the team to anticipate and prepare for challenges, leading to better resource allocation and planning throughout the project. Moreover, a detailed risk identification process can enhance communication with stakeholders. By informing them of potential pitfalls, expectations are set realistically, fostering a trusting and transparent environment. Such a clear understanding of the project’s risks invariably leads to more informed decision-making, allowing teams to weigh potential actions against foreseeable challenges. And even if some risks don’t manifest, their identification means the team remains prepared for any eventuality, providing a buffer against unexpected roadblocks. The experience gained from this thorough identification process can also be invaluable for future projects, contributing to a culture of continuous improvement in the organization’s risk management approach. Lastly, having such a comprehensive view of potential challenges can boost the project team’s confidence, ensuring they move forward with the awareness and assurance that they’re well-prepared.
Should the 100 or so risk events identified have been categorized? If so, how?
Yes, the 100 or so risk events identified should have been categorized. Categorizing risks brings forth a multitude of advantages. Firstly, it breaks down a large list into manageable groups, simplifying the process of comprehending and systematically addressing each set of risks. Secondly, categorization facilitates a focused response. Different categories of risks often necessitate different mitigation strategies. By placing risks into defined categories, more tailored responses can be crafted for each distinct group. This categorization also aids in prioritization, enabling the team to ascertain which categories represent the most substantial threats and which ones necessitate urgent attention. Moreover, categorized risks streamline resource allocation. With risks neatly sorted, resources can be judiciously allocated, taking into account the importance and specific needs of each category. As for how the risks should be categorized, here are some common methods:
- By impact: Risks can be categorized as high, medium, or low impact based on the potential damage they can cause to the project.
- By likelihood: Categorize risks based on their probability of occurrence – high, medium, or low likelihood.
- By source: Risks can be grouped based on their source, such as technical risks, financial risks, operational risks, or environmental risks.
- By phase: If certain risks are more relevant to specific phases of the project, they can be categorized accordingly, like design risks, prototyping risks, or production risks.
- By response strategy: Risks can be grouped based on the intended response, such as risks to be mitigated, accepted, transferred, or avoided.
- By stakeholder: If certain risks are particularly relevant to specific stakeholders or departments, they can be categorized that way, allowing those groups to focus on their specific areas of concern.
Can probabilities of occurrence and expected outcomes (i.e., damage) be accurately assigned to 100 risk events?
Assigning probabilities of occurrence and expected outcomes or damages to 100 risk events is a complex process, and its accuracy is contingent on multiple factors. First and foremost, the precision of these assignments is deeply rooted in the quality and reliability of the available information. For risks with a historical precedent, estimation might be more accurate than for entirely new or unprecedented risks. The project’s inherent complexity also plays a pivotal role. Innovative or groundbreaking projects might lack historical data, making accurate risk estimations more challenging. Additionally, the tools and expertise at hand can significantly impact the accuracy. Leveraging sophisticated risk management tools and drawing insights from seasoned risk analysts or domain experts can greatly refine the estimations. It’s also crucial to recognize the dynamic nature of risks. They evolve over the project’s lifespan, which means an initial low-probability risk might later become more likely as the project’s circumstances change. The intricate web of interrelations between risks further complicates matters. The manifestation of one risk might influence the probability of another, making estimations for a large set of risks even more challenging. Lastly, there’s an inherent subjectivity in risk assessment. In scenarios where concrete data is absent, estimations become partly subjective, and different experts might arrive at varying conclusions for the same risk based on their personal experiences and viewpoints. In conclusion, while it is feasible to assign probabilities and expected damages to 100 risk events, achieving absolute accuracy is challenging. It’s imperative to regularly review and update risk assessments, harness both quantitative data and expert judgment, and employ advanced tools to maximize the reliability of these assessments.
Given the life cycle phases in the case study, in which phase would it be appropriate to identify the risk management plan?
In the provided case study, the optimal phase to initiate and establish the risk management plan is during the “Preliminary Planning” phase. The logic for this is multi-dimensional. Initiating a risk management plan at this point guarantees the early detection of possible risks, paving the way for effective strategic design and resource allocation to manage these risks. Furthermore, the preliminary planning stage is pivotal for foundational decision-making pertaining to the project. A risk management plan at this phase ensures these foundational decisions are well-informed by understanding potential risks. Additionally, stakeholder communication is a hallmark of the preliminary planning phase. Armed with a risk management plan, clarity and expectation setting become more streamlined during these pivotal discussions. Moreover, this early stage risk plan can provide guidance on budgeting and allocation of resources, making certain that sufficient provisions are in place for potential risk mitigation endeavors later on. By setting up the foundations for risk management in the initial planning stage, all following phases, whether they involve detailed planning or prototyping, gain from a distinct path that’s conscious of risks. This results in a more streamlined and anticipatory project development approach.
This case, and questions, is take from the book “Project Management Case Studies – Sixth Edition” – 2022, by Harold Kerzner.
