Decision-making about ROI and your technology spending

Dan Gilmore wrote in “The ‘Probability’ of Supply Chain ROI” propounds properly and rationally the fact that any “forecast,” including forecasts of ROI (return on investment) should not be a single number. Rather, as anyone properly trained in statistical methods will tell you, it should be a range of numbers. The range of numbers would generally be calculated based on a single calculated value plus and minus values that represent the confidence intervals or, simply put, how likely the statistician believes his estimates the calculates will approximate reality. A larger range indicates lower levels of confidence and a smaller range higher confidence levels.

Now, while Gilmore is mathematically correct, the fact remains that most small-to-mid-sized businesses (SMBs) simply do not have anyone trained in statistics on their payroll and they are not likely to go out and hire a statistician to produce ROI forecasts for their IT projects – since this would, by definition, automatically reduce the ROI of the enterprise as a whole in the short term.

Back on a growth trajectory

Gilmore makes another comment in his article with which I wholeheartedly agree: “[T]here is some evidence that companies are in fact looking at investments that can help them to get back on a growth trajectory (read: increasing Throughput) without having to add much in the way of head count (read: Operating Expenses) by achieving productivity gains.” Given the world-wide economic malaise that is showing some signs of lessening (for the moment, at least), Gilmore’s description probably suits the vast majority of SMBs across the U.S. and beyond.

Furthermore, many others besides me have written that a firm stand on return on investment will be the hallmark of technology spending in the 2010 and beyond. So, I can hardly fault Gilmore for suggesting that SMB executives and managers need to become increasingly sensitive to and realistic about ROI for every kind of investment in their firms’ futures.

Too much complexity already

Despite my agreement with Gilmore on theoretical grounds regarding forecasts – including ROI forecasts; and despite my agreement with him regarding the goal of companies to get back on a growth trajectory through wise investment of capital resources, I must disagree with him on the matter of adding useless complexity to the return on investment forecasting process.

Allow me to explain why I use the harsh term “useless” to describe such an effort in the development of a ROI forecast for an IT project.

First  of all, let me say that statistical methods ought to be applied where they make sense. Statisticians generally agree that a valid statistical sample must contain at least 30 members. This works great where you have 30 dogs, 30 cows, 30 houses, 30 automobile, 30 miles of roadway, and so forth for comparison. Then, of course, you need to factor for environmental differences. Thirty or more cows all in the same pasture, eating the same foods, and enjoying the same climate would make a pretty good statistical sample for some studies of cows. On the other hand, three Holstein cows in northern Minnesota, two long-horns in west Texas, 15 black whiteface cows in eastern South Dakota, and ten mixed-breed cows in central Florida are not likely to constitute a good “sample” for cow studies.

Why?

Simply because there are too many environmental dissimilarities surrounding the cattle. By the time these factors were accounted for, (generally speaking) any results would have such a large confidence interval as to make any prediction almost meaningless.

When considered as a whole, a typical SMB has tens of thousand of variable at work within the enterprise. Any number of those variables are likely to dramatically separate it any “sister” enterprises in a sample group used to forecast ROI outcomes.

Of course, the fact that traditional ERP – Everything Replacement Projects – are going to affect the whole enterprise is a big part of the problem of predicting ROI outcomes. With tens of thousands of variables at play, picking the winning number is far more challenging than winning the lottery.

Reducing the scope reduces the complexity

First of all, a good many SMBs today have a “pretty good” ERP system in place – regardless of its brand. Unless there is some pressing reason to undertake a traditional ERP – Everything Replacement Project, it is probably a far better idea to consider a New ERP – Extended Readiness for Profit project instead.

Narrowing the scope of the project reduces the complexity. And, reducing the complexity increases the likelihood that your ROI forecast will be more on-target. Allow me to give you a couple of examples:

• Warehouse automation – Suppose your Current Reality Tree (CRT) shows you that, in order to increase Throughput, you need to enable your warehouse to be able process 80 to 100 shipments per hour, rather than the present 30 to 40 per hour. Furthermore, you need to do this while holding the line on Operating Expenses.
  
