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”.
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.
(For even more on the importance of requirements, see
the Business Analysis Benchmark Study from IAG Consulting, see http://www.iag.biz/resources/library/business-analysis-benchmark.html )
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…
