Implementing a Proactive Risk Program: Establishing a Collaborative Environment

by Cheryl Wilson PMP, PMI-RMP, CCEP

As the first article in this series indicated, a top down approach as opposed to a bottom up approach will provide a solid basis for a success risk environment.  This approach has 4 major steps:

  1. Establish a solid risk management process from the project initiation
  2. Discuss and reassess risk management often
  3. Establish a collaborative environment
  4. Ensure risks are documented as one of the five project constraints

It is now time to focus on the third step of this top-down approach:  Establishing a Collaborative Environment. If your risk environment is established at the start of your project, the teams work collaboratively, processes are well communicated, resources are used wisely, the project team can address the risks that are truly affecting the deliverables and objectives.

A structured and collaborative risk environment from the start will encourage proactive communications. This environment should specifically aim to increase the success of the project team. Tools to improve the performance and effectiveness of our projects can include established reoccurring risk meetings, well established and communicated risk processes, consistent reporting and solid metrics showing risk status.

Risk communication lies at the center of any collaborative risk environment to ensure all stakeholders know how to identify a risk, update a risk, escalate a risk and identify a triggered risk. Without effective communications, no risk management approach can be viable.

In order to be analyzed and managed correctly, risks must be communicated to and between the projects within the portfolio. Communications must also provide information flow between the project and organization, to all stakeholders, and most especially to upper management.

Because communication needs to be pervasive, risk activities should be detailed in the Project’s Communications Plan. If the project is a large or complex, it is recommended that the Project Manager write a separate Risk Management Plan to detail the risk environment. The last article, “Discuss and Reassess Risk Management Often” discussed a detailed framework that should be in every risk program.  In addition to the framework, how often the team should meet to discuss the risks, what reporting will be available to track the risks and what the roles and responsibilities are for each team member? These are all additional areas able to increase project success.

Risk Meetings:  Risk discussion should be an agenda item in team meetings. The duration and how often should be determined by the complexity and size of the project, but risk discussions should be done at least once a week.  Projects where the risk program is managed by the Project Manager and never discussed with the team will show signs of failure quickly as there will risks that are never identified.  Projects that put the risk management on the shoulders of a risk analyst to manage will also show signs of failure as the management of each risk is not with the person that is most capable of mitigating that risk.

As a rule of thumb, here is a simple guide to follow when deciding how often risks should be addressed:

  • High Risks:  At least weekly
  • Medium Risks: At least bi-weekly
  • Low Risks:  At least Monthly
  • Issues:  Daily*

*Triggers are critical to determine if a risk has changed from a future uncertain event to a certain real time event.  Triggered risks should be responded to immediately.  Contingency plans for your high risks should be reviewed to determine if they are still viable or if a new response plan should be effected.

Stakeholder Roles and Responsibilities: If stakeholders know their role and responsibility in the risk process, and manage risks they have responsibility for, the success rate for projects increase.  Too many times, the risk process is done by one person in a vacuum void of key people that came provide valuable key information.

Key roles and their responsibilities within the risk framework:

  • Project Manager (PM): Overall responsible person for the project therefore has overight responsibility for each risk.  The PM is responsible to ensure risks are discussed at project meetings, triggers are in place and risks are monitored. The PM should assign risk owners to each risk to further develop mitigation plans and identify triggers.  The PM has the ultimate responsibility to approve new risks and close those eliminated.
  • Risk Owners (RO): Accountable for managing the analysis of assigned risks.  ROs are accountable for the preliminary risk mitigation plan, or the preliminary issue response plan.  They should ensure all risks and issues are added to the risk register and that it is maintained and updated.  During team meetings, the RO should update the team on their assigned risks.  The RO should be a Subject Matter Expert (SME) on their assigned risks.
  • Risk Action Owners (RAO): The RAO is the person the RO feels is the most qualified to implement the chosen strategy to mitigate the risk. For their assigned risks and issues, they should assist the RO in maintaining and upgrading these assignments.
  • Team Members: All team members have a responsibility to identify risk potentials and bring these risk potentials to the PM’s attention.  All risk potentials should be considered.
  • Risk Source:  The person who identified the risk