• Business intelligence – After reviewing their Current Reality Tree and laying out a Transition Tree (TrT), your marketing and sales team has assured you that, if they are provided tools with which to better understand customers and markets, they will be able to segment the market and create UROs (un-refusable offers) and increase Throughput by 130% in two years. No additional staff or other increases in Operating Expenses would be required.

If your executive management team were to elect to pursue either of these projects – or both – the goals are specific and measurable – as would be the expected outcomes. ROI calculations become simple:

Where T = Throughput (Revenues less Truly Variable Costs), OE = Operating Expenses, and I = Investment.

Simple. Elegant. And ROI calculations are far more likely to be right than any calculation around traditional ERP – Everything Replacement Projects.

©2010 Richard D. Cushing

The New ERP – Part 41

We are wrapping up our discussion of Sue Bergamo's article entitled "Is Your Implementation in Trouble?" Bergamo listed seven "high level categories [in troubled ERP implementations]…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is her list:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

In the process of our review we are drilling-down on Bergamo's symptoms list and setting them in the context of the New ERP – Extended Readiness for Profit while contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

6. Project management was weak and over-customizations lead to increased scope and time

This is another no-brainer when it comes to traditional ERP – Everything Replacement Projects versus the New ERP – Extended Readiness for Profit. One simple reason is this: the amount of "real estate" to customize.

Think about it. If your organization is going through an Everything Replacement Project there are dozens – if not hundreds – of places in the new technology that could become a target for customizations. However, in a New ERP – Extended Readiness for Profit project, the effort is so targeted and so narrow in scope that there is just not much opportunity for "scope creep."

But, there is another reason as well.

If you will take time to go back (to prior portions in this series), you will discover that the vendor selection and "proof of concept" portions leading up to an implementation under the New ERP approach are likely to expose an requirements for customization early in the process. In fact, such customization or modification necessities will probably be revealed before the purchase agreement is consummated. This is as it should be.

7. The integration of diverse applications was harder than anyone expected

Even though this is where the New ERP – Extended Readiness for Profit should be most vulnerable, this issue is where the New ERP really shines unlike every other approach.

Why?

This is simply because the New ERP approach takes as its number one priority the matter of EAI (enterprise application integration). EAI is fundamental to the New ERP.

Since, under the New ERP scenario, your organization will not be tearing out the central technology engine (core accounting and related modules) and trying to re-integrate several – or even dozens – of necessary applications across the enterprise, the challenge becomes much less complex. The effort you undertake will be concentrated. Your resources will not be diluted. And the work can be planned and accomplished expeditiously.

Furthermore, looking again to the solution and vendor selection process (see earlier posts in this series), the question of integration of the targeted solutions being brought to bear through the New ERP approach – its ease or difficulty – should be and would be addressed prior to making a final decision on the solution(s) and vendor(s) to be employed.

In summary

In this series we have compared and contrasted traditional ERP – Everything Replacement Projects with the New ERP – Extended Readiness for Profit in addressing seven factors that have lead many organizations to failure or dissatisfaction with their ERP system and implementation as reported by Sue Bergamo in her article "CIO Update: Is Your ERP Implementation in Trouble?"

It should be clear to you and your management team now the many advantaged afforded you by applying the New ERP methods. This is a great way to avoid troubled ERP implementations.

©2010 Richard D. Cushing

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

The New ERP – Part 40

We are continuing our discussion of Sue Bergamo's article entitled "Is Your Implementation in Trouble?" Bergamo listed seven "high level categories [in troubled ERP implementations]…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is her list:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

In the process of our reveiw we are drilling-down on Bergamo's symptoms list and setting them in the context of the New ERP – Extended Readiness for Profit while contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

5. The vendor wasn't managed correctly and over-promised, then under delivered

