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

Making more money in the service business

If you’re a regular reader of my writings, you will know that I do not endorse many products. And, even if a product delivers many outstanding benefits, I will give you the straight scoop about delivering on R.O.I. (return on investment).


Well, I just finished reviewing an outstanding product for the SMB (small-to-mid-sized business) service industry. If your company sells, installs and/or services high-value technical or industrial products – or even if you service products sold and installed by others (such as swimming pools and hot-tub systems) – SM-Plus(tm) from Single Source Systems could help you start making more money.

A study done by Aberdeen Group indicates that service companies that adopted end-to-end solutions that aided managing their business as a “system,” rather than in silos, saw an average of 14.2% increase in revenues over a two-year period. Since, for many service companies, their service revenues carry very little in Truly Variable Costs (TVCs), that means that almost all the dollar increase in revenues drops directly to the company’s bottom-line.
 
So, how does an service management end-to-end solution create this increase in revenue – and profit?
Here are a few of the key factors:

• Elimination of inter-departmental silos increases visibility of “bottlenecks” and helps executives and managers take effective action to increase Throughput.
• Integration with mobile computing devices reduces time lost for data-entry or trips back to the job site or warehouse. This means more available service hours are actually used performing billable services.
• End-to-end solutions are able to handle complex contract-based billing calculations, thus virtually eliminating “islands of information,” manual calculations and redundant data entry. This, in turn, means the enterprise can grow revenues without adding to operating expenses.

So, how would you determine if Single Source Systems’ SM-Plus would be a good investment for your service-centric enterprise?

The formula return on investment remains the same:
You and your team need to calculate how much your Throughput (T) (i.e., Revenue less TVC) might increase (see average of 14.2% over two years above, but calculate your own numbers) and any net effect on Operating Expenses (OE). Then, figure out what your investment would be to get started with a product like SM-Plus. Put those numbers into the formula for ROI (see illustration), and you can calculate your ROI simply and easily.

Give it some thought.

Drop me and email at rcushing(at)GeeWhiz2ROI(dot)com if you have further questions.

©2010 Richard D. Cushing

Technorati Tags: service management,SM-Plus,Single Source Systems,ROI,return on investment,Throughput,bottleneck,TVC,Truly Variable Costs,mobile computing,operating expenses,SMB,SME,Aberdeen Group

Generating Business to IT Alignment for successful packaged software (COTS) implementations

You've decided on the software you need, the business side has bought into it, and you've even picked your integrator. Now the hard work begins: Making sure that your software deployment strategy sets your company up for success, and that means making sure Business, IT and the Implementation Partner are in alignment.

First, we need to understand that Business, IT and the Implementation Partner are coming from different perspectives. Every party has a knowledge gap to address. Business best understands their existing business model and the underlying success drivers. The Implementation Partner understands the packaged software and has multiple years of implementation experience. IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies. Alignment is generated only when a common understanding of the business model, packaged software and technology capabilities are shared by all three parties. When this alignment occurs there is effective communications and faster decision-making. Decisions move implementations forward.

Following is a recommended set of steps to develop a common understanding for effective collaboration during the COTS implementation:

1. Document existing business processes

It is an area that I see many packaged software implementations lack. The typical challenge I get is "Why document my existing business processes if I know they are changing?" Here are my reasons:

• Business users may not have a consistent understanding of their existing business model. Going through the exercise of documenting business processes will highlight these differences and driver deeper understanding.
• Documenting the existing business model will enable you to highlight the EXACT organizational changes that will occur. How can you manage organizational change when you do not have a clear understanding of what's changing?
• Business process maps can be a key source of information to quickly educate IT and the Implementation Partner on the existing business process model.

2. Educate IT and the Implementation Partner on the existing business model

Business should take a formal, iterative process to educate IT and the Implementation Partner on the existing business model. The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level "day-in-the-life" review. Following is a suggested approach for conducting this training:

3. Complete packaged software training BEFORE the Implementation Partner arrives

Just as it is important for your Implementation Partner to understand your business model and your business language it is important that Business and IT have an understanding of the packaged software and its language. Effective communication is a two party effort. Taking the required packaged software training before the arrival of your Implementation Partner will enable you to more effectively work together.


4. Have the Implementation Partner conduct supplemental packaged software training

Education is an iterative process - you will never learn everything you need to know for supporting packaged software in a classroom. Packaged software providers provide foundational training. I always say that the Implementation Partner completes your packaged software training. Implementation Partners have hands-on experience with configuration and maintenance of packaged software solutions.

5. Implementation documentation should be more business-oriented

Nothing encourages alignment more than being able to think like your end customer. Too often we create project documentation that focuses more on technology than business reasoning and justification. There are times were I am guilty of moving too quickly from what needs to be done to how will it be done without completely understanding why does it need to be done. At the end of the day we build software to drive business results.

Summary

Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust. Implementing packaged software is an opportunity to generate greater alignment by developing a common language for effective collaboration. When alignment is achieved then decision-making is effective.


Adapted from the book Maximize Your Investment: 10 Key Strategies for Successful Packaged Software Implementations by Brett Beaubouef.

Business Processes and Real Management – Part 3

Simply put: If there is no process, it – whatever “it” is – cannot be managed.

The key point here is to separate mere intuitive decision-making from the act of “management.”

Management implies the existence of “a process,” – that is, an understood cause-and-effect relationship in a sequence of dependent events leading to a predetermined goal. There are three critical elements to this definition of “management” and “a process”:

1. The “process” must have a goal or outcome. If there is no goal or outcome that can be stated in advance, then there is no point in attempting to “manage” it, for to manage it would be to somehow affect the outcome of the process (e.g., improvement). If the goal or outcome of the process is not understood or has not been articulated, then there is little need for the act of “management.”
2. The “process” must include more than one step or event, and the steps or events must be related by their sequential dependence. One cannot manage, for example, “the big bang.”
3. The “manager,” in order to manage effectively must understand both the goal of the process and the process itself.

If we return to the examples given, whenever an executive must deal with sales operations as mystical mojo that is carried out in some seemingly inexplicable way by certain persons who were hired because they have a demonstrated facility for working this “mojo,” then that executive cannot be said to be “managing” the “sales process.” He or she may be managing many things related to sales, like the expenses related to sales, the number of salespeople, the sales territory assignments, and more. But he or she cannot be managing “the sales process” any more than he or she would be said to be managing a group of witch doctors in the work they do.

Let me go further to say, that even though the executive may have a “prescribed sales process” that includes a number of “steps,” even if those “steps” are canonized in some CRM (customer relationships management) or other software application; and even if the salespeople are required to “check-off” against these prescribed “steps”; if such “steps” are subject to frequent manipulation by the salespeople or sales managers or if a near-constant series of concessions are being made to the demands of salespeople or sales managers in accommodation to their claims of “mojo,” (or something equally nebulous) then no real “sales process” exists in such an organization. Also, if management is repeatedly kowtowed by what amounts to little more than “threats” that “bad things will happen” if salespeople’s and sales managers’ demands are not met in this matter or that, then I would allege that no “sales process” exists.

Now, I hear you asking: “What difference does it make if we have a ‘sales process’ as long as we are making sales and surviving?”

To that question, too, there is a simple answer: If, as an executive, you do not have a real and manageable “sales process,” then you are at the mercy of the economic winds and the fickleness of fate. In the absence of a manageable process, you cannot know what actions will lead to improvement. Despite your title as “executive,” your only recourse is to try this or try that, because you have no comprehension of the actual cause-and-effect dependencies that lead to more sales or better sales.

Is that really how you want to run what is arguably the leading edge of your business enterprise?

Suggested Reading:

Reengineering the Sales Process

©2010 Richard D. Cushing

Business Processes and Real Management – Part 2

1. (continued) In the second scenario, the owner or chief executive is not in charge of the sales team. In fact, the firm has generally hired an experienced “sales manager” based on this persons history and background of producing sales at some other firm in the same or a similar industry. This person has then hand-selected a team of salespeople, the sales manager often doting over them making certain that each is uniquely satisfied with their particular arrangements. This is a variation on the same prima donna theme, but with a layer of middle management.
   
   In both of these cases, however, the general attitude of top management at the firm is that, while they may give lip-service to something they call their “sales process,” when one digs deeper, it becomes abundantly clear that the “sales department” is really surrounding by mystique. Each hand-picked salesperson has his or her own mystical mojo that is performed in a somewhat ritual-like fashion. This mojo, when properly carried out and when not too much interfered with management and administration produces a life-stream of sales to support the rest of the company.
   
   In these situations, the rest of the company’s executives and managers are under the implicit understanding that “I must not mess with the salespersons’ mystical mojo or things will go badly for the whole company.” Frequently, even top executives fear treading too much on the mojo, for fear there will be bad repercussions.
   
   
2. The second matter is that comes to mind is “sales commissions.” On numerous occasions I have asked executives, “How do you calculate and pay commissions?” A simple question?
   
   To this simple question, I am not infrequently given a simple answer: something along the lines of, “We pay commissions based on gross margins.”
   
   Simple enough, don’t you think? Until you begin to dig into the details. Then one starts hearing things like this: “Well, yes, we do pay commissions based on gross margins. But, if our buyers get a special deal on a purchase, we pay commissions on the ‘regular’ gross margins, not the actual gross margins of the sale of those special purchases.” Or, “Yes, we do pay commissions based on gross margins but, because the contract we signed with salesperson X is different from the deal we reached with salespersons Y and Z, the way we calculate ‘gross margins’ is different for each of salespersons X, Y and Z.”
   

So, I hear you ask, “What is the similarity between my daughter’s situation and the two examples I just mentioned?” The similarity is this: In each case the executive in charge called their decision-making a “process” (or, in the academic world, a “rubric”) or suggested that they were managing “a process” (i.e., “the sales process”). However, close inspection revealed that each decision was being made on a case-by-case basis without reliance upon a process or rubric, at all.
Note, my objection is not to the case-by-case decision-making – although I offer that this is likely not a sound approach to managing a growing SMB. Rather, my objection is to the managers’ beliefs that they are actually managing to a “process” or by “a process.”
(To be continued)
©2010 Richard D. Cushing

