Uncertainty: The Elephant in the Room–Part 2

In a previous article on uncertainty, we talked about how uncertainty is viewed by the “customer” of IT versus how it is viewed by the information technologists (e.g., value-added reseller or VAR, IT department) themselves. We mentioned how the “buyer” or the “customer” may feel the only uncertainty for them is the questionable performance of the IT provider.

In this present article I hope to bring out some of the ways traditional methods of project management and corporate management may actually contribute to uncertainty rather than diminishing it. We will speak of this in the context of IT projects, but it actually holds true in almost any project environment (whether or not management recognizes that they have and manage “projects”.)

Pretending about numbers

In out business dealings we like to think that our dealings—both internally and externally—are driven by numbers and facts. What management almost always fails to acknowledge is that a great percentage of our dealings are as much driven by intuition as they by numbers. In fact, intuition frequently ends up driving the numbers.

Take for example the VAR who brings a prospective deal to his project managers (or equivalent) and asks them for an estimate for the services on a project that includes development, training, deployment and post-go live support. The project management (PM) team does its due diligence and comes back with an estimate: “We think it’s going to take $278,000 in services to get this done right.”

The sales managers and executives put their heads together and, purely out of intuition, say, “We can’t sell this project for that much money, but we really need the work right now.” Then, based on the sales department’s intuition and clout with the executives, the PM team is “encouraged” (read: “pressured”) to reconsider their estimate to see if they can’t get the project done for $232,000—which the salespeople believe is the number the prospect will “bite on.”

To make a long story short: the deal gets done and the client is quoted $232,000 in services for the project.

Now, even though the final number was not predicated on numeric calculations and numerical estimates—no, indeed, it was based almost entirely on intuition—there is nothing imprecise nor “intuitive” about the $232,000 figure that was written into the agreement.

The intuitive number now bears pretends to be a precise calculation—an “estimate” or a “project budget.”

In so doing, the reseller has just introduced at least $46,000 in uncertainty into the project. At a typical billing rate, let’s say 250 man-hours or about six-and-a-half man-weeks.

There are no “price complaints”

Several decades ago I had the privilege of working with the national sales manager of an organization with which I was doing considerable business. The gentleman told me something that I will never forget. He said, “There is no such as a ‘price complaint.’ There are only ‘value complaints.’”

I bring this up because the “pretending about numbers” scenario I mentioned above happens more frequently than most folks in the IT business care to admit. But, I don’t believe it has to happen.

Why is it that, most of the time, folks in the IT business never have any real discussions about the “value”—the hard ROI—that their solutions will deliver?

I believe that they do not have those discussions for a couple of very elementary reasons:

1. The customer doesn’t ask. Of course, one of the reasons the customer doesn’t ask is because they’ve heard all the typical “rules of thumb” benefits already. Another reason is because many executives and managers do not even believe in ROI from IT. They consider it a “cost center” and just throw money at it whenever they think it might help. These managers and executives frequently see adding new “IT stuff” or replacing their ERP systems akin to pouring an engine additive into their car. They expect if they do that their engine (their company) will run smoother, faster, longer and get better mileage, but they have no idea how to measure the benefits of “smoother,” “faster,” or “longer.”
   
2. The IT folks don’t know how to calculate it. No, I’m not saying that the executives and other folks in IT don’t know the formula for “ROI.” I’m saying that they are (generally) unwilling or unable to walk their clients or prospects through the process of developing the performance metrics by which the results of their combined (i.e., IT or VAR together with the firm or business unit affected) efforts will be measured.

If both parties—the customer and the IT service provider—are unwilling to confront the subject of real ROI from IT investments openly, objectively and with the aim of mutual agreement on the intended measurable results for the investment, then how can the VAR (or IT department) expect to build “value” in the mind of the buyer to support the “investment” required?

In my opinion, they can not. So, instead, they reduce their “estimates” and cut corners to make it fit into someone else’s “intuitive” budget constraint that is generally predicated entirely on “cost” and almost never on anything like a hard ROI.

Isn’t it time to stop doing business this way? It’s just adding more to the uncertainty in every project. No wonder there are so many IT project failures—or self-proclaim or assumed “successes” with no substantiation—all around us.

Let me know what you think.

Uncertainty: The Elephant in the Room

Not long ago I was fortunate enough to have a conversation with two very fine gentlemen in the software business. They were part of an organization well-recognized for its leadership as a reseller and a developer providing an ERP (enterprise resource planning) solution for Tier 2 and upper-crust SMB firms.

As part of the conversation, I mentioned the fact that uncertainty is “the elephant in the room” throughout the IT (information technology) business.

What I meant by that is this: while the sales process is underway, it all too frequently happens that the two parties have differing views of the uncertainty involved in any project that might be undertaken as a result of their conversation. While they hold these differing views, however, they almost never speak openly and explicitly about the uncertainty itself.

My experience shows me that these two parties hold views of the uncertainty that take shape somewhat along these lines:

