Risk Assessment Frameworks

Risk assessment in proposals is the practice of naming what could go wrong, estimating the probability and impact, and proposing mitigations — before the engagement begins. The risk assessment is not defensive. It is the section that demonstrates technical maturity. The client who sees a risk assessment thinks "they have done this before and they know what to watch for." The client who sees a proposal without risk assessment thinks "they are either naive or they are hiding something."

1. Technical Risks Integration complexity, technology maturity, performance at scale, data quality, and the gap between the client's documented API and its actual behavior. Each risk is specific: "The client's ERP API documentation was last updated in 2023. Undocumented changes may require 1-2 weeks of additional integration effort." Specific risks are credible. Generic risks are filler.
2. Organizational Risks Stakeholder availability for decisions, client team capacity for testing and feedback, change management readiness, and organizational politics that could slow approvals. These risks are often larger than technical risks and always harder to discuss. Frame them as dependencies: "The Phase 1 timeline depends on the client's data engineering team being available for 10 hours per week during integration testing."
3. Risk Register Format For each risk: description, probability (low/medium/high), impact (low/medium/high), mitigation strategy, and residual risk after mitigation. The risk register is a living document — updated throughout the engagement as risks materialize, are mitigated, or new risks emerge. Include the risk register in the proposal appendix and reference the top three risks in the executive summary.