Clear, Communicated Processes: Processes for how to identify a risk, how to escalate a risk, how to identify triggered risks and assess a risk should all be clear and communicated to the entire team.  When a team knows how or where to initiate a risk discussion this helps to mature the risk environment of the project.

Reporting and Metrics: The risk program is not static.  Risks identified at the beginning of the project should not be the only risks in the risk register with no progress towards mitigation of these risks.  Reporting should show ALL changes to the risk environment.  Consistent reports will allow the project manager and the team to understand the risk environment and the critical changes needed.  The trigger report will show risks that are liable to become issues thus allowing time to respond if needed.

Suggested reports include:

  • Risk Ownership Report/Risk Action Ownership Report
  • Aging Issue Report
  • High Risk Report
  • Triggers Report
  • New Risks Report
  • Net Risk Index Change Report

Opportunity Risk? Is there such a thing? How do you fit Opportunities into your Risk Framework?

by Cheryl Wilson PMP, PMI-RMP, CCEP

What exactly is an “Opportunity Risk?” and can you fit the managing of opportunities in your risk framework?  The definition of an “opportunity risk” varies across the board and is actually very confusing.  This confusion is based on the fact that opportunities are not really risks at all, but positive potential events on our project or in our organizations.  So, I propose if you are going to track opportunities, just call them opportunities!

We know risk is an uncertain future event.  As Project managers or Risk Managers, we are managing the probability or impact of these uncertain future events.  Our goal is to reduce the probability or impact by strong mitigation strategies, and to avoid the risk from triggering into an issue.   CPJ Stoneman has said often, “It is better to mitigate a risk than to attempt to survive an issue.”

So what do we do with these opportunities and how do we track them in our Risk Framework?  I have often been asked this question.   Opportunities as they present themselves could still be uncertain future events but should not be tracked under the same parameters as risks. Also note that some opportunities can actually increase our risks if we pursue them.

If a project team is going to track opportunities, the assessment will be to monitor the Probability and Gain (instead of impact) and manage not mitigate by:

Capture:   Align the opportunity to the project objectives, assign to appropriate stakeholder(s) to track the probability and gain. (Internal opportunities)

Transfer:  Transfer the possible opportunity to senior management or business development team to make the decision to pursue. (External opportunities)

Ignore:      Pass on the opportunity

Share:       Finding a partner either internally or externally to assist us in exploiting the opportunity.

As opportunities can take the project off track of the original deliverables, a clear risk and opportunity management process should be communicated to the project team.   Opportunity Management is an approach to business development and should be aligned with the organization’s strategic goals.  So the caution is to understand project management as the planning and managing of a unique time based set of activities, while opportunity management is more in alignment with the organizations business needs outside of a specific unique time frame.

Risk Management Maturity Concepts: Discuss and Reassess Risk Management Often

by Cheryl Wilson PMP, PMI-RMP, CCEP

In my series of Risk Management Maturity Concepts, I want to bring you through my experiences of implementing an effective risk program. Recently I worked with a client’s troubled project by putting a risk program in to place. When I ask about what they already had in place and why they implemented it, they indicated: “I have a risk register with 5 columns with 12 risks.”

Using the ideas from my first article in this series, I told them and what I want to emphasis here is that the steps prior to even implementing the risk register are critical in providing the project manager with the tools necessary towards achieving a successful risk program.  Merely having a risk register is not enough and leaves the project vulnerable. You are more than likely to have missed information that you should be managing in your risk environment.

The section on “Inputs” to your risk environment will help ensure your project is ready for issues, contingency planning, government reporting requirements, audits, metrics, etc. These preparations are critical to your risk environment. They can guide you to deciding what is necessary in your risk register.  Every project will be slightly different. You cannot manage every project in the same way.

Since normally your projects will progress through your defined project life cycle, it is critical to frequently reassess the risks as the risk environment never remains static.  Thus, methods of how you identify your risks will change to address this dynamic landscape.

One of the first documents you will discuss and write for your project will be the Project Management Plan.  Within this plan, the risk environment should be discussed in the Risk Management subsidiary plan.  I recommend for projects that are complex, large or in trouble, a separate Risk Management Plan be written and evolved on its own.