• The Client or, more correctly, at this stage in the process, “the prospect” may believe that there is very little uncertainty about which to be concerned. After all, he and his organization have tried to be forthcoming with the reseller. They have answered all the questions the resellers’ folks have raised from the first day they met, and they have done so as directly as possible.
  
  Because “the prospect” feels this way, the only “uncertainty” he may feel about any proposed agreement is whether the reseller is capable of delivering on all the promises he has made over the course of the negotiations.
  
  Also, since “the prospect” will hold the checkbook during the project execution, he feels pretty sure that he can force the reseller into assuming whatever uncertainty might remain in the anticipated project.
  
• The Reseller has been through this many, many times. He is well aware that every project is full of uncertainty. A short list of the uncertainties in the reseller’s mind might look like this:
  • Have we asked enough questions?
  • Have we asked the right questions?
  • What don’t we know that we should know about this company and how it works?
  • Can the modifications we anticipate be completed in the time we have estimated?
  • Will the prospect’s company allow this project to proceed in the time we have estimated, or will their inefficiencies, indecision or other operational problems cause us to incur unanticipated time and expenses?
    

Accidentally induced uncertainties

W. Edwards Deming once summed up very succinctly the uncertainty included in all human communications. Following a meeting between two parties, as one party was exiting the room, Deming turned to the manager he was consulting and said, “We know what we told him, but we don’t know what he heard.”

Communications between two human beings are full of such foibles. The fact that the reseller’s salesperson does not believe that he has made any “promises” upon which the reseller cannot readily deliver does not mean that the prospect has not heard “promises” that are very different from what was intended by the salesperson.

Under such circumstances, there is—more likely than not—no intention by the reseller’s sales team to mislead the prospect. Neither, most likely, is there any intent by the prospect (now, client) to somehow misconstrue what was said in order to take undue advantage of the reseller.

Nevertheless, such accidentally induced uncertainties too frequently lead to cost overruns, hard feelings between the reseller and the client, and—sometimes—even to failed projects.

Why don’t we talk about it?

My question is simple: When it comes to IT projects (or any kind of projects, for that matter), and whether it is a relationship between an external IT provider or an internal customer relationship, why do we so often ignore “the elephant in the room”?

Why are both the customer and the supplier both so reluctant to speak explicitly about the uncertainties that almost inevitably affect a project of any significance or size?

Let me know your thoughts. Thanks.

What does technology project “success” mean to you?

I’m sure many of you are familiar with the common Venn diagram of “project management success.”

PMI (Project Management Institute) and others advocate that a project is successful if it is on-time, within the budget, and of high quality (or, at least, meeting the project’s original standards for quality). Of course, this is true when compared to the alternatives of over budget, late or of poor quality.

But, in the business world, we shouldn’t undertake projects—any kind of improvement project—for the sake of the project itself. So, while this might a satisfactory view of the project manager’s or the project team’s performance, it really doesn’t tell us very much about the net effect on the business.

Another popular Venn diagram used relative to technology deployments is the processes-people-technology one.


Here the aim is assure that the technologists involved in the project carefully consider the business processes that must be supported by the technologies deployed. Furthermore, the IT folks should also understand the people involved and they will desire to apply and benefit from the new technologies.

However, once again, we should be reminded that a business enterprise should never undertake any kind of improvement project merely to automate business processes for automation’s sake. Nor should they undertake an improvement project with the sole aim of people-pleasing.

In a for-profit organization, there are proper metrics to use for IT decision-making, but these are not the ones.

Consider, for example, the business that spends $150,000 on an IT project. The project is deemed to be “a resounding success” based on the following results:

1. The project was completed on time
2. The project was completed under budget
3. The project met all of the initial quality requirements
4. The project’s technology deployments properly supported the intended business processes
5. The project’s new technologies were well accepted and utilized by the people involved
6. The company was no worse off after this major undertaking (and everyone has heard the horror-stories of huge IT failures)

So, the project management team all got big pats on the back and a few VP’s got bonuses and all the stockholders and stakeholders are pretty happy about the whole “successful project” thing.

But, my question is: Should they be happy?

They just spent $150,000 with an admitted ROI (return-on-investment) of a big fat ZERO!

To me, that’s just not good business!

There is a Venn diagram that I, personally, have never seen, but it is the one Venn diagram that makes sense for business investments of every kind because it includes the three factors that should always be considered for “success.” Here it is.

Here are the questions that should be asked about every improvement project—IT-related or not:

1. How much does the project increase Throughput (where Throughput is defined as revenues less truly-variable costs directly linked to producing the revenues)?
2. What affect does the project have on Operating Expenses? Do they go up or down? If so, by how much? Is the change “real” or a calculation based on “savings” when no one will actually be laid-off or no additional Throughput will consume the man-hours “saved”?
3. How much will our Investment change? Besides (as in our example) the $150,000 we will invest in the project itself, will our inventory go up or down? Will we need to invest in new buildings, or can we sell off some capital equipment and increase our cash?

