Getting Better at Business Requirements
The approach to process, that forms the basis of skore app, has been used widely in many organizations. It has been particularly successful in implementing large scale ERP and CRM systems. In one example a team, that we have worked with extensively in the past, helped implement an ERP in 6 weeks when the leading Systems Integrators had quoted 6 months!
In project after project we see high levels of success using this approach. A single process model is defined up front and used throughout the project to capture business requirements and communicate those effectively. The documentation is used by the technical team to configure the solution. It is used by the change team to manage the transition. It is used by the business to express their needs.
Yet research, such as this by IAG Consulting, tells us too many projects fail due to poor requirements. Here we explore one reason this happens and introduce our approach to mitigating these issues.
Asking users what they want
A major problem any analyst will find in a requirements gathering project is that the business owners, or users, don’t often know what they want. Of course no one would ever say that outright. You may get the odd “I’m not sure but I’ll know it when I see it.”
Business users are normally full of ideas and thoughts about how a new process or system ‘should’ work. And yet so often, when delivered the product is deemed not fit for purpose. Whose fault was it? The analyst who didn’t interpret what the user asked for correctly?
In any project we must make a number of assumptions and test these as we go. But we still need a start point, and the further down that road we can start the better.
The problem with asking users what they want is that’s actually a very difficult question to answer. These users tend to be immersed in their day jobs. Busy fighting the very fires you’re there to help put out with your new project.
They’ll have lots of ideas, they’ll see lots of things that can be improved all the time. They are probably overwhelmed by things that could be fixed. They won’t have had time to think through which would add more value. What they’d do first and what would have the most impact.
Answering a different question
You approach them when they have little time to spare and other important things that need to be completed. They will not have the time, or energy, to start making sense of what they know. As Daniel Kahneman describes in Thinking Fast and Slow, when asked a question that’s too difficult to answer with an immediate response we default to answering an easier question.
And so your best intention, to gather requirements, through the use of interviews, surveys and workshops can result in a lot of answers to the wrong questions.
Ask users what they do
And here is where a process approach can help. For those already familiar using a Business Process Management System (BPMS) to automate processes this will not come as a surprise. Rather than asking users what they need we ask them what they do. A far easier question to answer and one a lot less likely to be substituted for something else.
As you discuss what happens, and visualize this in a process flow, the users move this information from their minds and out on to the page where they can move on to the next thought. They start to see connections and are reminded of ideas and thoughts they’ve previously had.
The process flow provides context for these ideas and reminds the user of the purpose. While talking about what they do they will find it easier to accurately describe what is wrong. And more importantly provide ideas on how to do it better.
A good process visualization tool will provide a quick and simple way for the analyst to capture these thoughts and ideas against the process. The tool will provide easy reporting so that these important requirements can be reviewed and analysed later.
A further requirement, for an approach like this to work, is the ease with which the user can understand the visualization you are building with them. They will not see and make these connections if the diagram they are looking at is made up of hieroglyphics only an expert will understand.
The process must be simple and easy to understand, providing enough information to accurately describe how things work but not overwhelm or confuse the audience.
Requirements are part of a process
The typical analyst will be familiar with modelling business process flows. However, the use of business process flowcharts tends to be tactical. In the development of a new digital product it may be used to define the flow of data or a user journey.
In the projects where we see the greatest success, process flows are used strategically to guide the project. Hence why they make a good business requirements tool. They are used to describe the work that the organization does and then act as a framework in which we position the requirements for the digital change.
A process diagram is not a deliverable as part of a requirement. Requirements are attributes of the business process.
As such, the process model becomes a point of reference for all stakeholders in the project. It is the model through which the business expresses its needs. The same model the design and development team use to build the solution. And the same model the training team use to manage and support the users once the solution is implemented.
Again this can only be achieved with a process approach that is easy to read and easy to understand for as many people as possible.
A better approach to business requirements
To help others take advantage of this approach we have started to create a general approach to business requirements gathering and definition.
This includes a Business Requirements Canvas, an early stage tool to help understand the purpose of the project, the key processes and any key technical and user requirements. The Canvas informs the project vision and objective, captured in the Strategy Template. And finally the process approach, or IDEFlite, a simple yet powerful approach to process that can be used as the single common framework for the project requirements.