Let’s start by looking at how requirements usually get started. If you ask Business Stakeholders for their requirements you are likely to hear statements like:
“I want another screen that shows me the manufacturing totals for the day.”
“I want the spreadsheet to show sales for the previous quarter.”
“I want to know how many new employees we have each month.”
Or you get s story like this:
“As the production manager
I want a screen to show me the output of each factory
So that I can see the productivity of all our plants.”
In each of these examples the stakeholder is telling you his perceived solution to some unstated need. You don’t know why the stakeholder wants the manufacturing totals for the day; you are not told what the stakeholder will do if he/she can see the sales. Even the rationale given for the production manager’s story does not really explain the reason for the request.
It is only when you know why somebody is asking for something that you are able to provide value. That is, you can provide a solution which matches the real business need, even thought the real need is as yet, unstated. Any solution that does not meet the real need is a waste of resources.
So let’s consider why people ask for solutions, and what you can do to get to the real need.
First, it is quite natural for a human being to ask for a solution that is close to his own tangible reality. If you are planning a journey you are more likely to say, “Let’s catch the 9:30 bus” rather than, “I want to travel from home to work using the means of transportation that will make the journey in time for me to get to the 10:15 meeting”.
The point is that we talk in tangibles rather than in abstractions.
A key business analysis skill is to listen to the stakeholders’ requests, and then apply analytical and systems thinking to discover the real need. You do this mainly by asking “why?”
“Why do you need the manufacturing totals for the day?”
“So that I can compare the units manufactured with the units sold”
“And then what will you do?”
“I will adjust the manufacturing cycle for the next week so that it covers the projected sales”
The result of this conversation is that the analyst starts to understand the real business need:
“As a manufacturing manager
I can compare the daily units manufactured with the daily units sold
so that I know how much to adjust the manufacturing cycle for the next week to make sure we can fill all our customers’ orders.”
Also please note how much the story is improved by using “I can” instead of “I want”. “I can” points to a need, “I want” suggests a solution.
By applying analytical and systems thinking, the business analyst discovers what it is that provides value to the business. While it seems bizarre, stakeholders often do not ask directly for business value. There are a variety of reasons for this:
For all of these, the business analyst can (and should) ask why the request is being made. By understanding the reason for a requirement, the BA is in a position to provide a solution that yields real business value.
The analyst also needs to explore other possibilities for business improvement. For example, the analyst should suggest innovative ideas for improving the existing business policy. While the BA does not determine business policy, he/she can make recommendations so that the business stakeholders are able to choose the innovations which will provide the most value.
The analyst needs to ask the stakeholder,
“How valuable will it be if we can provide a solution that comes up with a daily adjusted manufacturing cycle to avoid unfilled orders?”
“How many orders are unfilled now?”
“What are these unfilled orders costing us?”
“Are there any other factors that are causing the orders to be unfilled?”
“Would it help if we can correlate the manufacturing schedule with the supplier materials deliveries?”
These kind of questions indicate that the business analyst is using systems thinking – looking at the whole of the business, and the effect of each part on the others – to find the real needs. It is only by finding the real need that the optimal solution can be built. The optimal solution is the one that matches the real needs, and provides the most business value for its cost.
Discovery of real needs is the responsibility of the business analyst. Choosing the optimal solution is usually the responsibility of the stakeholders. Working together, both parties can ensure that they are providing the maximum business value.
21 maart 2017Workshop met BPM-specialist Christian Gijsels over business analyse, modelleren en simuleren met de nieuwste release van Sparx Systems' Enterprise Architect, versie 12.Intensieve cursus waarin alle basisfunctionaliteiten van Enterprise A...
28 en 29 maart 2017 Elke technologie, architectuur en methode heeft een houdbaarheidsdatum. En dit geldt zeker voor de snel veranderende wereld van business intelligence. De laatste jaren is er een schat aan nieuwe technologieën geïntroduceerd, w...
5 april 2017Praktisch seminar waarin Sander Hoogendoorn u laat zien hoe u microservices kunt inzetten in uw softwarearchitectuur.Het nieuwste architectuurprincipe microservices lijkt veelbelovend: verkorte time-to-market, schaalbaarheid, autonomie, u...
17 en 18 mei 2017 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikbare r...
1 juni 2017 Iedere organisatie heeft te maken met het integreren van systemen en applicaties. Maar welke technologie zet u in bij welke vorm van integratie? Guy Crets bespreekt de verschillende oplossingen voor integratie. Integratie van IT-sys...
13 t/m 15 juni 2017Driedaagse workshop over requirements management door James Archer. Opstellen, testen en ondubbelzinnig vastleggen van requirements. Unieke driedaagse workshop over requirements management op basis van de Volere methodiek door Jame...