When a tennis player talks about hitting the ball early, they are referring to the process of preparing their body, getting into position in advance and then striking the ball on the rise to use its momentum to win the point. In business transformation terms, your business requirements are the equivalent of preparing your body and moving into position in anticipation of playing the winning shot – failing to do it, or doing it poorly, will lead to you missing the point. On the other hand, great preparation should lead to great execution.
We established in our previous blog, ‘Who Needs Requirements? I know what I want!’ that clear, agreed business requirements are an essential component of any transformation project. Now we turn our attention to ensuring that when requirements are produced, they are done so in a way which sets the baseline for transformation.
How to produce effective business requirements
There are some key principles to be applied if business requirements are to be high quality and a useful baseline against which progress, solutions and results can be measured:
Completeness: all the requirements need to be documented to encapsulate the full project scope, including business and non-functional requirements (e.g., system availability, performance requirements, etc.)
Accuracy: requirements need to be unambiguous, certainly not vague, and with sufficient detail to enable the recipient to pick them up and design or build from them, preferably unaided. Here is a real-world example: a pair of glasses frames are required to be ‘black’, but what defines ‘black’ so that someone can deliver the correct type of black? It sounds like we’re watching This Is Spinal Tap, but precisely the right colour code and style is crucial to the final aesthetic of the product and therefore its market appeal.
Expressed in simple language:it is essential that simple language is used to explain them and wherever technical terms are used, those terms should be defined and explained.
Prioritised: it is important to challenge requirements to ensure that only those which add value are designed and built; failure to address this results in waste and potentially failure of the project to deliver the benefits case
Testable: a major element, often missed in requirements exercises, is to give thought to how the requirement will be tested for and/or proven. This doesn’t mean building a test script before you’ve built the solution, rather it is identifying how to test the requirement in order to demonstrate that you know how to do so, as part of validating that the requirement is genuine and worthwhile. Where a significant degree of uncertainty still exists, many projects will develop a proof of concept from which to learn before they embark on full solution development. The key to achieving a truly successful proof of concept is that you must be mentally prepared in advance to take the lessons learnt from the experience whilst potentially discarding the outcomes that result from the PoC
Traceability: requirements must be traceable. They should be evident in the design and build of a solution and should be proven by testing prior to implementation.
Change: no matter how good a job you do of capturing requirements, you are likely to experience some level of change whilst your project progresses, because businesses move on. A strong set of requirements constitutes a business baseline against which you can identify, scope and quote for the impacts change.
Creating requirements traceability
Below you can find Claverton’s model for defining business requirements. It demonstrates how you prepare to manage your stakeholders in parallel with the preparation of the requirements and advocates bringing project teams and stakeholders together to create strong dialog and challenge, culminating in a shared agreement and sign-off exercise.
A core component of this process is the production of a Requirements Traceability Matrix (RTM). It sounds complex but it is really just a simple reference mechanism, often in the form of a spreadsheet, that can be used to prove that your requirements are in place and are well controlled. It should be maintained throughout and updated to reflect the development and testing of solutions to ensure they are ready for release to customers and users. It performs the following functions:
As a list of prioritised business or customer requirements, it transparently explains your detailed needs
It aligns requirements to your target process taxonomy, ensuring that each process step has a defined business requirement – where gaps are identified, they may represent an efficiency opportunity
It can help with supplier selection exercises, by providing a requirements framework for an RFP or a bid process, making it easier for a selection team to choose solutions which are fit for purpose
By mapping solution designs to an RTM, it is easy to see which requirements cannot be met – this is particularly helpful when building technology solutions as you can evaluate the cost/benefit of meeting a requirement in multiple different ways, and make the best choice
An RTM will ensure that no requirements are unconsciously missed throughout the lifetime of a project. They might be deprioritised but if they are descoped or excluded for some reason, the RTM explains why, and what will be done about it in future
It provides a control mechanism through which you can evaluate the impact of change, e.g., when new requirements happen, or existing requirements change, an RTM assessment will help you define, size and scale the nature and cost of the change
It provides the baseline against which contracts with suppliers can be written (requirements documents are normally included in contracts relating to the supply of services, e.g., for management consulting arrangements)
Signing off requirements may be the end of the beginning of the project lifecycle, but it does not necessarily mean that all the requirements will be met. For example, during a subsequent Design Phase it may emerge that meeting a particular requirement is cost prohibitive, requires an excessive service element, or results in significant unjustifiable complexity. At this point, a decision must be made as to whether or not to meet that requirement. If the decision is taken to drop it, the RTM must be modified under change control so that it remains the record of intent.
Conclusion
Strong, well-formed business requirements and a requirements’ control process in the guise of an RTM will help your transformation project set and maintain a baseline against which progress and performance can be measured. They enable controlled change and prevent the chaos which besets so many transformation initiatives. For that reason alone, a strong set of requirements is imperative, the process to produce them must be clear and well executed. Using Claverton’s Business Requirements Management Process is the best way to ensure that your transformation initiative has the best chance of success.
To find out more about any of the points covered in this blog, contact us at info@clavertonconsulting.co.uk or call us on 0117 325 7890.
댓글