As the risk environment is an iterative rolling wave process, the following areas should be addressed in your risk management plan.  Future articles will expand each section in more detail.

  1. Identification of potential risks by utilizing risk tools and techniques. There are many tools and techniques to identify risk potentials, their root causes, triggers, etc.  Depending on whether your project team is in one location, or virtual has an impact on how risk identification will happen. The project team needs to know how to identify a new risk and how to report the risks.  They need to know to whom to report the risk, and the time sensitivity of such reporting.

One area projects have the most problems with is identifying the true risk and understanding the difference between the cause of the risk and the effect of the risk.  Identify the WRONG risk is in itself a risk to the project.  If you are wondering why your project has a long list of risks, but no progress in mitigation of those risks, it is more than likely the wrong risks are stated!

2. Assessment of risks both quantitatively and qualitatively. In order to know the risk potentials that will have the most impact on the project, the project manager and the project team need to prioritize all risks. A common temptation is to skip the methods of quantitative risk assessment—where estimation of risk value is precisely calculated with numerical measures—and only concentrate on a few cheap and easy qualitative methods. Quantitative methods often provide a more accurate image of risk likelihoods and can be critical to the success of risk management and contingency planning. Today’s computers and software can reduce the effort of using quantitative risk analysis.

3.  Prioritization of risks using impact analysis. Prioritization of the risks by assessing their potentially negative impact and the likelihood of occurrence is necessary to effectively utilizing limited risk management resources. There are two common ways to do this. One way is to assess the risk’s impact and probability on a scale of 1 to 5, where 1 and 5 represent the minimum and maximum possible negative impact and in similar fashion, the likelihood of risk occurrence.  The other way is to assess these two variables in terms of low, medium, and high. Prioritizing your risks will enable your organization to focus on the most critical potentials first before tackling others.

4. Design and implementation of risk mitigation and contingency plans. After you have prioritized your risks, develop risk mitigation and contingency plans for the highest potential risks in order to manage, eliminate, or reduce their potential impacts to acceptable levels. Mitigation plans need to tie each risk to scope, time, cost, and quality while identifying mitigation strategies and contingency plan triggers.  You also need to clearly define risk-related roles and responsibilities in terms of risk owners (the person responsible for ensuring appropriate mitigation strategies) and risk action owners (the people responsible for implementing the chosen strategies).

5. Management of the risk environment in order to reduce risk impacts. The last step is reviewing mitigation and contingency plans on a frequent basis to stay abreast of changing circumstances that may affect them. As noted above, it is a best practice to set a schedule for risk discussions, such as weekly for high risks, bi-weekly for medium risks, and monthly for low risks. Another best practice is bringing in internal or external risk auditors, such as quarterly, to evaluate the effectiveness of your risk management and contingency planning. Risk audits will often point out better ways of handling a specific risk so that you can change your mitigation strategy going forward.

In summary, the need to be dynamic in identifying, assessing, and managing the risks confronting your projects is clearly a solid practice of improving project success rates. It is always better to mitigate a risk than attempt to survive an issue.

 

 

 

Mitigating “External” Risks is usually Scoop Creep

by Cheryl Wilson PMP, PMI-RMP, CCEP

Tasks outside of a projects planned objectives, is commonly known as scope creep. Scope creep can originate from several sources and is a leading risk potential. As a review, the project primary constraints are Scope, Time, and Cost, Quality and Risk. Constraints behave in concert based on stressor mechanics. Equilibrium = the projects primary constraints in balance. If one constraint is altered the other primary constraints must be realigned to re-balance. If equilibrium cannot be achieved, projects cannot produce the “fit for use” deliverables. Risk potentials should be categorized into internal and external risks as soon as they are identified.

Internal Risks
Internal risk potentials are risks that fall within the scope of the project. The project manager and the project team have some control over the mitigation plan.

External Risks
Risk potentials that cannot be mitigated by the project manager or the project team are considered external risks. Organizational problems that the Project manager has no control over fall into this category as well as funding for the project. If the project manager or the project team cannot mitigate the risk within their scope, additional resources or funding will need to be applied.

Scope Creep
Because as effective mitigation of external risks normally involve tasks that are outside of the projects deliverables, external risks should be escalated to the program level or the portfolio level for effective management. By trying to mitigate the risk, the result is usually scope creep.

Practical versus Theoretical Risk Management

Dear readers, I am having a very good friend of mine, Mr. CJP Stoneman, lend a hand on our blog today. He has a very interesting thread — one that I think you find quite interesting, informative, and even a bit enjoyable. So, CJ, the deck is yours.

Good evening, folks, this is CJP Stoneman blogging from my homestead in Talkeetna, Alaska. As Paul mentioned, I have a steak to filet so I will get right to the issue.

In reading a recent post by a well-known risk theoretician from the UK, I was again struck by the issue of the practical application of risk management versus the theoretical discussions of risk and uncertainty. This very intelligent doctorate discussed this type of aleatoric uncertainty, that type of epistemic uncertainty, and this type stochastic uncertainty as if it was something that risk practitioners sit around the water cooler discussing every day. The significant difference is that portfolio/program level risk management has to be practical not theoretical or erudite. Explaining risk terminology to risk owners and action owners is difficult enough without the need to segway down the path of academic obfuscation.

Now, having said all that, let me get to the point: risk management at the portfolio / program level is not difficult, mind-bending, or theoretical. It is simply the application of three very simple principles that we teach and implement every day with real world clients and risk environments:

1.    Risks are not bad – only unidentified risks are dangerous,
2.    Risks can only be mitigated, and
3.    Risk management must be proactive.

What these three statements say is that you must be interested, diligent and proactive with respect to the uncertain future events that can and do have the ability to turn your project into a tangled mess of email threads, angry business sponsors, and slipping schedules and budgets. Be interested in identifying those risks that are there in front of you, realize that the largest return on investment for risk management is the reduction of risk impact (mitigation), and doing this in a proactive not reactive manner is the hallmark of successful risk managers.

Finally, if you practice these powerful three concepts of successful risk management, it will not matter an iota if you know the difference between stochastic, aleatoric, or epistemic uncertainty. If on the other hand, if you don’t practice such practical risk management concepts, knowing the definitions and examples of these types of uncertainties will not save your projects or programs from uncertain future events that can have real-world consequences and costs.

Stay grounded, my friends.

CJP Stoneman

Risk Management: Mitigation vs. Response

To reiterate from our last post:

“It is better to mitigate a risk than attempt to survive an issue.”
(CJP Stoneman, 2010)

The purpose of mitigation with respect to proactive risk management is quite simply to undertake actions that will reduce the risk potential’s risk equivalent value (REV) which can be found through the following process:

1.    Constraint analysis: scope, time, cost, and quality (see our previous constraints mapping posts)
2.    Scoring assessment which draws its valuation from the constraints analysis
3.    Determine the risk potential’s REV which is the product of RCI * RPO (see previous post)
4.    Rank order the risks according to the organization’s or project’s prioritization profile
5.    Begin the task of mitigation planning on the highest order risks to conserve project resources

The above process provides several advantages to the project:

1.    Improvement in risk scoring assessment from the subjective to the objective,
2.    Efficient application and utilization of limited project resources, and
3.    Reducing the number of risk potentials for which mitigation planning is required.

As we have stated in prior posts, mitigation can only be applied to future events – one cannot mitigate the past or the present. In similar fashion, response can only be directed towards events that have become reality or triggered into reality. In risk management, one of the most important parameters tracked for each risk potential (in the risk register or database) is that of the risk’s triggers. These are future events associated with the risk potential that are monitored by the risk owner(s) indicating when a risk has transitioned from being an uncertain future event to an actuality or issue.

Thus, once a risk potential becomes an issue, it can no longer be mitigated as it has become reality and must now be managed to reduce its cost and burden to the project. Issues consume project resources that would otherwise be available to support the production of the project’s “fit-for-use” deliverables. This makes issue resolution a double cost to the project as it redirects funds from productive to reactive uses. In short, issues are parasitic distractions to the project’s resources and time allotments.

