The more novel your solution—the more your risk identification and mitigation strategy must show considerate and detailed analysis Experienced business developers must apply thorough risk burndown analysis to lessen exposures and overcome customer objections to unique solutions that deserve to win. Let’s say your organization can offer a unique solution in your bid for a federal Government contract. You’d think it might be enough of a compelling reason to grant you the award. Novel solutions and innovations represent more risk than conventional approaches or the status quo. Government technology is generally 5-10 years behind commercial industries. So implementing brand new solutions in a specific agency makes your solution innovative. Even if it’s relatively old technology. Doing something that has never been done is inherently risky regardless of the benefits it might provide. However, if you propose the status quo then how can you distinguish your offering from the competition? And, most importantly, is a business-as-usual approach sufficient to meet the customer’s future needs?
Identifying and Developing Risk Strategies
First, let’s go over what risks are included in most proposals. Many risks in proposals read something like, “All of the deliverables are not submitted on time.” Then, in response, the risk mitigation approaches read something like, “We will submit all deliverables on time.” Obviously, most risks and risk mitigation plans aren’t this bad but many are close. Most risks in proposals boil down to, “we might do a bad job” and our solution is that, “we will do a good job.” Yes, selecting a bad contractor/vendor is a risk to the program. But why would you mention doing a bad job when you have spent volumes telling the evaluators what a great job your company is going to do? Instead, we need to talk about things that are outside of our control that may impact our project in terms of scope, schedule, or budget. Outside impacts to our projects are real risks, and talking about them with proper risk mitigation strategies will demonstrate both understanding, and a higher level of planning.
Risk Analysis Should Be Collaborative
Finding and describing risks is a collaborative effort between the proposal team, program managers, and subject matter experts/front-line staff. These discussions ideally happen during the solution development phase of capture, or pre-sales phase if you’re in commercial sales. The solutions architect, proposal manager, or capture manager who has been cross-trained in proposals should lead the risk brainstorming. This brainstorming can uncover contingencies for use in the Technical solutions and Management approaches. Example topics include:
- What elements of our solution are yet to be developed? Yet to be tested?
- What resources have yet to be acquired? What will they cost, and how long will it take to get them?
- Historically, what risks have been inherent in the type of technology or project we’re proposing?
- What kinds of disruptive events would have the greatest impact on our performance?
Ideas for Finding Risks
Prior commercial application. Federal Government customers will be more likely to accept an innovative solution if it has already been tried in other agencies, on a smaller scale, or in the private sector. It’s very common for solutions implemented in large-scale Government contracts to have undergone practical use in commercial ventures, where tolerance for risk — and prospects for rapid financial reward — are much greater.
Lessons learned and best practices. Corrective actions from your firm’s comparable past performance are an excellent indicator of likely risks and appropriate mitigations.
Accuracy of engineering estimates. Prior estimates — comparing budgeted and actual costs — of Time & Materials (T&M), Firm-Fixed Price (FFP), or Cost Reimbursable-type contracts for delivering a similar solution can highlight risks and costs.
Subcontract quotations. Subcontractors/vendors who specialize in a specific niche can lower risk if their subcontracts/vendor agreements pass the risk of budget or schedule overruns to them.
Earned Value Analysis (EVA). Compare how much of budgeted time and expense has already been spent on a project versus its percent complete. Calculating EVA discrepancies on R&D efforts or analogous contracts can disclose reasons for poor performance.
Root Cause Analysis (RCA). Conducting an RCA can uncover if poor-performance was the result of our work or if the customer influenced the work in a negative way. These scope, requirements, and schedule changes happen all the time, so we must properly communicate the impact of the change to the customer and business leaders. However, RCA’s can also reveal less-than-optimized business processes that are adversely impacting the project.
The Risk Analysis Process
After you have identified and described the risks, the process of risk analysis calculates probability and the impact on the project in terms of cost and schedule. A risk table summarizes the component factors:
- Description – label, short narrative, and an identification number
- Probability – or likelihood, expressed as a percentage, or frequency of occurrence
- Cost in Time – amount of worker hours or days lost as a result of incurring the risk without mitigation
- Exposure – product of multiplying Probability x Cost
Depending on the downside impacts, the cost can also include labor category charge rates for specific expertise needed to resolve, along with the cost of materials for replacements or repairs. The figure below can help you calculate the exposure for each risk by multiplying Probability by Cost.
| Description | Probability | Cost in Time | Exposure |
| 1 – Phase 1 late | 20% | 10 days | 2.0 days |
| 2 – Test failure | 10% | 5 days | 0.5 days |
| Total Exposure | 2.5 days |
This is just one example of determining risk exposure. There are many other examples that you can find for your specific scenario.
Risk Mitigation Plans
You must develop process-oriented and quantifiable risk mitigation plans. One of the most common types of win themes in a proposal is called Common Themes Based on Strengths. This is where we are essentially saying the same thing as our competitor, but we say it better. Details are the most important, and the same is true for risks. An impactful risk mitigation plan is detailed and addresses specific risks. Examples include:
Risk Mitigation Plans
You must develop process-oriented and quantifiable risk mitigation plans. One of the most common types of win themes in a proposal is called Common Themes Based on Strengths. This is where we are essentially saying the same thing as our competitor, but we say it better. Details are the most important, and the same is true for risks. An impactful risk mitigation plan is detailed and addresses specific risks. Examples include:
Processes With Built-in Risk Mitigation
A fundamental principle of agile software development is to discover challenges, errors, and flaws during short iterations, or sprints. The short duration of the sprint (typically two weeks) mitigates the impact of the error, which can be identified and corrected before much damage is incurred. Agile software development practices are in stark contrast to Waterfall, where errors sometimes aren’t discovered until deployment. Agile teams keep a risk register of any problems they encounter.
Backup Resources
There are key people on project leave and there are always supply chain issues. Be specific about the other performers who can contribute, and/or network to use in the event that key components are not available.
Alternative Designs
For a critical subtask or component product, you have a tested solution ready to swap out. The key here is proof that your company has done this before, and if something has gone wrong and how it was remedied.
Communication Plans
Many enterprise or organization-wide projects require a tremendous amount of buy-in and stakeholder engagement. Knowing who to engage at what point in the process may be the key to success or failure in a large organizational change-type initiative.
Surge
Customers can be late with their approvals and/or they can add requirements not initially estimated effectively adding work. Having a bench or network of qualified professionals can get a project back on track if an emergency happens.
Reachback
Projects can stall because a key decision needs to be made. Implementing a problem escalation plan to involve resources outside the project team, such as corporate leadership, administrative support, or outside consultants, can resolve issues quicker and cheaper than the project team spinning their wheels.
For each mitigation plan, your risk burndown analysis must estimate the potential percentage reduction in risk so that impacts can be quantified. For example, you might ask, does the mitigation reduce the likelihood of occurrence or the cost impact if the risk is incurred?
Risk Burndown Metrics and Graphs
After identifying the risk, calculating the exposure, and developing a mitigation plan, now you have to show the customer the quantifiable steps that will reduce the probability and/or impact of the risk. It’s okay if there are multiple steps, and it’s okay if the steps reduce the only probability or only impact. There are many variations of risk burndown analysis graphs, but we will only use one to reinforce the topics discussed in this blog post.
In this scenario, let’s say that we are implementing a new IT solution for our Government customer that is used to operating on 30-year old technology.
A Hypothetical Risk and Impact Statement
Multiple steps in the regulatory process and multiple approvals from separate organizations prevent meeting the initial project schedule. The impact of this risk is significantly extending the schedule and increasing project costs.
Our approach to mitigating this risk includes four steps:
- Our Program Manager will work with stakeholders to form working groups who will be the voice of their office throughout the contract.
- We have built into our schedule extra time to account for approvals in the regulatory process for each major milestone such as: (here we would list out the milestones).
- Our Requirements Specialists will work with each stakeholder group to document epics, user stories, and detailed requirements prior to development work.
- Our Organizational Change SME will work with stakeholder groups to develop training, messages, and workflows to increase the adoption rate and decrease disruption to regular operations.
To finish this chart, the proposal team should expand on our 4 general steps above. This can be done by discussing what problems each step is meant to prevent. For example, what happens if we don’t collect requirements correctly? Then a group of people in the organization may not get the functionality they require to do their jobs.
Make Your Proposal Compelling, With Risk Burndown Analysis
Risk burndown analysis charts and their narratives can be a powerfully persuasive tool. Your goal is to convince your customer that your firm’s solution will work in their environment. Properly describing your risk management plan will convince your customer that you can deliver this solution on time and on budget.
Contact us to learn more.
