Many people think process analysis and optimization should be done before embarking on a software project. This article explains why it is unnecessary when buying cloud or commercial off-the-shelf software.
When an organization wants to improve operations, they can be faced with the choice of buying software or writing their own. If they decide to write the software themselves, early phases of the project involve business process analysis and optimization. However, writing software is an expensive and risky proposition for most organizations. Sometimes they can’t even finish what they start; for example see "An IT failure unicorn: Endless 19-year project in Massachusetts" by Michael Krigsman. If suitable software exists, it is usually far cheaper and less risky for an organization to buy the software than to write it themselves.
The process analysis question
The question is this: should business processes be analyzed and optimized before gathering requirements for the new software? We would argue that in most situations this is not necessary. Doing so does not add significant value to the software selection process, and will delay the production rollout of the new system.
When buying cloud or off-the-shelf software that is a good fit with requirements, most of the needed business processes will already be built in. The software vendor will have developed them with inputs from multiple customers. Many of these processes may have been optimized in the form of best practices, and may be better than existing processes used by the acquiring organization. The software may include "unknown processes" that nobody in the organization had even considered, but turn out to be very useful in practice.
Instead of spending time on business process re-engineering, process owners should document their needs in detailed requirements. One of the biggest causes of delays and corresponding cost overruns with major software purchases is discovering “new” requirements during implementation when they should have been found during the requirements analysis phase. If these requirements can't be met out-of-the-box, then the implementation team attempts to satisfy them with system configuration, add-on modules, 3rd party products, developing code or business process re-engineering. All this extra work takes time, and discovering too many “new” requirements is what causes a 9-month implementation project to turn into a two-year nightmare.
One of the best ways of discovering requirements is to use the technique of reverse engineering features from potential products back into a detailed list of requirements. Next, the process owners rate those requirements for importance. Then RFIs are sent out, and vendor responses captured. Finally, the gap analysis is done by scoring potential products against the requirements, and the winning product selected. This assumes each business process owner knows their processes well enough to judge how important the requirements are to the organization. Note that this is not always true in smaller, fast-growing companies. In these situations external help is needed, e.g. from consultants with experience in those particular business areas.
The core of the argument
The reason you don’t need to do the process analysis in the requirements phase of the project is because those processes are already built into the software. Few business processes are unique, and there is a reasonable probability that many of the processes will already have been optimized in the new software, meaning that the effort put into re-engineering those processes was a waste of time that only delayed the production rollout of the new software. In addition, any process optimization would have been done in a vacuum, without contextual guidance from the new software.
Rather, the time can be spent more effectively on a thorough requirements analysis. This analysis should uncover and express all the processes as requirements, and ensure no new requirements will be discovered during implementation. Then the various process owners must decide how important those requirements are to their operations. If detailed requirements are known before the implementation project starts, they will be planned for rather than causing unpleasant surprises during the implementation. In addition, a more detailed requirement analysis may result in selecting software that is a better functional fit for the particular needs of the organization.
When purchasing software, business process analysis and optimization should be left for the implementation stage of the project rather than being done before the requirements gathering phase, because the purchased software has a significant impact on how processes are implemented in that system. The software vendor’s best practices may obviate the need for much of the analysis and optimization work. The time saved by avoiding that unnecessary work may result in the organization selecting software with a better functional fit, and enjoying the benefits of the new software sooner rather than later.
This article was originally published on CIO.com on June 29, 2015, and was updated on September 28, 2016.