This exposes another important advantage of the New ERP – Extended Readiness for Profit over traditional ERP – Everything Replacement Projects: namely, that the New ERP takes several specific steps to minimize such an occurrence –

Traditional ERP – Everything Replacement Project	The New ERP – Extended Readiness for Profit
Since the vendor in a traditional ERP project is going to touch so many facets and functions in the enterprise, this fact allows the vendor great latitude to make promises about the benefits and gains to be made without ever declaring the specifics about those gains. The benefits to the organization are frequently stated so broadly as to remain essentially without a corresponding metric for evaluation.	The New ERP, in contrast, requires that the executive and management team of the organization determine in advance the three critical matters we have already mentioned several times: What needs to change – That is, to identify what very specific functions in the enterprise are keeping the firm from achieving its goal of making more money tomorrow than it is making today. What the change should look like – The management team must determine in advance what the changes in the specific functions (identified in item 1 above) should look like in order to assure that, after the change is made, the enterprise will, in fact – or with a very high probability – make more money tomorrow than it is making today. This should be measurable in some manner. We have previously used the example (see earlier portions in this series) of an increase in the number of orders that could be picked, packed and shipped with the same number of personnel working in the warehouse. How to effect the change – This is the one area in which the technology vendor may play a part. They may offer suggestions about which technologies to apply and how these technologies should deployed to achieve the greatest effect. Note that if this approach is taken, the management team of the buying organization is setting the specific performance standards expected. This leaves little room for the vendor to exercise his "bragging rights" and thus "over-promise." The vendor either can meet (or exceed) the stated standard or performance, or it cannot. It is as simple as that.
In most cases where traditional ERP is undertaken, there is no up-front establishment of performance standards with the vendor. And, of course, in the absence of a specific and measurable standard, how can one effectively "manage" the vendor. By what measure are you managing them? If the traditional "project success" standards are applied (i.e., on-time, within the budget, and of acceptable quality) then, I suppose, you can count your project a success. However, if that "success" does not result in your company's ability to make more money tomorrow than it is making today – if there is no measurable R.O.I. (return on investment), then that is a hollow victory indeed.	Since the New ERP begins with the executive management team establishing and articulating clearly to the vendors the measurable results expected from them, then "good management" of the vendors means achieving those results that have been predetermined to deliver increased Throughput, reduced Inventories or demands for new investment, and/or lower Operating Expenses while sustaining significant growth. Such an approach greatly reduces the likelihood that a vendor will be incorrectly managed.
Most traditional ERP projects include "demonstrations" of the software. In many cases, such demonstrations are even carefully scripted. However, if you look at the section of this series that references product demonstrations, you will see that product demonstrations rarely constitute proof of concept tightly focused around metrics correlated to critical functionality.	On the other hand, the New ERP required participating vendors provide, not only proof of concept, but also a budget to achieve that proof of concept in the production environment. Furthermore, that budget is compared by your executive management team with the estimated benefits (changes in Throughput and Operating Expenses) to help assure that the projects planned ROI is likely to be attained as a result.

 
This side-by-side comparison of traditional ERP with the New ERP should make it abundantly clear that the "incorrectly managed vendor" failing is far less likely to occur when organizations adopt the New ERP as their method for evaluating both improvement projects and the vendors they hire to supply and implement technologies for them.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

The New ERP – Part 38

Yet another "Why ERP implementations fail"

Sue Bergamo, former CIO at Aramark's WearGuard & Galls companies, recently posted an article entitled "Is Your Implementation in Trouble?" (Bergamo 2010) In her writing, she listed seven "high level categories…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is how the list shaped up:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

We are going to drill-down on these and put them into the context of the New ERP – Extended Readiness for Profit, contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

1. Misconceptions of business expectations 

Ms. Bergamo does not explain in her short article precisely who had the misconceptions of business expectations. We do not know whether, in the Bergamo survey, the misconceptions were held by all or part of the management team involved in the ERP acquisition, by the vendors and resellers involved, and/or by third-party consultants that may also have been a part of the ERP project. My experience tells me, however, that if persons were involved in a traditional ERP – Everything Replacement Project the likelihood is very high they had and held "misconceptions of business expectations."

