How to Improve your process for developing business requirements
By Ed Fenwick
Vice President, Insurance Practice
There is little debate and a high level of
agreement these days that new technology and old processes will not
yield the desired business results.
Here’s the question we are hearing increasingly:
Should we implement the technology around existing processes, learn
and understand what the technology can do, and then redesign the
processes and adapt the technology? In other words, where is the
proper home for process redesign in the technology implementation life
cycle?
The “install now, redesign later” approach is
often fostered by technology vendors. They propose this approach for
several reasons. They want to get to the “installed” state ASAP, book
the revenue and move on. Their sales and marketing are often built
around the theme of “our solution is plug-n-play with built-in
industry best practices templates.” The fundamental problem with the
“install now, redesign later” approach is that it’s almost certainly
going to kill any economic benefit of implementing the technology.
Going through two development cycles—one to get
it installed now and one later to adapt the redesigned processes—is an
almost certain ROI killer for most technology initiatives. While this
approach is often fatal to an acceptable ROI, there is often plenty of
support for it from within the organization. Management teams often
fight the budget wars for several years to get funding for a given
technology. As a result, they want the shortest path to implementation
once the green light is given to proceed.
An even bigger motivation for this approach has
its roots in the inefficient and ineffective process that most
organizations have for implementing technology. The process generally
yields poorly developed requirements which yield poorly developed
solutions—with the result being delayed implementation and poor
business results. Adding redesign to that faulty process can seem to
be a needless risk.
The solution and the proper home for process
redesign can be found in your organization’s requirements development
process. Improving this process is critical to optimizing the benefits
of any technology initiative. Here are some key aspects of a business
requirements process that can efficiently and effectively incorporate
process redesign:
 | Business requirements definition starts with defined business
processes, both the as-is and the to-be. |
| Standard tools and methodologies are used to define both the
business processes and the requirements. The methodologies and tools
need to be model-oriented; words alone cannot properly convey the
proper detail and context of any process or requirement. |
| Costs, benefits and other key operating metrics are attached to
the business processes and the requirements are managed closely at
each stage of the technology initiative, not just at the beginning
and end. |
| User-acceptance testing is derived from the business
requirements and is thoroughly tested. An organization that has a
business requirements development process with the above
characteristics can easily answer the question of when to redesign
business processes. They do it as part of the development effort
with no additional risk, delays or costs. |