In closing, proactive risk management directs risk activities that seek to reduce a risk potential in both profile vectors: impact and probability (RCI and RPO). This lowers the overall REV so that if the risk does become reality through the advent of one of its triggers, the burden of the issue has been lightened through minimizing the expenditure of resources for its resolution. So as CJP Stoneman stated above, and we paraphrase, mitigation is better than resolution – it’s all about resource utilization.

In Risk Management, Why Be Proactive?

To put this question in perspective, it is simply stated by a very recent quotation we came across:

It is better to mitigate a risk than attempt to survive an issue.
(CJP Stoneman, 2010)

What Mr. Stoneman is attempting to articulate is that in the practice of project risk management the cost of risk mitigation (reduction of a risk potential’s risk equivalent value or REV) is usually much lower than the cost of issue resolution. The basis for this concept is that once a risk potential has triggered into reality, i.e., has become an issue; the project team is now playing the old game of wasted resources called “catch-up.” An issue is not managed, scheduled, or planned – it is simply resolved in the shortest possible time for least expenditure of project resources. Why? Issues are a distraction or impediment to the over-arching objective of every project:

the production of “fit-for-use” deliverables on-time and on-budget.

Therefore, to be proactive in the project risk management discipline means to spend more time attempting to mitigate risk potentials than to deal with them after they have triggered into reality thereby causing a drain on project resources and funds.

An ancillary question may now be:

How does a project team mitigate a risk potential?

With the recent growth in certification for project managers, there are many answers to this question, but many do not stop and think about the words or phrases they are using to define risk mitigation. In common terms, risk mitigation is the process by which project risk potentials are dissected, understood, and evaluated for the express purpose of reducing their risk equivalent value (REV). A risk potential’s REV is the product of the potential’s risk cost of impact (RCI) and its risk potential of occurrence (RPO). Thus the formula for a risk potential’s REV is:

REV=RCI*RPO

Usually the value of REV is given in terms of cost when RCI is in a monetary currency and the RPO is enumerated as a percentage. The product or REV is thus expressed as the product of cost impact weighted by the probability that the risk potential will occur.

An example would be, say, the RCI or cost of a severe hurricane hitting your data center could be $1,000,000.00 units, and the RPO or probability occurrence is 0.01 or 1% chance of happening given your location, propensity for hurricane activity, soundness of data center structure, and many other factors. The REV would then be the product of RCI * RPO which is $10,000.00 units. The REV now allows the risk management team to prioritize the risk potentials thereby expending the limited risk mitigation funds and resources on those risk potentials with highest REV. The added benefit is that the risk potentials with the highest REVs are the candidates for the largest reduction value versus mitigation resources expended.

In closing, being proactive therefore is primarily focused on mitigation and not on response. Reducing the possible impact (REV) of a risk potential instead of responding to a risk that has triggered, i.e., an issue, is most often, we have found, the best approach and most cost efficient given today’s economic landscape.

Please join us over the next several blogs, for further discussions on proactive risk management topics.

Risk Mapping to Primary Constraints: Mapping Quality Metrics

As the final constraint mapping involves quality and acceptance metrics it is not intended to be the least important – quite the contrary. The quality constraint of projects is probably the most misunderstood and mismanaged of all the primary constraints. While the amount of research and written dissertations on quality is copious and available, for project management specifically, most project managers seem to miss the target.

In short, project quality can be simply defined as the “fit-for-use” criteria determined by the project’s business sponsors or customers used to produce the project’s acceptable deliverables.

As opposed to the current understanding of project quality definitions and activities, quality criteria must be determined and accepted during the initiation phase of the project and not at the end of the project’s lifecycle as described in most project “bodies of knowledge” during the scope verification process.

Parameters: Project charter, WBS, Schedule, Budget, Stakeholder analysis, Lessons-learned, historical archives

Determinations: Risk-adjusted quality metrics for deliverables production,

The implementation of quality activities appears to be an afterthought to most project manager, we have found, that it usually left almost entirely to the assigned quality manager / analyst team member. Quality as defined above must be the focus of every project team member since it is the production of “fit-for-use” deliverables that will achieve the quality benchmark as determined by project sponsors. So mapping risks and issues to quality metrics provides the additional clarity as to the impact that risks and issues will have on the ability of the project to produce acceptable deliverables.

