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:
- for what business process is the analysis relevant (e.g. Payroll, Call handling, Customer invoicing,…),
- what organizational departments will the analysis touch (and for what reason?)
- who are the stakeholders (and why? What have they got to win or lose with this solution?)
- what are the interactions between the scope of your analysis and other actors (context diagram)
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.
- The amount of employee complaints is so high that department X never meets the SLA’s which leads to a loss in reputation of the business unit as a whole.
- Employees don’t understand their pay slip, this leads to anxiety that was already addressed by the unions. If we do nothing, we risk having strikes.
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.
- Reduce the number of employee complaints by 30 %
- Increase employee satisfaction (measured by survey) by 20% before the end of year X
- Decrease the number of pay slip related questions for the call center from 1000/week to 50/week
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.