In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development.
However, when one considers the wider view of organizations concerning information systems, it is common that new software development is not always the primary means of implementing new systems. Organizations do need software for many different functions and data, but a lot of those are common; organizations that realize this do not develop their own software for common needs, they buy it. It actually started a few decades ago with functions like general ledger accounting and human resources, then it moved into more specific domains like insurance or banking, and on into cross-domain ERP packages popularized by major vendors.
When organizations first started to buy more than build, they were often delighted by the time savings: “I can have it now? And not wait 2 years for it to be developed in-house? Where do I sign?” What many organizations did not realize, and their internal IT people probably didn’t see either (at first), was that it was only the pure development and system testing activities that were being saved. There was still the need to determine what the package was actually going to do. While software apps provide many common and standard functions, which ones are implemented, and how they are configured still vary significantly based on an organization’s own needs. Ahead of that, the decision has to be made concerning which package to buy in the first place.
This is where business requirements come in. Again, the focus and discussions about requirements these days is primarily about their role in new software development, such that some organizations forget or discount the need for requirements when buying packages… This is a recipe for disaster.
It is true that companies buy things all the time, and often use a standard Request for Proposal (RFP) process. A common process is a good thing, and proposals for quantifiable products such as hardware or components can be straightforward. An RFP for software, however, is specifying an intangible thing that has to perform a function in a specific way. That means defining complete and correct business requirements.
A web search on RFPs or package implementation failures will quickly identify a primary cause; “Failure to clearly define the business requirements for the project”. (see http://www.orionsecuritysolutions.com/the-o/item/188-request-for-proposal-mistakes).
Even the (in)famous lawsuit between Waste Management Inc. and SAP concerning a failed project included a claim by SAP of Waste Management “failing to timely and accurately define its business requirements” as a contributing reason for the failure.
(see http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments).
So, an organization cannot skip over or pay lip service to business requirements definition in software package projects. Done properly, good business requirements can be used to directly fill the part of an RFP that scares most people: the functionality and data that a package has to meet to be considered for purchase.
When first putting together a list of candidate packages, there may be a lot of vendors who claim to meet your needs based on a summarized description of their products; sending vendors an RFP containing good business requirements will quickly weed out the ones who don’t measure up. Many times, (good) vendors react to this kind of RFP by declining to respond when they see that their product really does not meet the business requirements; this saves both parties time and effort on a deal that would never have gone through.
This will normally lead to a short list of vendors who have a product that could meet the requirements. Getting to one vendor usually involves product demonstrations, on-site trials and other means of evaluation. Of course, other requirements need to be met as well, perhaps technical requirements the software has to meet to run in the desired environment (although hosted and other “cloud” options are changing this). The best scenario is to have two or three vendors whose products will meet the requirements, after which the remaining negotiations can be about getting a good price … all because of having defined the business requirements.
And last but certainly not least, having the business requirements eases the implementation of a package. In decades past, buying a package meant buying code; if alterations to the package were needed, that meant changing code, and getting it to work. This was often difficult and would commonly void any agreement with the vendor to support the package and provide updates.
These days, good packages are built to be configurable. A vendor will often have consultants who can configure the package; and what do those consultants need as input? Your business requirements.
If by chance and very good luck, the project has reached this without having defined the business requirements, they will have to be defined now if the package is ever going to work properly; and there is a very likely possibility that when the requirements are finally documented, it is clear that the wrong package was purchased. That’s when stories about project failures turn up in industry magazines and sites, and even the regular media if the failure is colossal enough.
So, you’re buying a package? Don’t forget your business requirements…
– David Wright, IAG Senior Consultant
(For even more on the importance of requirements, see the Business Analysis Benchmark Study from IAG Consulting, see https://www.iag.biz/resources/library/business-analysis-benchmark.html )
@David, good for you for squarely stating that business requirements are essential for buying software. Indeed many acquirers simply buy off the shelf without defining requirements and thereby rely on the vendors to build applications that presumably are what the buyer needs. For well established uses, such as word processing, such trusting buyers probably won’t suffer from their ignorance.
For applications that are less well-established and in fact reflect more unique variations, acquisition needs to include defining requirements the software must satisfy. I’ve found that most such acquisitions do include defining requirements, which typically then are included in some form of a Request for Proposals (RFP). The RFP’s requirements guide the vendor in proposing software and serve as a basis for the buyer’s evaluation of proposals.
However, a very large proportion of software acquisitions still fail to result in suitable software. In my analysis of numerous failed acquisitions, the main cause of these failures is that left to their own devices, most buyers define the wrong kind of requirements for their RFPs. Regardless whether or not they call them ‘business requirements,’ most buyers in fact define product/system/software requirements, which actually are a form of high-level design. Unfortunately, BABOK® doesn’t help, because like many in the requirements industry, it says business requirements are merely objectives.
When vendors propose products that fit such designs, those products often turn out not to be what the buyer actually needs. Invariably the vendor is blamed, and it’s common for the buyer to repeat the same failure process with the next vendor.