First, in order to achieve this clarity the quality metrics must be well understood and accepted by both the project sponsors as well as the project team. The risk and issues identification at the point when the quality metrics are being defined is usually somewhat embryonic in development.  So it important to execute this risk / issue mapping to quality metrics process repeatedly over the project lifecycle usually after major project milestones or achievements have occurred. The mapping process of risks and issues to quality metrics thus begins with an discussion of the risk or issues expected values (REV) including both the risk cost of impact (RCI), and the risk probability of occurrence.

Having completed the initial risk analysis to produce the REV provides the earliest indications of the associations between identified risks and issues and the quality metrics that define the project’s deliverables. These indications will illustrate the associations that if a particular risk becomes a reality, its REV will have this potential negative impact on this specific quality metric. The project team members that must be involved in these discussions include the:

  • PM (project/program/portfolio) management
  • Risk manager/analyst
  • Business manager/analyst (BA)
  • Key risk owners
  • Quality manager/analyst
  • Business sponsor and key customers

As a prelude to these discussions, the quality SME (quality manager/analyst), risk SME (risk manager/analyst) and BA should provide an initial mapping and impact analysis of each risk or issue and its potential to prevent the production of “fit-for-use” deliverables.

Once the initial analysis is completed by the smaller, more mobile group (quality, risk, and BA), the preliminary determinations are presented to the larger group listed above for their discussions, modifications, and ultimately affirmations of the quality impacts. The approved determinations of this group are instantiated as the risk-adjusted quality metric mappings for the project as a whole, and must be disseminated to the rest of the project team and stakeholders.

We suggest that at this point a quality metric artifact such as a quality metric tracking tool or quality metrics traceability matrix be implemented to provide the project historical logging of the now risk-adjusted quality metrics throughout the project’s lifecycle. This quality metrics traceability matrix is now a parameter to any formal change management process implemented as part of the project’s normal monitoring & management processes.

Risk Mapping to Primary Constraints: Mapping the Budget Impacts

In current times of economic weakness, many projects tend to focus very heavily on the need to bring projects in on-budget over any of the other primary constraints since answering for cost over-runs is usually a reason for a meeting with the organizational senior management team to explain the need for additional funding. The necessity of a clear path from risk potentials and/or issues to the impact that they can and are having on project budgetary expenditures serves as a foundation to address any potential need for additional monies or to plan mitigation strategies aimed at reducing the cost vector of the risks or issues on the project’s budget.

Parameters:  Project charter, non-risk adjusted project budget, WBS work packages, control accounts, budgetary policies, lessons-learned, historical archives

Determinations: risk-adjusted project budget

Mapping of risks and issues to the project budget artifacts should begin with the WBS and WBS database due to the fact that if properly executed, it is the WBS which contains the work packages necessary to complete the project work effort and the assigned control accounts linking the project to the organizational accounting environment. If the project has not completed the WBS as a part of its initiation phase, mapping to the budget, schedule, or scope will be all but an exercise in futility.

The WBS serves as the central work effort artifact for projects seeking to produce “fit-for-use” deliverables on-schedule and on-budget. This should be a primary work activity for the project management and a part of the organizational processes in initiating any project or program.

With the WBS work packages with the assigned control accounts holding the primary bulk of the project’s proffered funding, the following project team members and external budgetary subject experts begin the process of determining the risk equivalent impact on each portion of the project budget. These members should include:

  • Project manager
  • Risk manager/analyst
  • Financial analyst
  • Risk owners
  • Organizational accounting experts
  • Business sponsor(s) and key stakeholders

Each risk or issue is dissected to review the preliminary risk cost of impact (RCI) that was determined during the initial risk or issue identification process. The prioritization of the risk and issues into the most severe RCI’s is only half the process since once ordered, their associated risk probability of occurrence (RPO) needs to be reviewed to provide a secondary sort to ensure the risk-adjustment process does not expend resources on those risks or issues that have a very high RCI, but a very low RPO. The team’s focus should be on those that expose the project budget to the highest RCI while characterizing at least a modicum of occurrence probability.

