The Perfect Business Requirements Document

Smaller organisations with limited project experience may still be finding their feet on the best way to document requirements for their particular business so whether you are trying to develop a template or trying to modify an existing one that is no longer up to the job, here are some tips to help you. For those planning to download one of the BRD templates available online this is also a useful checklist to compare the different ones available. A Business Requirements Document (BRD) is a document that ensures your project meets the needs of the client, end-users and other stakeholders. A detailed Business Requirements Document will create a strong foundation for your project, giving it a better chance of success. The sections listed below are the basic elements of a BRD but most projects usually need many more sections. 1. The Problem rnWhat problem has prompted the initiation of this project? Detail the problem area and clearly define what needs to be changed to solve the problem. Consider what changes need to be included and excluded - this statement will assist with the decision-making process later in the document and throughout the project. 2. The Current ProcessrnWhat currently works effectively as well as those areas that need improvement? What aspects of the current product or procedure do not deliver what the business requires. In many businesses the core functionality is adequate but the reporting output no longer meets the current needs. 3. Business AimsrnWhat do the stakeholders want to achieve with this project? It is important to recognise that this is distinct from the features, functions or processes required and is simply a high-level statement from a business perspective. rn4. Scope and Limitations rnScope creep (i.e. gradually adding to the requirements) is one of the most common causes of project failure so it is vital to clearly document what is in-scope and out-of-scope to prevent any ambiguity and uncertainty amongst the stakeholders. It is also necessary to identify those issues that cannot be solved by the current project, otherwise there is a tendency to think that a single project can be the solution to all problems. This will help to set realistic stakeholder expectations and enable stakeholders to understand which areas cannot be improved and, importantly, why not, for instance because of regulatory reasons or technical limitations. 5. Assumptions rnAssumptions that have been made by anyone involved in a project usually only surface part way through the project when a stage delivery is made. It can be difficult to unearth assumptions that are being made, often unconsciously, in the early stages of a project but it can be done through thorough interviewing and analysis techniques. 6. RisksrnAll projects have potential risks so acknowledging that fact and actively managing risks by monitoring them and putting contingency plans in place is an everyday part of project management. However, clearly not all risks can be anticipated and it is often the unexpected that can knock a project off course. 7. Quality MeasuresrnThe only sure way to measure whether the project deliverable meets the business objectives is to be able to measure the quality of the end product. Depending on the type of project, the quality measures may be different: for a physical product it is relatively easy to define criteria that assess its fitness-for-purpose but it is not so easy for less tangible project deliverable such as new processes or reporting outputs. rn8. Success Criteria rnA project can never be deemed a success unless some pre-defined success criteria have been established – as with quality measures these can be tangible or intangible but the most important aspect is that they are documented near the start of the project and all stakeholders agree that a deliverable that meets these criteria can be considered a success. 9. New ProcessrnIf a project involves a new process that will have to be carried out by staff then those people should be involved right at the start in discussing and documenting how the process will change (or how a new process will work). Documenting the new process can help to identify potential risks and the need for any training. 10. TrainingrnChanges to a working environment that are the result of a major project are likely to require the training of key staff to ensure they understand the new process or product and can take full advantage of the improvements the new deliverable offers. rnA Business Requirements Document is an essential part of project management and how well it is done will contribute to the success of the project.