When you have the answers to these questions you will have the answer as to whether your technology project was just a “project success” or a “business success.” And, while the numbers may not be precise, knowing that they are approximately right will give you far better understanding of your company’s success or failure than not considering them at all.

What do you think?

[Cross-posted at Kinaxis Supply Chain Expert Community.]

ERP Vendors and Customers: The Blind Leading the Blind

Writing in CIO UK magazine online, David Henderson’s article entitled “Why IT vendors must raise their game” makes several salient points. Not least among the points raised is the fact that “too many IT vendor sales personnel don’t really understand my underlying business processes and investment criteria….”

For me, however, the issue is somewhat stood on its head. Far too many business enterprises with which I have been involved have precisely the same problem internally. CEOs, CFOs and CIOs in many businesses buy new technologies without understanding their own underlying business processes and by what criteria they should invest.

What executives and managers should know

Executives and managers seeking ways to improve their business enterprises (read: make more money tomorrow than they are making today) too often buy new technologies out of “hope” or “desperation,” rather than with a clear and concise understanding of

1. WHAT needs to change in order for the business to begin making more money tomorrow than it is making today;
   
2. What the change should LOOK LIKE; or
   
3. HOW to effect the change (including what role any new or upgraded technologies might play in delivering the improvement).

Since they do not have the tools to concisely analyze what needs to change in order to make more money tomorrow, then they cannot know what the change should look like or how to bring about the change effectively. So, in the absence of clarity, they grope about in their darkness hoping that some change – any change – will bring them their desired end of higher profits.

Blind leading the blind

Like the blind leading the blind, the technology vendors and resellers who do not fully understand their prospects’ underlying business processes or appropriate criteria for investment (in fact, they understand them less clearly than the executives and managers, in many cases), console the yearning executives with platitudes and “rules of thumb” about how their latest and greatest “gee-whiz” technology will “reduce costs by X percent” and “improve sales by Y percent.”

Of course, this is precisely what the executives want to hear. Like the Sirens of old, the vendors and resellers lead many to spend. Even if they don’t fully believe what they are hearing from the vendors and VARs, the executives and managers frequently do not take time to calculate with any precision just how or why the new technology should, could, or would produce a return on investment (ROI) in their particular organization and circumstances. Instead, they close their eyes and ears to any negative thinking and, In the absence of any better ideas, these executives take out their checkbook to purchase the latest and greatest of new technologies. Of course, the correct general ledger account to which this “investment” should be charged is “Hope and Earnest Expectation.”

Serendipity

Sometimes good things come of this method. According to the industry literature, we can say that about one out of three such “investments” lead to noticeable improvement. Many times, however, the measure of improvement cannot be known with certainty. A growing company that shows improvement after some implementation cannot know which results may have occurred even in the absence of the new technology. A far greater share of SMBs (small-to-mid-sized businesses) simply assume they are “better off” if they are not clearly “worse off” following the deployment of some new technology. Some merely breathe a sigh of relief after some trying implementation period and, like a good Calvinist, say, “I’m glad that’s over,” without ever looking back to measure their return on investment.

My argument, however, is that “hope” and “serendipity” are not strategies and, while a few companies come to excel and even to dominate some markets for a short period of time based on little more than serendipity, it is not a sound strategy for long-term growth in any enterprise. For executives and managers return on investment should be seen as a primary responsibility. This responsibility should not be handed over to the technology vendor or VAR (value-added reseller). Neither should it be left to chance.

As W. Edwards Deming said so clearly: “It is management’s job to know.”

It is management’s job to figure out WHAT needs to change in order to start making more money tomorrow than the firm is making today. It is management’s job to come to a clear understanding as what that change should look like when it occurs. And, it is management’s job to define an unambiguous roadmap to effecting the necessary change. Then, it should be management’s job to measure and report on the return on investment yielded by their own keen insight.

Need help with this? Contact me at rcushing(at)GeeWhiz2ROI(dot)com and let’s talk.

©2010 Richard D. Cushing

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 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).


 

ROI is a Responsibility – Part 5

This is Part 5 in a series where we have been reviewing comments made by Jacob Varghese in a 2003 article in which he essentially claims that it does not make sense to try to measure or compare IT initiative based on ROI (return on investment) calculations. In preceding portions we have noted that Varghese called upon Ross and Beath to help him say more about how and why ROI might not be a good way to make determinations regarding IT investments:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

I have previously concurred that there is, of course, legitimacy surrounding each of these classifications, but I wanted to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money. In Part 3 we discussed "Transformational" IT projects. In this portion, we will try to cover, in a more brief way, the other three Ross and Beath categories for IT projects.

Process improvement IT projects

Ross and Beath tell us that "process improvement" IT projects are those "that focus on short-term profitability or incremental process improvements [such as] to speed time to market, lower the cost of operations, or to differentiate services/product offerings."

The Ross and Beath examples for IT "process improvement" projects are most enlightening. They are:

• Accelerating time to market
  
• Lowering the cost of operations
  
• Differentiating of service or product offerings
  

Now, allow me to restate these in the context of the three key metrics that we have been using repeatedly in this series:

Example Project	Key Metric Predicted Effect
Accelerating time to market	Assuming the enterprise's products or services have a market and the firm is doing a reasonably good job of selling the products prior to the "process improvement" project under consideration, then accelerating time to market should lead to increasing Throughput. All that needs to be done by the executive team is to figure out how they will leverage accelerated TTM (time to market) in order to increase Throughput, and then put numbers (estimates) to the question of how much they believe that Throughput can be increased as a result of the improvement.
Lowering the cost of operations	This is a simple exercise in reducing Operating Expenses. The question to be answered by your executive team is just how much Operating Expenses can be reduced without jeopardizing support for increasing Throughput (from other initiatives that are hopefully underway already).
Differentiating of service or product offerings	This should essentially be a ditto of what I said above in the "Accelerating time to market." After all, what is the point of investing in increasing the differentiation of your firm's products or services if doing so does not, in fact, lead to increasing Throughput. Still, managers will need to set their minds to calculations of how and how much the new differentiators will add to Throughput.

Experimental IT projects

In their article, Ross and Beath describe "experiment" IT projects as those that test "[n]ew technological trends that present significant opportunities for long-term growth" in "pilot programs to validate the technology's promise and impact." Since this is purely experimental, it would seem that it would be impossible to calculate their potential effects on T, OE or I.

However, I believe that it would be possible to apply a simple method called "profit expectation" to determine the value of potential benefits that might flow from experimental technologies. Under such an application, the standard ROI formula would be modified to the following:

ROI = ((a% * delta-T) – (b% * delta-OE)) / (c% * delta-I)
where
a% = estimated expectation (as percent) of achieving calculated delta-T,
T = Throughput, b% = estimated expectation (as percent) of actualizing delta-OE,
OE = Operating Expenses, c% = estimated expectation (as percent) of required delta-I,
and I = Investment

It would seem to me that these kinds of R&D projects would not be considered alongside other immediately accessible improvement projects. Therefore, an alternative approach for R&D should be considered. For example, perhaps before investing more than some preset and relatively small amount in any R&D project, the promoters of the project must present an ROI calculation to a review committee based on the formula above. It is up to the backers of the project to "sell" the committee on the validity of their calculations and estimates for a%, b% and c%.

Furthermore, it seems reasonable that as R&D projects move forward and more is learned, the values used in the ROI formula will change. Certainty should increase with each incremental review, but the ROI value will move up or down over time. By reviewing projects on a regular basis – weekly, monthly, quarterly, as may be reasonable for the type of organization – your executive team can maintain a clear and consistent drive toward increasing ROI through the firm's R&D efforts.

The bottom line

We must again be reminded: the bottom line is "the bottom-line." Do not succumb to accepting the concept that it is not possible to calculate ROI for so-called "process improvement" or "experimental" IT projects. There are ways to help your organization stay focused on real improvement – improvement that is most likely to have a positive effect on your enterprise's bottom line.

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI is a Responsibility – Part 4

We have been reviewing comments made by Jacob Varghese in a 2003 article. In our Part 3 we noted that he had more to say about how and why ROI (return on investment) might not be a good way to make determinations regarding IT investments. In doing so, he references work by Ross and Beath:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

I have concurred that there is, of course, legitimacy surrounding each of these classifications, but I wanted to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money. In Part 3 we discussed "Transformational" IT projects. In this portion, we will try to cover, in a more brief way, the other three Ross and Beath categories for IT projects.

Renewal IT projects

Ross and Beath describe "renewal" IT projects as "investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance."

It seems clear from this description that most "renewal" projects will not contribute in any significant way to an increase in Throughput (T). However, it is likely that such projects will lead to reducing Operating Expenses (OE), and, in some cases, it may be possible that a "renewal" project could reduce the demand for (other) Investments (I). If this is true, then is it too much to ask for the IT department or the executive team to actually sit down and put some rational numbers (i.e., estimates) to the potential savings from investments in proposed IT "renewal" projects?

For example, if investment in SAN or virtualization technologies will contribute to savings in support or drive down the need for investments in new servers or other types of data storage in the future, then let the IT department bring forth such estimates and present them for consideration by the executive management team. There is a place for such projects, and the more the firm emphasizes and prioritizes around IT projects that increase Throughput (based on calculated ROI for projects competing for the investment dollars), the more cash flow will increase and the less difficulty the enterprise will have in coming up with the funds when ROI calculations show that a "renewal" project makes a lot of sense.

However, I would like to suggest another approach. One of the former managers for the New York Yankees used to have a strict policy: "Put a rookie in the lineup every year." This makes sense because then your team never gets "old" all at once. This approach makes sense, too, in the IT infrastructure world. Organizations should build into their regular annual budgets an Operating Expense amount allocated to "renewal" of their IT infrastructure. Some years the full renewal budget will be spent. Other times the renewal budget will not be spent in full. In that case, any budget balance should roll-over into the next year when a larger renewal project may be required.

