Another reason traditional "requirements gathering" approaches may be unnecessary
As we have already discussed (see prior posts in this series), some of the reasons that traditional ERP – Everything Replacement Project approaches to "requirements gathering" – whether internal or as performed by a vendor or VAR (value-added reseller) – fail to deliver real value or results for the organization purchasing new technologies. Now we want to turn our attention to one other matter that we believe will help you see why traditional approaches to "requirements gathering" may be a huge waste of time, energy and (in some cases) money.Think back to the scenario we described (in a prior post) where some executive makes the announcement regarding his firm's intent to replace their existing ERP software, sending off silo leaders to develop a list of "requirements." Two or three weeks later the firm has assembled a list of 300 or so "requirements."
Unless the organization is very unusual, the truth is that more than 80 percent of the typical "requirements list" contents will be found in some form or other in almost all of the contending software packages to be considered. In the middle market – software designed for small- to mid-sized businesses – there are far more similarities in features and functions across the different packages than there are differences. Furthermore, most of the distinctions (i.e., differences) between the most common competitors in mid-market ERP are to be found around the edges of the application software, not in its core functions. For this reason, it is quite likely that about 80% of the "requirements" collected will be present and therefore little value was added to the process by collecting and documenting such "requirements."
Next, it is worth noting that many of the so-called "requirements" listed by staff from the various organizational silos will not be genuine "requirements" at all. Many so-called "requirements" will be nothing more than what the silo staff is used to in their existing software application. Stating these as "requirements" merely fixes in the mind of staffers from the various functional silos that they can and will all get a relatively precise duplication of existing functions plus added features in their functional domains. This sets many wrong expectations and may lead to demands for modifications and customizations where, in a more open-minded environment, adaptation to new methods or processes would have been perfectly acceptable or even an improvement in itself. Never mind whether any of these now cast-in-concrete "requirements" will actually have any effect on increasing Throughput (T), reducing Inventories or demand for new Investment (I), or cut or hold the line on Operating Expenses (OE) while allowing the firm to sustain significant growth.
[To be continued]
5 comments:
Your view, although contrarian, will one day become mainstream.
I am currently about to enter the "requirements gathering" phase of a backoffice ERP implementation, and one big challenge we are facing is precisely what you mention:
- The vendor wants to make a good impression and please the users.
- IT wants to avoid customizations it will later need to manage.
- The functional users already have in mind what they want.
- Top Management wants us to adopt "best practices" already in use by other companies that use the product to get a quick implementation.
But...shouldn't we focus exploring on what features the software already has and are being used by other companies? If we focus on imposing our "requirements", won't we end up with a customized software of which we will be using only a fraction of the functionality it has out of the box?
--vv
Vic:
Thanks for leaving your comments.
As I state in the series, the first thing your company should be focusing on is "making more money tomorrow than they are making today" with a MINIMUM of additional Investment. To do that, you and your management team need first to determine the answer to one question:
What are the small handful of things that are keeping us from making more money tomorrow than we are today?
Those are the things that MUST CHANGE. Everything else is superfluous.
...
Thanks Richard for your expertise and insight. There are two schools of thought for gathering requirements – you can take a traditional requirements-driven approach or a solution-driven approach. Both approaches have their advantages and disadvantages. The trick is to blend the above approaches to gain maximum value from your ERP investment. Please see the following blog article to see how to develop a blended requirements gathering approach
http://gbeaubouef.wordpress.com/2011/01/09/gather-erp-requirements/
Something else that goes wrong with the traditional requirements gathering process is that most of the requirements are "motherhood and apple pie" -- they are prerequisite for any ERP decision so there really is no need to specify them
Furthermore, most of the remaining requirements are the things staff wish they had had five years ago so, once the system is operational they get the system they wish they had six to eight years ago
There needs to be high level future focussed strategic guidance and high level requirements needs to come from the executive team facilitated by a person with executive and strategic insight who fundamentally has grasped the essence of their business
Your comment, ERP Doctor, is certainly cogent about typical requirements-gathering thinking having a backward focus rather than a forward focus. People tend to identify requirements from their experience and not from what the future should look like.
Post a Comment