Why do I say this so boldly?

Because, unfortunately, most organizations do not begin their search for traditional ERP with clarity on the three critical factors we have discussed earlier in this series:

Management Factor Number 1: What needs to change

If executives and managers applied rational tools to determine precisely – not vaguely – what needs to change so that the business could make more money tomorrow than it is making today, the "business expectations" would be clear.

Sadly, many organizations today still pour in traditional ERP like some kind of "miracle-working additive" that is supposed to make their whole enterprise run smoother, cleaner, faster and, as a result, produce more profit. It seems that 20 or 30 years of experience with ERP not delivering its supposed miracle-working power in so many implementations is not yet enough to convince some. Such executives continue to drink the proverbial Kool-Aid offered by ERP software vendors and VARs just as if the hundreds of bad experiences being reported are only mirages and the same could not and would not happen to their firm.

I have walked into dozens of traditional ERP projects where, if asked, no one in executive management could tell me what measurable improvements were expected when the implementation was complete. If they were able to reply at all, their answers sounded more like they were drawn from a séance than from a the mouth of an executive. They might sound something like these:

"We expect that this new ERP system will enable us to grow while holding down our operating expenses."

"We are counting on this new system to help us ship more efficiently."

"Our ERP vendor told us that this new system should help us reduce our inventories without sacrificing customer service. Plus, it will help us build 'best practices' into our back-office."

Now, I have no problem with "We expect that this new ERP system will enable us to grow…" provided that statement is followed by specifics like:

• How much is it likely to "help us to grow"?
  
• What specific changes will the new ERP system bring about that will lead to the expected growth?
  

In the absence of specifics, how can those who complained in Ms. Bergamo's study even complain that they had a "misconception of business expectations"? Was their expectation that they would mystically grow, but they did not, in fact, achieve their concept of mystical growth? Did they expect that profits would mystically improve, but the mystical improvement in profits never appeared?

Just what were their "business expectations"?