If this approach is used, then "renewal" projects in IT become a part of operating expenses necessary to maintain the enterprise's health. In this case, a "renewal" project's ROI is still calculated in the same way using the same formula. The calculations would run along these lines:

ROI = (delta-T – delta-OE) / delta-I
where T = Throughput (Revenue less Truly Variable Costs),
OE = Operating Expenses, and I = Investment

Since, for IT "renewal" projects there is not likely to be rationale for concluding that the project will contribute to increasing Throughput, then that leaves only reductions in Operating Expenses and Investment as factors. If a "renewal" project requiring an investment of $25,000 will reduce annual maintenance and support costs by $6,000, but will also reduce a potential additional investment in year 2 by $18,000, then one can calculate as follows:

ROI (Year 1) = ($0 – (-$6,000))/$25,000 = 24%

ROI (Year 2) ($0 – (-$6,000))/($25,000 - $18,000) = $6,000/$7,000 = 85.7%

Note: When comparing multiple projects that produce multi-year variable cash-flows it may make sense to compare projects based on NPV (net present value) or, potentially, FMRR (financial management rate of return).

The bottom line

To reiterate: the bottom line is "the bottom-line." Do not succumb to accepting the concept that it is not possible to calculate ROI for an IT project destined for "renewal." We have just proven that, if your executive management and IT staff will commit to thinking through estimates and causes for changes in T, OE and I, then it is possible to rationally calculate the benefits to proposed IT projects – "renewal" or otherwise.

We will continue with the other kinds of IT investment from Ross and Beath in future posts.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI is a Responsibility – Part 3

Jacob Varghese has more to say about how and why ROI (return on investment) might not be a good way to make determinations regarding IT investments. In doing so, he references work by Ross and Beath:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

There is, of course, legitimacy surrounding each of these classifications, but I want to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money.

Transformational IT projects

Ross and Beath describe transformational IT projects as being "IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing)." Now, in for-profit organizations, my guess is that the real measure of "growth" is in two realms: revenues and profits. I doubt that there is a desire to grow the balance sheet just to call it "growth."

Another word for "barriers to long-term growth" would be a "constraint." So, "transformational" IT investments should be aimed at exploiting, elevating or breaking a constraint to long-term growth. And, while we are talking about it, let us set forth this axiom: It is not possible to exploit, elevate or break a constraint to long-term growth without the action also opening the door for short-term growth. So whatever investment your executive team makes in so-called "transformational" IT should still be able to be measured in the essential terms we used in earlier portions of this series: namely, increasing Throughput, reducing Inventories or demands for new Investment, and cutting or holding the line on Operating Expenses while supporting significant growth.

Let us look at each of these more closely in the context of "transformational" IT:

Increasing Throughput: Some business executives look at IT investments in, say, a new ERP system as though ROI for such investments were a given. There justification for yanking their present systems out and going through 18 months or more of upheaval in a traditional ERP – Everything Replacement Project is frequently little more than some general sense that "If we do it, things will get better." They hear that other companies have replaced or upgraded their ERP systems and report making more money, and they don't want to be left behind. But these same executives forget that other companies have also gone into Everything Replacement Projects only to be tapped for hundreds of thousands or even millions of dollars and not improved at all. In fact, some companies never recover from traditional ERP implementations and end up on the junk-heap of business history.

In the absence of the willingness or tools to create a valid estimate for their firm's "transformational" IT projects, some executives and IT managers seem to buy into the software vendors' and resellers' theory that somehow "new" or "improved" ERP systems are like oil to an engine – just pour it in and everything will run smoother, faster and with less friction.

Well, oil does that for an engine and we can accurately predict the effects of the lubrication on the engine because we have laws of physics and mechanics to guide us in calculating the predicted effect. Unfortunately, most business executives and IT managers today do not even have an accurate theoretical framework about what the constraint is – or constraints are – to their businesses' making more money tomorrow than they are making today. Instead, they accept the "mystical mojo" theory that "new" or "improved" technology will somehow make their enterprise also run smoother, faster and with less friction.

Would it not be more business-like for your executive management team to actually figure out how just how any investment in IT that is designed to "remove infrastructural barriers to long-term growth" will actually remove barriers to long-term growth? Would it not be more practical for the team to make some rational estimates of the measure of improvement that will result from the removal of these "barriers to long-term growth"? Does it not stand to reason that, if managers believe that implementing new technologies will, in fact, "remove… barriers to… growth" that they be asked also to define just how the technologies will elevate or break existing constraints to business growth?

That is what figuring out how much new technologies will contribute to increasing Throughput is all about. The executive management team should be able to say something along these lines before making a decision regarding any given IT project: We believe that investments in technology X will lead to increasing Throughput (for definitions see related posts) by Y dollars within N months. We base our estimates on the new technology's providing us with the ability to expand our reach into markets A, B and C accompanied by commitments from Sales and Marketing that targeted offers in Product Lines P, Q, R and T.

To do less than this is for your executive management team and IT staff to make a resolution to spend, perhaps, hundreds of thousands of dollars on new technologies based only on "hope" and we all know that "hope" is not a strategy, at all.

Reducing Inventories or other demands for new Investment: Much of what I just said about your executive team setting forth specifics in estimating changes in Throughput applies equally well in calculations regarding potential changes in Inventories or other Investment. If your IT staff or software vendor is encouraging you and your team to consider an investment of potentially hundreds of thousands of dollars, it seems that you would owe it to yourself and to your stakeholders to grapple with just how this investment may help the company with regard to liberating cash or reducing demands for new investments in other areas of the enterprise.

If investing in new supply chain technologies will help slash your $10 million average inventory by an estimated 22%, then that is $220,000 in cash that will be liberated in your operating cash flow. But your management team should figure out, in advance, just how the application of the technologies in your specific environment will lead to this 22% reduction in inventories. The 22% figure should not be grabbed out of the air; nor should it be taken for granted that because the technology vendor has reports from other clients that this number has been achieved that your organization can do the same.

However, on the positive side, if your proposed technology investment can cut your inventories by 22% while simultaneously support significant increases in Throughput, then you and your team are probably also looking at an apparent reduction in demand for new investment, as well. It means that your enterprise may be able to double or triple its Throughput without having to build a new warehouse or invest in the expansion of the existing one. This is all good news and should be calculated in the firm's ROI for the proposed investment in "transformational" IT.

Cutting or holding-the-line on Operating Expenses while supporting significant growth: Again, much of what I have said above regarding your executive team's willingness to "dig out the numbers" and figure out the "how" an investment in "transformational" IT will "remove barriers to… growth" applies to calculating changes in Operating Expenses (OE). Do not rely on rules-of-thumb and reports from technology vendors and resellers regarding the benefits other companies have achieved. If these are going to be real for your enterprise, then the how-to and resulting benefits should not be too difficult for your team to put down on paper.

Actually, in the example given above, we could already calculate at least one portion of the change in OE: If we know the firm's carrying costs for inventory, then the change in Operating Expenses from the reduction in inventory would simply be $220,000 times C%, where 'C' is carrying costs as a percent of inventory. If it costs your business 20.8% to carry inventory, then the change in Operating Expenses would be a decrease of $220,000 times 20.8% or $45,760 per annum.

The bottom line

The bottom line is "the bottom-line." Do not succumb to accepting ROI calculations from your technology vendor or base them on rules of thumb that may or may not be accurate for your enterprise. Besides, it is up to your management team to work out – in advance – precisely how they intend to leverage the proposed new technologies to achieve the ends of increasing Throughput, reducing Inventories or demands for new Investment, and cutting or holding the line on Operating Expenses when "transformational" IT projects claim to be "removing barriers to… growth."

We will continue with the other kinds of IT investment from Ross and Beath in future posts.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI is a Responsibility – Part 2

As I said in Part 1 of this series, I have, of late, been challenged in my thinking from two quarters: first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be too much "right-brained" and could not be cornered into decisions based on such things as calculated ROI (return on investment).

And next by this excerpt from a May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins. By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses. ROI numbers do not ensure that technology initiatives will be in line with business strategy. The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative. ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered. And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits." (Varghese 2003)

"ROI numbers do not ensure that technology initiatives will be in line with business strategy."

Of course, Mr. Varghese is absolutely correct in this. It is quite possible to calculate an ROI for a project that has nothing to do with your business strategy. In fact, this is eminently possible if you use formulas provided by software vendors and resellers. All you need for some of those formulas are numbers like:

• Number of employees
  
• Number of salespeople
  
• Current Revenues
  
• Number of orders per month
  
• Number of SKUs and so on, ad nauseum. 

Unfortunately, one of the things that you will note about these numbers supplied to standard ROI formulas used by salespeople is that everyone has employees, everyone (or almost everyone) has salespeople, everyone has revenues, and so forth. None of these figures say anything about your business strategy or what will actually make your business better.
If you use these kinds of generic formulas to calculate the ROI of your IT initiatives, then there is no assurance whatsoever that the there will any alignment between IT efforts and your business strategy. So the answer is, do not use such ROI calculations. Go back to Part 1 in this series and see how you and your management team should calculate ROI in order to compare business opportunities that may be supported by IT investments.

"The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative."

Now here is where I'd have to ask Mr. Varghese for the definition of "success." If you ask the typical software vendor or VAR (or, unfortunately, maybe even your own IT manager) the definition of the "success of [a] technology initiative," you are likely to get an answer along these lines: "If the project is completed on-time, within the budget, and delivers the quality anticipated to the end-users, then the project is a 'success.'"

