Do you recognize the following situation? You are involved in a project and, based on a slide deck or analysis document, you need to decide on the way to go. After reading the content, you don’t feel like you’ve fully grasped it and you don’t feel comfortable at all to take a decision. In this article, I’d like to share 3 practical tips to increase the value of any change/requirements document, enabling faster and more confident decision taking for stakeholders.
A common pitfall in writing requirements or specifications in my experience is: once the analyst has taken a deep dive in the content and gets convinced of a solution, it is very tempting to shortcut the rationale on how this particular solution contributes to solving the business problem. Instead he just describes what needs to be done (e.g. implement feature X, build interface Y,…).
Worst case, the analyst has taken some false assumptions during his analysis work, leading to solutions that later on turn out to be suboptimal (or even wasted) investments. The lack of business context in the decision document makes it impossible for the decision taker to ensure the solution is aligned with the problem. Therefore it undermines the last chance in turning the project before wasted investments are made.
In my assignments as business consultant, I’m regularly asked to coach colleagues in business analysis techniques, not seldom after a case similar to what I’ve described above occurs.
Very recently, I’ve advised a project colleague in revamping a functional specification document he'd made by adding 1 chapter at the beginning of his document. The 3 paragraphs in that chapter will increase the analyst’s efficiency dramatically and will ensure an ROI to the things that really matter for the stakeholder/sponsor. I would like to share this advice with you. Don't worry, you don’t need to be fully trained in any business analysis methodology or design framework to apply this. The only things you need are some common sense and the will to do the right thing for the company and its customers.
Here we go, the content of this ‘Requirement chapter’ should be:
This paragraph puts the reader in the right mindset. It describes (in words and/or an image) in what context the analysis document is situated. It should not contain any detail about the solutions in place, this will come later. It’s just the first start so that the reader is put in the right direction.
What you can include:
Now that you have the context right, you can continue to describe the problem you are trying to solve in this context.
This paragraph describes as clearly as possible the pains and problems the business is currently facing with their impact (for a stakeholder).
It’s this PAIN that we will try to alleviate by putting a solution in place. The reason we mention this information is to make it possible for a sponsor/decision taker to decide if the PAIN is worth an investment for change and if so, how much money he is willing to invest. A common pitfall, however, is limiting the description of the PAIN to application behavior or end user experience only. This is not where it really hurts, we are looking for the effects on business performance.
Some examples:
By clarifying the PAIN, we have reached consensus on the issues to solve. Next we will state the objectives for the project. These objectives will make clear what we want to realize, again without talking about solutions yet.
This paragraph describes what we want to achieve by implementing a solution. A business objective is a clear expression of a desired state without description on how this will be realized (again, we make full abstraction of the solution). A business objective should be as SMART (concrete, measurable, no room for ambiguity) as possible. The reason we add this, is quite the same as for the business pain. We want to ensure that everyone (especially the decision taker) is on the same line about the ‘WHY’ of the change and what added value it promises. Making the objectives clear will allow us to verify/challenge if the proposed solutions will be able to meet the objectives.
Some examples:
You're done. Now that you have elaborated the business context, you're ready to start describing the right solutions that will tackle your business problem and will really bring the value that your stakeholder expects. And if he doesn't agree with what you've written, this is an excellent opportunity to straighten things out and get back to the drawing table.
Thank you very much for reading this article, I truly hope it proves to be useful in your upcoming professional challenges.