Over the years it has been cited that - the failure to assess customers' real requirements is 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
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 provide by 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.
Translating Business Pains
Often your staff's pain isn't conveyed properly. It is important to take the time to translate staff pain-points into business value or lack there of. Here are some real-life examples:
|
Pain felt by Staff |
Tangible Translation |
| 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. |
By rewriting the pain-points a clear "value-add" emerges.
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).
RKL eSolutions has a business requirements survey that has been a successful tool to help clients articulate business pains and processes and what you would like from a new business management solution that you aren't getting from your current solution. If you are interested in using the Systems Requirements Survey contact sales@rklesolutions.com for a copy.