What is missing in this all too typical definition of IT project success is anything having to do with delivery of business value. If that is true – if your IT manager does not relate every effort to delivering business value that is a failure of executive management. Either they hired the wrong kind of person for the job, or they have not taken time to convey across the whole organization – IT staff included – that every expenditure of time, energy or money should be focused on delivering business value.

If, on the other hand, your executive management team is "responsible for implementation" of each IT initiative and if they have prepared their ROI calculations for the project as I have described in Part 1 of this series, then they will have and know everything they need to help guide the project to full business value-delivering success.

"ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered."

I confess that Mr. Varghese has me confused at this juncture. If "planning is as comprehensive as possible and the totality of impact has been considered," then what is wrong with using the ROI figures altogether? I think most readers will concur with me that the ROI in the example presented in Part 1 of this series is "comprehensive" and considers "the totality of impact." So, if such numbers exist, why not use them in a comprehensive way to set IT priorities?

"And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits."

I certainly concur with the general notion that, if proof of concept can be achieved without expenditure of the full budgetary allowance for any given IT initiative then, by all means, get to the proof of concept and make a go/no-go decision at that point. This is common sense.

However, planning, that goes well beyond the IT department, should be responsible for all of the other things that must occur in order to "realize planned benefits." Technologies are tools and only tools. They represent costs, expenses and investment and do not, in themselves, ever represent revenues, Throughput or profit to the organization. It is up the business organization itself to leverage the tools in order to achieve more of the firm's goal – to make more money today and in the future. Executives and managers must have laid the functional groundwork during the planning that was used to calculate the ROI (see Part 1). They must already know what must happen to reach the estimated increase in Throughput, for example. That factor is not in the purview of the IT department.

