Not a few have cited, over the years, the failure to assess customers’ real requirements as a leading cause for failure in the deployment of new technologies in business or across supply chains. Of course, the crux of the matter lies in the definition of “failure” versus “success” when deploying new technologies, doesn’t it?

 

Think about this

 

When “project success” is defined as completing the deployment of technology on time, within budget, and meeting quality expectations, then what are the things that prevent this from happening?

 

Sometimes the issues are technical. But, in my experience, the more frequent cause is the endless head-scratching and wandering around that seems to occur when some contingent of “customers” (read: users) for the new technology complain that they expected one thing and got another. Frequently, this complaint is accentuated with the cry: “We can’t use this!”

Many times, these expectations were about matters like how screens should look, feel or function; how many mouse-clicks should be required to execute this task or find that data; or how to difficult it is to fetch a particular piece of data (especially when contrasted with the technology being replaced).

 

Much of this dissatisfaction stems from an expectation set—often unintentionally—during a process undertaken very early in the project. That process is frequently called “requirements gathering.”

 

Requirements gathering run amuck

 

Somebody contributing at Wikipedia gotten this definition right. Wikipedia defines “business requirements” as describing “in business terms what must be delivered or accomplished to provide value.” (Wikipedia.org 2007)

 

Unfortunately, in many technology projects today, the so-called “requirements gathering” process has almost nothing to do with “business requirements.” The “requirements lists” that are assembled are, quite often, little more than a list of functions that various staff members are used to in their existing application and are virtually never related to providing business value. Other elements in the “requirements list” are simply “nice to haves” and “wish-list” items from the users of the existing technology.

 

Now, it is certainly true that certain functionality may be essential and, therefore, cannot be lost in transitioning from one technology to another.

 

However, inadvertently setting the expectation that the user’s concept of how a function should work—as they expressed it in the “requirements document”—is the way the new technology will (or, should) actually function leads to a high likelihood that some folks are going to be disappointed when they have opportunity to work with the new technology.

 

Get a professional to do it

 

Clearly, allowing rank amateurs, who may know little or nothing about “business value,” to involve themselves in writing “requirements” is a bad idea. One ought to leave such matters to the professionals. Here are some clear (real-life, by the way) examples:

 

Prepared by Amateurs

Prepared by Professionals

We need to be able to import and export data from the new software

Need ability to import and export data in a meaningful way…. Ability to export meaningful data to the reporting database

We need to have a flexible chart of accounts

Flexible chart of accounts, such as multiple levels of accounts

We need to be able to print production reports

Production reporting capabilities must exist

 

Despite the clear “value-add” of engaging a professional in writing such requirements (tongue firmly in cheek), what is lacking from either the professional’s or the amateur’s list of “requirements” is any hint of the “business value” provided by having these requirements fulfilled by the new technology.

 

What “business requirements” ought to look like

 

Genuine, effective business requirements—requirements that will lead to real business value and rapid ROI (return on investment)—should look something like this, we believe:

 

Business Requirement

Business Value to be Delivered

Implement a supply chain integration and visibility solution directed at reducing stock-outs in the top 20 percent of SKUs (ranked by Throughput) to fewer than 5 per month within 120 days without any increase in our total dollar investment in inventory

Increase Throughput by 12.5 percent where 9.5 percent (over the first 9 months) of the increase comes from recapturing what would have been “lost sales” and the remaining 3 percent (over the first 6 months) comes from Sales Management’s commitment to regain customers previously lost due to what customers deemed to be our lack of reliability as a supplier for these  SKUs

Implement a business intelligence (OLAP) solution to provide the Sales and Marketing Teams with visibility to sales data by customer, salesperson, sales manager, region, product line, SKU, and other demographics for the express purpose of establishing viable market segmentation for use in the development of “irrefusable offers” by market segment (down to a single customers, if required)

Increase Throughput by 22 percent (over 12 months) in accordance with estimates and concepts outlined by the Sales and Marketing Teams without increasing Operating Expenses

Eliminate paper-based picking, packing and shipping in the warehouse with the goal of being able to accurately pick, pack and ship 16 average orders (~117 lines) per hour in order to support increasing Throughput without increasing Operating Expenses

Hold the line on Operating Expenses while increasing the capacity of the our warehouse shipping function to an average of 16 orders per hour with greater than 99 percent accuracy

 

Creating these kinds of “business requirements” sets a much higher standard—and, a measurable standard—for VARs and technology vendors to reach. Product demonstrations become proof-of-concept modeling environments and the vendors are prohibited from throwing out “rules of thumb” about your company’s supposed success, should you buy their technologies.

 

Not only so, but creating this kind of “business requirements” list means your cross-functional “technology selection team” is focused on business results that matter, not what modules should be acquired, what screens should look like, or how many mouse-clicks are counted. This is the kind of thinking that brings real and rapid return on investment (ROI).

 

 

What do you think business requirements should look like? Why?

We would be delighted to hear from you on this topic. Please leave your comments below.

 

Follow us on Twitter: @RKLeSolutions and @RDCushing
LIKE us on Facebook: RKL eSolutions and GeeWhiz2ROI