What Makes a Project Sponsor Approve the Business Requirement Document?

Risk tolerance.   The project sponsor signs-off the business requirement document when the document matches or surpasses the risk tolerance of the sponsor.  Note risk tolerance is relative to the sponsor and changes depending on the risk of the project.  For example depending on the size of the company, a $10M project motivates the sponsor to have a much lower risk tolerance than a $10K project.  Project sponsors could cite several other reasons for variable risk tolerance such as project complexity, resources, etc.  The follow-up question and point of this article is:  Can portions of the BRD be equated to various levels of risk tolerance?

A Proposed Business Requirement Document Risk Tolerance Model

Below is a BRD Risk Tolerance model (Figure 1).  It depicts a cumulative risk tolerance incline starting from a high-risk tolerance (lower left corner) to a low-risk tolerance (upper right corner).  Supporting the risk incline are seven best practices for writing a BRD.  Under each best practice are key words describing the practice; for details see “Verifying Requirements Documentation” (1).  On top of each best practice is a cumulative risk tolerance percentage.  This percentage represents the cumulative risk the project sponsor assumes when BRD components are missing.  For example, a risk tolerance of 50% equates to signing-off a BRD with all the best practices above the percentage (data requirements, transitional requirements, and traceability) missing from the BRD.  Note that for every missing BRD component the probability of defects increases in the deliverable.

Figure 1. Business Requirements Document Tolerance Risk Model

First a Note on Project Risk

Before reading the below examples, note the percentages on the model are the sponsor risk tolerance for a project equated to “allowed” missing BRD components.  As stated before, project risk depends on the characteristics of the project (i.e., size, complexity, cost/benefits, technology, resources, duration, etc.).  The point here is that the project risk may well influence the project sponsor on what is an acceptable BRD.   

BRD Risk Tolerance Model Examples

Below are examples of BRD risk tolerance using the model in Figure 1.      

• A project sponsor may well be justified assuming a high-risk tolerance with the BRD missing various components for a project entailing a small modification to an existing system (i.e., the cost of the BRD should not exceed the benefit of the modification).  
• A project sponsor could assume a low-risk tolerance missing any components in the BRD for a project providing a strategic new service for the business (i.e., product defects will have a major impact to the business).  
• If a project sponsor decides to accept a BRD with only process improvement targets and functional requirements documented, the sponsor assumes a risk tolerance of 70% (i.e., still assuming considerable risk of defects in the product or service).
• And so on up and down the risk tolerance incline.    

BRD Risk Tolerance Model Use

The business analyst can possibly use this model as a guide for management on the level of risk assumed when approving a BRD.  On almost every project, there is a question on how much to document in the BRD.  The answer lies within the range of the project sponsor’s BRD risk tolerance.  Using this model, the business analyst can associate the BRD components with levels of risk tolerance.  With this model plus the characteristics of the project, the project sponsor has enough information on the appropriate risk to assume. 

Can This Model Be Used on an Agile Project?

Agile projects do not generate a formal BRD.  User stories are the basis for iterative development.  However, the product owner (sponsor) needs to consider risk tolerance when reviewing the product backlog and during the retrospective prior to approving the product release.  Questions to consider:

• Are process improvements targets addressed?
• Are specific functional requirements present?  Are they being addressed in business value order?  Are dependencies considered?
• Are nonfunctional requirements measured?
• Are the business rules incorporated within the software decisions, access authorizations, and conditions?
• Are data relationships and cardinalities present in the files?
• If replacing a legacy system, are transitions planned?
• Are the original scope features reflected in the user stories?  Can cost/benefits be linked to the deliverables? 

Summary

What is your opinion of the BRD Risk Tolerance model?  I invite your comments.  Perhaps you prefer a different component order or a different level of percentages on the Cumulative Risk Tolerance line.  If you are a project sponsor needing to know what best practices should be used in a BRD, see the article cited in the reference.   

References

1. Monteleone, Mark (2012), “Verifying Requirement Documentation,”