[To be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI Is a Responsibility - Part 1

I have, of late, been challenged in my thinking from two quarters: first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be too much "right-brained" and could not be cornered into decisions based on such things as calculated ROI (return on investment).

Next, I was going back through some old articles I had collected and discovered this excerpt from an May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins. By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses. ROI numbers do not ensure that technology initiatives will be in line with business strategy. The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative. ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered. And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits." (Varghese 2003)

Now, I remain at two-minds regarding the Varghese article. On the one hand, I might agree with him on some matters, but I cannot be quite sure because there are other statements that run so outrageously against my inner sense that I cannot be certain of his meaning in the other statements. So, let me break this down sentence by sentence:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins."

Who is the "liar" here?

I suppose if the ROI figures are coming from a salesperson working for a software vendor or VAR (value-added reseller), then Varghese might have a point. However, it is the firm's executive team that is the "fool" in that case, for believing the ROI numbers provided by the very persons who stand to gain the most – and lose the least – by selling new technology to the firm.

However, if the executives and managers are doing their job properly and they have the right tool set, they should be the inventors of their own ROI figures. Furthermore, those figures should not be predicated on industry averages or "round-numbers" or rules-of-thumb. The executive team should figure out – for each proposed investment in IT – the following three factors (at a minimum):

	Factor	Description	Example
1	Change in Throughput or delta-T	How much will Throughput increase, where Throughput is defined as incremental revenues less truly variable costs (only those costs that will vary directly with the change in incremental revenue change)	Investing $85,000 in technology X should increase our sales of Product Lines A, B and C in the Y market segment by 15% over the next 12 months. We estimate that this will result in $215,000 per annum in additional Throughput when fully up-to-speed. We believe that minimal change in Operating Expenses will be necessary to support this increase it Throughput.
2	Change in Investment or delta-I	How much will total assets change	Of the $85,000 investment in technology X, we expect that $50,000 will be capitalized. We also expect that about $22,000 in additional inventory will be required to support the $215,000 per annum in additional Throughput. Therefore, total change in Investment (first year) is estimated to be $72,000 ($50,000 + $22,000).
3	Change in Operating Expenses or delta-OE	How much will day-to-day expenses increase or decrease	As previously stated, our estimates indicate that we will be able to support the $215,000 in additional Throughput with no additional staffing. However, the carrying costs for the additional $22,000 in inventory are estimated at 23.2% or $5,104 per annum. We also know that software maintenance costs will 18% of $20,000 or $3,600. Total estimated change in Operating Expenses are, therefore, $8,704 per annum. In the first year, we must add the non-capitalized part of the $85,000 IT project, or $35,000. First year delta-OE is, therefore, $8,704 + $35,000 = $43,704.

How, then, do we calculate the ROI for this "technology X" project? Quite simply using the following formula:

ROI = (delta-T – delta-OE) / delta-I

Or

First-year ROI = ($215,000 - $43,704) / $72,000 = $171,296 / $72,000 = 238%

Now, perhaps Mr. Varghese can explain to us all why comparing various IT projects on this basis is "a fool's game."

"By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses."

Here, again, I guess we need to ask the question: Whose ROI figures? If the figures upon which the executive team is relying come from the vendor or the VAR or are otherwise based on non-specifics, then I would concur with Varghese.

However, if the ROI figures are coming from sound analyses as I just set forth in the examples above, then I would say that it would be managers who do not "rely solely on ROI figures to approve" IT projects, or to "decide between projects" that are "shirking their responsibility for understanding how technology will affect their businesses." In fact, by not preparing an ROI analysis with the kind of stringency suggested by my example above, then managers and executives are simply throwing in the towel and confessing outright that "We do not know how technology will affect our business. Instead, we just have hope that if we spend money on technology, that somehow our company will magically improve."

That, folks, is not a strategy.

[To be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

The New ERP – Part 21

Getting to the "system" view of technology deployment projects (continued)

Sometimes there is an even a selfish motive lurking beneath the surface of one applying the traditional approach to IT deployment projects. If the organization – whether it be your own organization, or the vendor's or reseller's – rewards those responsible for IT implementations based on their projects being on-time or on-budget rather than basing rewards on the value returned to the target organization as measured in terms of beneficial changes in Throughput (T), Investment (I) or Operating Expenses (OE), then it is not only possible, it is highly likely that there is a personal and selfish motive to how these managers plan and implement.

Now, I am by no means suggesting that managers of IT deployment should be frivolous in the treatment of available time or funds for project completion. Far from it, for from a "system" improvement point of view, delays mean reduced Throughput and additional money carelessly spent on an IT project drives Investment higher. Both of these are absolutely negative in my view.

However, what I am saying is, executives and managers holding only a cost-world view of the IT deployments will likely miss opportunities to produce even better results (in terms of T, I and OE) if they hold to the traditional aim-and-shoot approach.

The holistic value-view of technology projects

A management team with a holistic value-view of any change involving technologies should hold a much different view of the one we have described (in Part 20 and above) as the traditional IT project view. If your managers, vendors or resellers want to participate as an active partner with you in an Extended Readiness for Profit – the New ERP program, they need to have a clear understanding of all of the tools that have brought you and your team up to this point. They need a clear framework through which to view and understand what is happening across all of the departmental silos in your organization. In short, they need to understand have a "system" view, not a departmental or functional view. Working through your Current Reality Tree (CRT) with these stakeholders in your project's success should help them gain this essential footing and view.

Next, since (hopefully) no one on the project team is relying upon a set of nearly meaningless "requirements" prepared either by internal silos or external consultants, each of the team leaders should have a clear set of measurable objectives with regard to any initiative being undertaken. (A clear and measurable objective might be: "To increase the number of shipments able to be picked, packed and shipped from the current 20 per hour to a minimum of 40 per hour at current staffing levels.") These participants will know precisely how much a specific IT initiative is to deliver in terms of increased T or reduced OE. There is no guesswork about value creation under the New ERP – Extended Readiness for Profit approach.

Armed with a clear, controlling framework and measurable objectives for the IT initiative at hand, such managers are armed and able to make effective value-based judgments throughout the entire duration of the project. The reasons this is necessary are several:

• "Today" – whatever day that is in the project – the managers have learned something they did not know "yesterday" that will affect delivered value
  
  
• "Today" – whatever day that is in the project lifecycle – the managers do not know some things that they will learn "tomorrow," and these unknowns may also affect the value proposition of the project
  
  
• Making changes in the immediate future (say, within a week, or a month, depending on the project) to the technology is very likely more difficult and more costly that making the same changes at some later date (the increased costs and difficulty being caused by factors such as lack of time for planning, current workloads, potential overtime pay requirements)
  
  
• Having the liberty to make changes incrementally into the future, as the value proposition changes and unfolds, allows the managers to guide the overall IT project to the highest value optimized against the lowest total cost of ownership (TCO)
  

This is really where the traditional approach falls down so dramatically. If the IT initiative under consideration is going to last more than 30 or 45 days, it is almost a certainty that something will change – or something not changed, but only lately coming to light for consideration – that will affect the value proposition of the proposed deployment. New products are introduced – if not by your company, then by your competitors or your suppliers. Changes in the economy or public policy may affect the way or with whom you can or must do business. These and likely some 10,000 other factors could change the value proposition of the IT project that is underway.

This means that the "target" that you and your team were originally aiming for on Day One of the project may not be the target you really want to hit on your scheduled completion date. The value-based manager is prepared to take those revelations in stride and to make effective adjustments as soon as new estimates of T, I and OE can be made. (And, if you recall from our earlier posts, estimates of T, I and OE can be done pretty rapidly meaning no paralysis by analysis for the team.) Then, the team will apply the simple formulas we have previous supplied using the new estimates:

Benefit ($) = delta-T – delta-OE

Or

ROI = (delta-T – delta-OE)/delta-I

The value-based manager should always understand that the value he beholds today in any given improvement initiative (technology-based or not) may not be the value of the same initiative tomorrow. The further into the future the manager tries to see, the less certainty there is that today's value proposition will still hold true.

[To be continued]

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]