Lessons-learned and historical archives of previous completed projects can be a significant assistance in this budgetary impact prioritization since what has occurred in the past may offer some indication of the future impact a particular organization can expect to experience. This is standard insurance type actuarial operations.

With the sorted list of risks and issues, the team can now inspect each risk or issue with the assigned risk owner to uncover the overt and/or covert aspects of the risk or issue that would damage the project’s budgetary processes and reserves if the risk were to trigger, or as the issue is resolved. At this point, the weight of an issue’s actuality should be given preference due to the fact that an issue having already become reality is in fact draining project resources diverting them for the useful work of producing “fit-for-use” deliverables.

The use of a scatter plot with the axes of risk cost impact and prioritized probability of occurrence. This is different from the normal P X I plot in that the occurrence probability has been adjusted to take into account both the priority of risk in relationship to other risks, lessons-learned and historical budgetary impact experiences of the organization. The scatter plat will produce a value of those risks that should be mitigated from the need to reduce budgetary impact since in many projects the schedule appears to have more flexibility than the budget in these times of financial due diligence.

Those risks showing the highest placement on the scatter plot can now be analyzed from an accounting stand point to provide the actual budget impact value that when paired with the risk’s risk equivalent value (REV) will produce the needed risk-adjusted budgetary REV. This value becomes the parameter for more in-depth financial analysis to clarify the project’s risk environment impact on the budget and to plan the need and amounts of such contingency funding as management reserves and or “set aside” buffers. (See critical chain budgetary reserves).

Risk Mapping to Primary Constraints: Scope – the Work Effort

As we have discussed in our “time” constraints mapping, all projects/program/portfolios regardless of size or complexity need to ensure the balance between primary constraints is maintained in order to produce the fundamental quality outcome of a project. We call this fundamental quality concept the production of “fit-for-use” deliverables. At MCLMG, we have developed this entire mapping and many other innovative project management concepts in our Deliverable-Centered Project Management (DCPM) architecture.

Parameters:  Project deliverables, Project charter, work breakdown structure (WBS), lessons-learned, historical archives, stakeholder analysis

Determinations: risk-adjusted WBS work packages

One of the earliest artifacts on your project will be the project scope which will support the creation of the project scope statement.  The scope management phase will produce the deliverables and the “fit-for-use” criteria the project will need to achieve customer sign-off by the end of your project. This phase also helps the project manager ensure and communicate the work defined in the WBS and ultimately the project schedule is actually being executed to the level of quality demanded by the project sponsor and/or customer.

To achieve the definition of the project deliverables and the quality metrics, the project team begins stakeholder analysis by completing in-depth interviews to define the project requirements. The project business analyst, if this role is assigned, should be the premier team member involved in uncovering the stakeholder’s expectations and deliverable quality metrics. The outcome of the stakeholder analysis is the draft WBS which can be further refined as the business analyst clarifies the “fit-for-use” criteria discovered during stakeholder interaction.

With the WBS in draft form, the mapping of risks and issues, now being identified during the same stakeholder interaction that defined the deliverables and quality criteria, can begin as each WBS element is further broken down into its lowest form for work effort assignment and execution, i.e., the WBS work package. Mapping risks and issues to each of the WBS work packages, determining the risk expected value (REV), calculating the risk impact deviations, and issue response profiles (costs and schedule) can be achieved to provide the clarification of risk-adjusted decision making defined as a significant benefit of implementing risk to constraint mapping.

At this step, scope verification can now begin. In current project management “body of knowledge” dissertations, scope verification does not occur until the very end of a project with the formal acceptance of the deliverables. We assert that waiting until the end to verify the scope is in and of itself a major risk to the project. Scope verification at MCLMG’s clients occurs when the business sponsor accepts the risk-adjusted WBS and the quality metrics for producing “fit-for-use” deliverables after completing a formal walk-through and/or inspection of the WBS, risk register, issues log, and quality metrics profile. This completes the scope management initialization processes with the dissemination of the approved risk-adjusted WBS (work packages, and database) and the associated risk register and issues log.

Finally and of equal importance, no project or program can exist without the possibility of change; thus, any requested or needed changes to the project scope must go through a formal change control management process.