With the latest research indicating that over half of all software development projects don't deliver what users wanted due more often than not to a breakdown in the requirements gathering process, investigating alternative methods should be high on the agenda of any organisation about to embark on a new software project.
Although there are some powerful established techniques available to analysts and developers to help them analyse and define requirements, it is alarming to see over and over again that the software delivered did not match the users' needs. Perhaps this is indicative of the fact that most organisations don't know what they do. In other words, they know what they want but they don't know what they need.
Our job therefore during the requirements analysis phase of the project is to identify the client's business processes and document them. We do this using the Business Optix. We build and fully document the business processes with interactive audience participation and we find that this technique produces immediate results. We then allow stakeholders to review the business processes and add feedback through the Business Optix library portal. We can incorporate this feedback into the processes present it to the users again for review using the powerful Business Optix 'before and after' review capabilities. We refer to this activity as "Prototyping the Process".
Over the years we've developed this approach for capturing this kind of information in an efficient and effective way. There are a number of advantages to this:
* We find out as much out about the process in the shortest possible time.
* We achieve buy-in from the relevant stakeholders for the process that we design for them, resulting in a strong feeling of ownership.
* The client gains a deeper understanding of the format of a BPM process
* We identify and resolve any disagreements within the group regarding the existing process and how it should function.
By the time we've finished our prototype, not only is the actual business process fully documented, but everyone has a much clearer idea of their own responsibilities in relation to others in the process. The overwhelming benefit we bring to the organisation is that when the process is documented and the client wants to automate what they do, there's no confusion about requirements, and we are able to use the prototyped process as the basis of the system itself.
The BPM system that is deployed is therefore much more easily understood by users and managers alike. If the process subsequently needs to be changed or improved, the revised procedure can easily be prototyped from the existing system, and the cycle starts again.