How to: Writing Risk Analysis for Business Proposals

by Editor

Risk assessment creates problems for proposal writers. When responding to a Request For Proposal (RFP), you need to identify all known risks but also flag how these will impact other projects and deliverables. Your response also needs to discuss how you will mitigate against this; in other words, if you were awarded the contract, what measures would you take to reduce the risks.


Outline the Costs. Provide line item details and daily rates

It’s a challenging area for bidders as you don’t want to seem too negative but… you need to demonstrate that you understand the risks and have the expertise to control them.

Risk Assessment in RFPs

You can discuss the risks by breaking them down as follows:

  •  Risk Number – provide a unique number to each risk. This helps track it across all procurement documentation.
  •  Category – identify a set of categories and place each risk into its own category.
  •  Detail – use this section to describe the risk in detail and how it relates to the requirements as identified in the Request For Proposal.
  • Impact – highlight where it impacts the solution and what other issues need to be addressed.
  • Mitigation Actions – finally, include a section that discusses the steps you will take to reduce this and minimize disruption to services.

Risk Analysis: Number

Use a numbering system that it easy to track in both Microsoft Word and Excel. Avoid complicated numbering systems as these take time to manage and update. If possible, cross reference the risks to the requirements.

 Risk Analysis: Category

Examples of categories include:

  •  Mobilization
  • Project Management
  • Client Input
  • Organisation
  • Functionality
  • Acceptance
  • Schedule
  • Budgets

Restrict the number of categories to keep it manageable.

Risk Analysis: Level of Detail

Discuss the risk in detail so the reader understands your concerns and later the mitigating actions you’re going to take. Here are some examples from a previous project:

  • Number of people that will join the project. Risk that there will not be space or facilities for them.
  • Deadlines are aggressive. The solution needs to be in place by September 2012.
  • Client’s resources are either not available to participate from the start or participate at different stages throughout the project.
  • Unclear contractor responsibilities result in less effective project management.
  • Change is not managed in a controlled manner.
  • Security audit requirements; may take several weeks.
  • Parallel project (which we are dependent on) is delayed.
  • Scope changes.
  • Client is not prepared for acceptance on completion of User Acceptance Test (UAT).
  • Client does not deliver test environments before start of the Technical Design phase.

Risks Analysis: Impact

The next step is to discuss how these may impact the project’s success.

  • Lack of preparation may result in delays.
  • Delays will result in negative perceptions in staff.
  • Delays will impact timelines and costs.
  • Scope creep results in delays and unanticipated complexity.
  • Security audit may impact the project’s timelines and thus project costs.
  • Project team does not have the required information before technical design begins.
  • Impacts to project timelines
  • Impacts to costs.
  • Impact delivery timelines.

Risk Analysis: Mitigation Actions

So, how do you mitigate against this? Here are some examples:

  • We have successfully delivered projects for Government clients, such as [project name]
  • We have the experience of meeting tight deadlines. We can ensure that each stage is managed tightly and produces the right inputs for the next stage.
  • We have will work with you to ensure that there is adequate notice of when all client resources are required.
  • We have the experience to provide the cohesive project management capability that you require.
  • We have has experience of working with and managing third parties to work together as a coherent and productive team and to successfully deliver projects.
  • Monitor scope in order to ensure successful delivery.
  • Baseline and agree the scope of the project during the Scope Definition phase.
  • We are accustomed to planning audits and designing solutions that meet these security audit requirements.
  • We have has taken into account your readiness date when planning.
  • We can work with you to manage any issues relating to project overlap.
  • We are accustomed to building solutions that need to interface with third party solutions.
  • We have can work with you to monitor any impact on parallel projects.
  • We will help prepare the UAT user group for conducting UAT with a view to acceptance on behalf of the organisation.
  • We will ensure that you are aware of the timelines by which environments are required.

Conclusion

When writing the risks section of the proposal, it’s best to present the information in a table format. Creating a table (possibly in landscape format) will help the evaluation team examine the risks and, if necessary cross reference them back to the Request For Proposal’s requirements.

What else would you add?

How do you identify risks? Do you use a specific numbering system? How do you discuss the mitigating actions?

Previous post:

Next post: