Writing the Risk Analysis section for Business Proposals

risk-analysis

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?

Free and Premium MS Word, Excel and Apple iWork Templates

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan