As a Project Sponsor, What is Your Documentation Risk Tolerance?

To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question. This article is a follow-up to the BATimes publication, “Verifying Requirements Documentation.” As author of the article, I took special note of a readers comment on providing organizations a continuous process improvement model on composing a business requirements document (BRD). The comment was:

“. I too found some things worth cutting and pasting into some training or checklist material. The post script was prophetic — the environment for BRD seems to be getting squeezed by those who find the whole process too cumbersome and not (lowercase) agile enough. I know of lots of orgs whose risk tolerance is so high that they could never see the ROI in it. I Think much of the great material here could be better digested by some organizations if one applied it as part of Continuous Process Improvement. As you find cause to question your BRD effectiveness, compare your process for creating brd documents to this model. While few organizations are willing to invest in all of this effort up front (and it can be appear to be oppressive), laying this out as the gold standard sets the bar for where you can go. When flaws are found or systems don’t meet expectations, the project closure efforts should certainly involve looking at the shortcomings, comparing to this list and considering what additional pieces should be included next time to avoid the flaws, increase acceptance, or implement a solution that’s more relevant to the customer. ” #Tony 2012-01-25 22:20

This comment caused me to pause and wonder if one could construct a BRD risk tolerance model based on the contents of the BRD. In other words, what is the risk tolerance if only certain best practice components are included in the BRD? And can the BRD risk tolerance be represented as a sliding scale. The purpose of this article is to propose a risk tolerance model as a sliding scale based on what is included in the contents of the BRD.

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.