Business Processes and Real Management – Part 1

I had a conversation with one of my daughters on the way to the airport today. She was telling me about something that went on with regard to management decision-making at her work. (She works in the field of education, but the principle I wish to discuss applies everywhere, in every type of organization.)

The scenario is something like this: An executive (and here I use the term “executive” in the broadest sense, meaning any manager in a position to not only choose, but also to execute upon the decision made) states that he or she is going to make a management decision based upon a process (or, in this academic environment, a rubric – a process for scoring an otherwise subjective decision). However, upon further discovery and discussion, it becomes apparent to all involved that whatever “process” or “rubric” is ostensibly being applied is purely subjective and intuitive to the manager alone. That is to say, what is pretended to reduce an otherwise purely subject and intuitive decision to a “process” – a “rubric” – is merely that, a pretense. The decisions being made remain purely subjective and intuitive and are not correlated to a “process,” at all.

Now, let me be clear. I am a free-market guy. I believe that business owners and their executive agents should be able to hire, fire and make other management decisions at will. I am fully committed to the fact that they may do as they please so long as their actions do not include coercion or deceit. In this scenario, it is not the executives decision with which I take issue – which is why the decision itself is not discussed herein.

What I wish to discuss is how many times executives and managers are themselves deceived as to the presence of a “business process” or any kind of rubric by which they manage. From my experience, if I spent time cogitating, I’m certain that I could come up with a large number of examples. However, for brevity’s sake, let me just toss out a couple.

1. Foremost in my mind are the numerous discussions I have had with executives over the years regarding so-called “sales management.” I say, “so-called,” because I have too many times been faced with one of two variations on the same theme in this regard. The first is where the owner of the small-to-mid-sized business (SMB) was the companies first salesperson (which is quite natural, as the organization was likely an outgrowth of some entrepreneurial venture) and remains today as the firm’s sales manager. He or she has, over the years, created a sales team of hand-selected folks, and the executive is convinced that each of these salespeople is unique and each requires special handling – a sort of prima donna approach.
   

(To be continued)

©2010 Richard D. Cushing

Changing the game for ERP/COTS implementations

I think we've all learned that implementing ERP/COTS using a traditional approach of (1) focusing on custom software and (2) having a purely requirements-driven approach results in greater Total Cost of Ownership (TCO). ERP/COTS can make for an expensive custom solution. What is required to change this trend is to evolve our implementation approach. Following are my top strategies for changing the game for ERP/COTS implementations:

(1) Focus on Business Results. Too often we focus on software scope and not the entire business solution (People, Business Processes, Technology). A challenge I make to my project team is to focus on all three components that drive business results. Also, spend time/effort on gathering requirements that drive value-add business results. Not all of the customer's existing business results drive real business value.

(2) Ask customers to formalize knowledge transfer on their existing business model. Every customer's implementation is unique and it is important that every member on the project team has a common understanding of the customer's existing business model. This knowledge transfer will enable implementation partners (consultants, IT) to better align with the explicit and implicit expectations of their customer. Implementation partners need to speak the language of their customers. Being in the same meeting or having the latest chat technology does not guarantee alignment nor collaboration.

(3) Implementation partners need to enable customers to lead during the implementation. This requires us to have a formal knowledge transfer plan and a progressive leadership style: Directing, Coaching, Facilitating, and Supporting. A new measure for success: the implementation partner leavers before the go-live because the customer is self-sufficient.

(4) Perform business solution modeling. Use prototyping for defining requirements and modeling to validate requirements/configurations. Use multiple validation techniques (peer reviews, modeling, testing) to identify potential problems.

(5) Implement to the current business process maturity level. Technology alone does not mature a business process. Meeting the customer where they are at will (a) reduce the challenge of emerging requirements, (b) reduce implementation risk, and (c) put you in a better position for a quick win.

(6) Minimize customizations and maximize enhancements. Every customer will have unique requirements that must be addressed via software. Some of these requirements add no material value to desired business results (customizations) while other requirements have a material impact to desired business results (enhancements). This is not meant to be a negative commentary but it deals with the reality that a customer's existing business process is not 100% efficient nor 100% effective (Lean Six Sigma). A key strategy for the project team is to focus on the requirements that drive enhancements and eliminate non value add customizations as quickly as possible (before Fit/Gap).

(7) Negotiate for success. This requires changing the customer's expectation of business software. If the custom expects a custom software solution then the results will be additional gaps, costs, and disappointments. Implementation partners need to understand the potential areas in the ERP/COTS software where software changes can be cost-effective. Negotiation will be required to foster adoption and yet not eliminate the inherent advantages of ERP/COTS.

(8) Accelerate decisions by generating more knowledge and less information. At the end of the day, decisions (not documents) move implementations forward. Sometimes we get caught up in generating too many detailed documents without ensuring they generate value-add results (decisions).

In summary, the key to effective ERP/COTS implementations is to have an implementation approach that maximizes the advantages and minimizes the challenges associated with ERP/COTS software.

Adapted from the book "Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations" by Brett Beaubouef.