The New ERP – Part 37

In an article posted on the Web in October 2009, Carol Francum states, "A quick search of CIO magazine's website turns up more than 200 entries for the term 'Project Plan' and even more for 'Project Success' and 'ERP Project.' Many of these articles point out that 'scope creep' and the failure to assess customers' real requirements are the biggest reasons projects fail. Other articles focused on selling users a particular tool for project management. A recent blog asserts that ERP project success may be defined as completion, regardless of the ROI or performance improvements which may or may not have been achieved." [Emphasis added.] (Francum 2009)

Apparently, from what Ms. Francum reports later in the same article, there is not really much agreement among traditional ERP – Everything Replacement Project project managers as to which factors are, in fact, "critical" to project success:

• Just over 1 in 5 traditional ERP project managers said that "accurate requirements definition" was a primary success factor
  
• About 1 in 6 each cited one of the following as "critical" to traditional ERP project success –
  
  • Upfront project planning
    
  • Stakeholder commitment and alignment
    
  • Subject matter expert involvement
    
  
  
• And, about 1 in 7 traditional ERP project managers seemed to think that understanding and documenting the "as-is" versus the "to-be" business processes was "critical" to success
  

What is it about "business requirements"?

Another author, Todd Boehm, tells us this about "requirements gathering" in a traditional ERP – Everything Replacement Project: "One of the most important steps of any software project, especially the choice of an ERP system, is to gather requirements. You need to know what is needed, what is wanted, and what you can do without…. The definition of ERP is very loose, and could include modules that you don't need, or not include modules that you will eventually want." (Boehm 2010)

Now there's an encouraging word: If you opt for traditional ERP, you might end up buying "modules that you don't need" on the one hand; or the application may "not include modules that you will eventually want." There are two problems with this statement:

1. Buying "modules" – or any functionality – that your organization does not need to add or change in order to increase Throughput, reduce Inventories or the demand for new Investment, or cut or hold the line on Operating Expenses while sustaining significant growth is pure waste. It certainly should not be done because someone in the organization, no matter how influential or how highly ranked, simply says they "want" or "need" the additional functionality.
   
   
2. This brings us to the other problem with the statement, and that is the use of the word "want" with regard to the modules that may potentially be missing in a traditional ERP offering. Decisions intended to bring improvement – that is, decisions focused on helping a for-profit organization make more money tomorrow than they are making today – should not be predicated on "want." It makes no difference the title of the one "wanting" the capabilities. If the capability cannot pass must when scrutinized under the R.O.I. (return on investment) challenge, it should not be purchased – now or ever.
   

The good news is that at least someone writing for Wikipedia seems to have gotten the basic concept right. Here's the definition of "business requirements" from Wikipedia:

"Business requirements describe in business terms what must be delivered or accomplished to provide value." (Wikipedia.org 2007)

I confess: I really like this definition. It is too-the-point and leaves nothing essential out.

In almost all of the literature surrounding traditional ERP – Everything Replacement Projects the missing element is a strong connection between the changes being effected through the deployment of the new – and costly – technology and "what must be delivered or accomplished to provide value." And this critical element for "business success" – not to be confused with "project success" – is missing despite the fact that traditional ERP consultants frequently make a point about involving business owners and managers in the "requirements gathering" process.

My strong sense, in speaking with a large number of executives and managers over the last 25 years, is that they calculate ROI on traditional ERP something along these lines:

"Our business is presently growing at X% a year and we believe (or "think") that if we replace our existing ERP system with a newer and fancier ERP system that we can make more money."

This "make more money" part is usually predicated on more rumination about "making more sales" or "reducing expenses" in some ethereal form. There are almost never any hard facts or numbers put on paper as to the expected results.

What "business requirements" should look like

No.	What must be delivered or accomplished?	What is the expected business value to be delivered as a result?
1	Implement a supply chain integration and visibility solution directed at reducing stock-outs in among the top 20% of SKUs (rated by Throughput) to fewer than 5 per month	Increase Throughput by 12.5% where 9.5% (over 9 months) of the increase comes from recapturing what would have been "lost sales" and the remaining 3.0% (over 6 months) come 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
2	Implement a business intelligence (OLAP) solution to provide the Sales and Marketing Departments with visibility into sales data by customer, salesperson, sales manager, region, and other demographics for the express purpose of establishing viable "market segmentation" for use in the development of "irrefusable offers" by market segment (to a single customer, if required)	Increase Throughput by 22% (over 12 months) in accordance with estimates and concepts outlined by the Sales and Marketing Departments without increasing Operating Expenses
3	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 warehouse shipping function to an average of 16 orders per hour with greater than 99% accuracy

Please note that the "business requirements" in the examples above contain all of the key elements listed in the Wikipedia definition. Further, note that these are all measurable. And because they are all measurable, it is not only possible for the management team to determine whether the resulting IT project was a "success" based on project-related measures such as on-time, within the budget (for establishing budgets, see other posts in this series), and of acceptable quality. The management team can also measure whether the "improvement project" was a success from the standpoint of having achieved its forecast business objectives.

There is no way to write a comprehensive set of "business requirements" that would be parallel to this in a traditional ERP – Everything Replacement Project. The reason is simply that the traditional ERP approach results in too large a project covering too many changes within the organization. Some of the changes will, undoubtedly, produce negative results if reduced to such definable metrics.

Think about this next time you are asked to write "business requirements" for someone's proposed IT project. What will be your management team's measure of "success"?

Works Cited

Boehm, Todd. Gathering ERP Requirements. January 01, 2010. http://worldclasstech.wordpress.com/2010/01/01/gathering-erp-requirements/ (accessed January 02, 2010).

Francum, Carol. Revving your engines: Tuning up your ERP project plan. October 26, 2009. http://searchoracle.techtarget.com/news/1372186/Revving-your-engines-Tuning-up-your-ERP-project-plan (accessed November 18, 2009).

Wikipedia.org. Requirement. October 2007. http://en.wikipedia.org/wiki/Requirement (accessed January 07, 2010).