If "business expectations" were not defined in clear cause-and-effect terms up front: if the executives and managers could not – in advance – link specific anticipated changes in the "system" (i.e., how the organization itself functions) to the anticipated and measurable improvement, then they have no one to blame for "misconceptions of business expectations" other than themselves. If they drank the vendor's or reseller's Kool-Aid about ROI (return on investment) and did not establish for themselves the metrics for specific and measurable change, they cannot blame the vendor or reseller. It is management's job to know these things and not to simply take a salesperson's (or even a consultant's) word on such matters.

Management Factor Number 2: What the change should look like

If executives and managers have proactively worked out rational cause-and-effect relationships, and have determined clearly and specifically what needs to change, the next step become relatively easy. That step is for the management team to establish what the change should look like.

If applying new technology in the organization (i.e., the system) will "increase Throughput by an estimated 12.5% over 12 months by providing improved market segmentation for Product Line C," then what the change should look like will be described in terms of the changes required to "improve market segmentation for Product Line C." That change might take the form of new market data collection techniques, new automated surveys, or some other form. Nevertheless, there should be no confusion in the management team members' minds as to what the change should look like when it has been implemented.

Similarly, the management team should understand the changes necessary to leverage "improved market segmentation" into "an estimated 12.5%" increase in Throughput over 12 months. The executives and managers should have a clear understanding of how the new market segmentation data will lead to new "offers" in the marketplace that will, in turn, lead to the anticipated growth.

Management Factor Number 3: How to effect the change

What we have described above are real and concrete "business expectations." There is no easy way to misconceive "business expectations" that are so clearly articulated. This kind of "expectation" can be the basis of concrete action. These kinds of "expectations" can become a guide for how to effect the change.

The meaningless séance-induced "business expectations" so frequently articulated by executives and managers surrounding traditional ERP hold little hope of functioning as a guiding light for concrete action on the part of anyone in the organization. It is no wonder that "expectations" are only met in so few traditional ERP implementations.

[To be continued]

©2010 Richard D. Cushing


 

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

Constrained by your ERP?

Are you feeling that your ERP "solution" is more constraining than liberating?  Maybe it's your approach?  Maybe its the way your ERP reseller or vendor treats you?  Maybe your "systems integrator" has no vision -- no ability to "think outside the box."  Click on the link or the title of this post and watch a very funny video on this subject.

Whatever it is, you'll get a kick out this (click the link), and you'll find answers by reading more posts right here at GeeWhiz To R.O.I.

Thanks.

...

The New ERP – Part 20

Getting to the "system" view of the organization

We will talk more about this when we get to the matter of customizations and modifications; however, if the organization is brought together to see that what is needed is an improvement in the effectiveness of the whole organization – i.e., the "system" – in order to achieve more of the goal of making more money, then many of the petty so-called "requirements" may quite naturally fall away.

When I am applying the New ERP – Extended Readiness for Profit with my clients, I frequently have a very frank discussion with the management team about our holist (or "system") view of the organization. In the course of these discussions, I try to point out that, in general, the goal of any improvement is to achieve at least one of the following three things for the whole system:

1. Increase Throughput (T)
   
2. Reduce Inventories or demands for new Investment (I)
   
3. Cut or hold the line on Operating Expenses (OE) while sustaining substantial growth
   

The caveat to that statement is that achieving that end as the result of any given change in the system (i.e., the organization) will not necessarily mean that the level of effort in every functional area will be decreased. In fact, although it is rare, it is possible that a change may lead to some increase in level of effort in a department or departments that already have excess capacity.

I find that, if the executive management team has created and has a full understanding of the impact of their own Current Reality Tree (CRT) – and maybe a Transition Tree (TrT) – the executives' use of the CRT (and TrT) in explaining what needs to change and why to the whole organization usually results in excellent buy-in on the matter of any workload redistribution that may result.

Getting to the "system" view of technology deployment projects

While we are on the subject of seeing your organization as a "system" – that is, from a holist point of view – we want to compare another important difference between the traditional – Everything Replacement Project approach to technology deployments with the approach we take with the New ERP – Extended Readiness for Profit.

The traditional method applied in most IT deployments under management internally or by vendors or resellers is what we call the aim-and-shoot approach. In a (usually vain) effort to minimize risk, the general concept is to get all the details "nailed down" before management turns vendors and resources loose on the work. Executives and managers who hold to this approach sincerely believe that they are acting in the best interests of their firm. Managers from vendors and resellers also generally hold with all sincerity that this approach is the "safest," if nothing else. But let us take a look at just what risk it is that this approach seeks to minimize.

As we said, the way the traditional approach is formulated, the project leadership attempts to "nail down" or "cast in concrete" all the pertinent details as early in the project as possible. Frequently, executives and managers on both sides try to get every detail settled before the final agreement is signed for services. From that point, their thinking is, all they have to do is follow what has been defined to the letter and they will hit their "target" of success at the end of the project.

It is possible that taking this approach minimizes the risk of cost-overruns. (Although, there is a virtual plethora of data available from the experience of thousands of companies over the last 25 years that militates strongly against this concept that this approach actually does reduce the frequency or size of cost-overruns.) More importantly, however, is the very fact that applying the term "cost-overrun" strongly suggests that the project is being measured solely by "cost" and not by "value delivered." Rather than thinking about the value created through increasing T, or reducing I or OE (if you don't know what T, I and OE mean, yet, then go back and read some earlier posts in this series), such managers and executives can conceive of no concept greater than "cost" by which to set goals and measure "success."

Let me assert right now: Any project that is ON-TIME, ON-BUDGET, and of HIGH QUALITY is still a failure – not a "success" – if it fails to increase the system's production of T, or fails to reduce the system's values of I or OE while sustaining significant growth.

[To be continued]

The New ERP – Part 19

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]