On Value Pricing

I pick on software vendors and VARs a lot in my writing, not because I dislike them. Rather, because I believe that the vast majority of them are increasingly shortsighted. Their customers and marketplace are changing rapidly and dramatically and they are staying the same. They remind me of the lawyer profession after the telephone was invented. Attorneys were some of the last businesses to take on the new telephone technology and then, they did it only at the insistence of the clients -- because their clients wanted to call them!

While I have carried around the concept of value-pricing for some years, I cannot claim credit for inventing the concept (I don't know who did, but I'm pretty sure it wasn't me), and I am not foremost among those that promoted it over the years. VeraSage Institute is a leader in helping professional firms develop and institute value-based pricing for their services. In fact, the link underlying the heading of this article will take you to a FREE WEBCAST from Ronald Baker, founder of VeraSage on the topic of "Measure What Matters to Your Customers."

Nevertheless, an email I received included a quote from Luci Swindoll:

"It has been said that sixty-five thousand thoughts float through our minds each day. Every one of those thoughts has the seed of possibility in it. We choose with our will what we'll do with that thought. Will we stay stuck in 'If only...' or 'Why me?' -- or will we open our minds to 'What if?' and 'Why not?'"

This quote trigger me to reply to the business associate who sent it to me.  Here is my reply:

This brings up an important factor about “knowledge workers.”  Thoughts occur in an instant.  A thought may come into being through years of conscious and subconscious “mulling,” but the thought, when it arrives, is instantaneous.  Breakthrough thoughts are, interestingly, more likely to occur in the shower or in the midst of a long commute, simply because the mind is given opportunity to “think” without a lot of distracting things and “requirements” pressing.  Unfortunately, most businesses are all about “doing” and less about actually taking time to “think.”

Consider this: If an advertising agency staffer has an idea during his morning shower that is worth millions of dollars to one of the firm’s clients, should the agency bill the client for 15 minutes? An hour? What was that “time” worth to the agency and its client?

If the formula for success in a knowledge-based company is nothing more than PROFIT = Capacity * Efficiency * Cost-based Price (e.g., hourly rate), then the only ways for the firm to improve its profits are:
1. Add capacity
2. Work current capacity more hours (i.e., Efficiency)
3. Increase its cost-based rates

However, if the firm discovers value instead of cost, its formula for success becomes PROFIT = Knowledge * Delivered Value.  Under such a circumstance, the advertising agency can bill its client for some share of the value delivered by the multi-million-dollar idea that its staffer had in the shower.  The firm’s profit potential becomes virtually unlimited and, what they need to garner and preserve in the organization – indeed, what the organization needs to value – is more ‘knowledge’ in the organization, not more ‘capacity’ or ‘efficiency.’  Adding capacity only increases overhead that is troublesome in economic downturns, and increasing “efficiency” isn’t always possible (especially in downturns of the economy).

Suppose the advertising agency we are using in our example were to go to its client, and the client agrees that the idea is likely to generate an increase in Throughput (Revenues less Truly Variable Costs) by $4.5 million over the next 12 months. Let us further suppose that the typical billable work for this particular campaign would have been $250,000.  Now, the ad agency makes an offer thus: “We are going to charge you $150,000 (in advance) to put this campaign into effect. And, we will share the risk with you for the expected results as follows: Based on agreed accounting methods for this campaign, you will pay us 15% of your increase in Throughput each month over the next 12 months.”

If the agency-client jointly-concluded estimates are correct, the ad agency will get $150,000 plus $675,000 ($56,250 per month for 12 months) for a total of $825,000.  That’s $575,000 more than the originally estimated $250,000 in hourly billings.

There are multiple advantages to this, not the least of which is the fact that if the firm does this regularly, it will develop an annuity stream of (e.g., monthly, quarterly) income that will sustain the firm during economic downturns and thus allow the firm to hold onto the talent and knowledge it has worked hard to attract to its work environment.

Just some things to think about from the “Thought for the Day.”  What if…?  Why not…?

I owe much of the credit of my response to Ronald Baker and what he presented in the FREE WEBCAST linked above, but the concept has been with me for many, many years.  My thanks to Ron and VeraSage for reminding me just how important it really is.

Please feel free to email me if you would like help in developing value-based pricing at your firm.

(c)2010 Richard D. Cushing

Constrained by your ERP?

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

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

Thanks.

...

The New ERP – Part 37

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

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

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

What is it about "business requirements"?

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

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

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

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

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

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

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

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

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

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

What "business requirements" should look like

No.	What must be delivered or accomplished?	What is the expected business value to be delivered as a result?
1	Implement a supply chain integration and visibility solution directed at reducing stock-outs in among the top 20% of SKUs (rated by Throughput) to fewer than 5 per month	Increase Throughput by 12.5% where 9.5% (over 9 months) of the increase comes from recapturing what would have been "lost sales" and the remaining 3.0% (over 6 months) come from Sales Management's commitment to regain customers previously lost due to what customers deemed to be our lack of reliability as a supplier for these SKUs
2	Implement a business intelligence (OLAP) solution to provide the Sales and Marketing Departments with visibility into sales data by customer, salesperson, sales manager, region, and other demographics for the express purpose of establishing viable "market segmentation" for use in the development of "irrefusable offers" by market segment (to a single customer, if required)	Increase Throughput by 22% (over 12 months) in accordance with estimates and concepts outlined by the Sales and Marketing Departments without increasing Operating Expenses
3	Eliminate paper-based picking, packing and shipping in the warehouse with the goal of being able to accurately pick, pack and ship 16 average orders (~117 lines) per hour in order to support increasing Throughput without increasing Operating Expenses	Hold-the-line on Operating Expenses while increasing the capacity of the warehouse shipping function to an average of 16 orders per hour with greater than 99% accuracy

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

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

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

Works Cited

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

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

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

The New ERP – Part 29

What makes technologies valuable?

Let us stop for a few moments to think about just what it is that makes new technologies valuable to a business enterprise. If we take this time to think, it should occur to us that there is no inherent value in new technologies. Just like everything else that resides within your enterprise, new technologies only add to Operating Expenses (OE) in and of themselves. It is only in the application of technologies to business processes that value may be found.

Interestingly, the value delivered through the application of technologies to business processes may be broken down into three elementary categories – categories that we have discussed on numerous occasions elsewhere in these posts:

1. Increasing Throughput (T)
   
2. Reducing Inventories or driving down the demand for new Investment (I)
   
3. Cutting or holding-the-line on Operating Expenses (OE) while sustaining significant growth
   

If you and your management team are going to purchase new technologies as part of a process of ongoing improvement (POOGI), you will know – or should recognize – automatically that you will either increase Investment (capitalized purchases) or increase Operating Expenses (in at least one year), or both (since any capitalized purchase will be amortized as an expense over multiple future periods. Therefore, it is also important that your team has compared this proposed improvement project with other improvement options using this simple formula:

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

Where ROI = Return on Investment,
T = Throughput (Revenue less Truly Variable Costs only),
OE = Operating Expenses, and
I = Investment.

As you can see from this simple formula, the ROI is maximized by achieving the highest value for delta-T while holding delta-OE and delta-I as low as possible. This leads to a very simple set of priorities:

1. Projects that increase Throughput are generally a top priority
   
2. Projects that reduce Investment (including reductions to inventories – being the most common reduction in Investment) should be considered next
   
3. Projects that reduce Operating Expenses are generally reserved for last for consideration
   

The Technology Value Matrix

If you will review carefully the accompanying figure you will see immediately something about what makes new technologies or, more appropriately, new applications of technologies valuable. In this matrix, the lowest value values are to the lower left - "Commodity Technologies." Commodity technologies are those that are widely available, they tend to have a "standardizing" affect on the enterprise, and they are generally applied in a typical (read: non-innovative) way. Examples of such technologies include desktop computers, graphical user interfaces (GUIs), network servers, relational or other databases, and so forth.

So, what would a "Wasteful Technology" or technology application be?

Consider a small business that has a typical range of departments. They do everything from R&D to shipping and receiving, invoicing, and general ledger accounting. In the shipping department is a bright young lad that never completed college, but he is a hard worker. He is effective, full of good ideas, and does whatever it takes to keep customers happy inasmuch as it lies within his power to do so. The president and founder of this young company still works in the R&D department helping to design the next generation of products. This firm generally introduces four to six new products a year, so the president doesn't even work in R&D on a full-time basis. On the other hand, the young man in shipping is constantly working 50 or 60 hours a week trying to assure that the firm's customers' orders are filled on-time.

While this scenario is not based on any particular client with whom I have worked in the past, the general scene is not all that distant from far too many clients in my experience. All too frequently, if an investment is going to be made in technology, the president and R&D 'guru' is far more likely at having $10,000 thrown toward a high-end CAD workstatation, while the guy working 50 or 60 hours a week in shipping remains stuck doing his work on a six-year-old machine that is long past its prime. Or, worse, the guy in shipping is still filling out paperwork on shipments by hand, and these data are then being keyed by someone else into the firm's accounting software.

Let's compare these two options based on the following (usually true) assumptions:

• The firm does not expect the technology investment in R&D to accelerate time to market, the frequency by which new products are introduced to the market, or have any other affect leading directly to increased throughput
  
  
• The firm will not include in its calculations any supplementary beneficial effects on Operating Expenses that my accrue through increased accuracy, support for significant growth, or the elimination of potential data redundancies under the old regime
  
  
• Investment (delta-I) will be the same for each option
  
  

Improvement Option	Effect on Throughput	Effect on Investment	Effect on Operating Expenses
New CAD workstation for President in R&D	No increase in Throughput	Increase by $X	Increase by $Y
New automation for shipping	Yes, increase Throughput	Increase by $X	Increase by $Y (amortization of investment) LESS decrease in overtime wage expense

Time and time again I have spoken with companies that make just such foolish expenditures on new applications of technologies. Why would a company make a decision to spend money for what is clearly zero-dollars in net benefit to the organization?

The answer is usually found in one of two areas:

1. Company politics – the investment goes to the person or department with the greatest "pull" in the organization
   
   
2. The company's management team simply considers all IT expenditures an "expense" and, therefore, never calculates a return-on-investment
   

Such an approach is folly on multiple counts, but considering that time, energy and money are all limited resources within a firm, it seems blatantly silly to "spend" any of them where there is no return on the "investment."

That, in a nutshell, is a display of "wasteful technology." Since the firm had no deliberate plan to do anything particularly "differentiating" along with the purchase of the new CAD workstation for the president, and since CAD in itself is "standardizing" (not "differentiating"), the high expense for an engineering "workstation" made about as much since as the purchase of a $10,000 Rolodex™ for one of the secretaries.

[To be continued]

The New ERP – Part 22

What else might change the value proposition of a technology initiative?

We have already pointed out the foibles of the traditional "aim-and-shoot" approach to IT initiatives and their proclivity toward considering every matter in terms of "cost," rather than "value." (See prior post in this series.) We even pointed out some of the factors that may change the value proposition for an IT initiative well after the project launch. But, what else might have an effect on the value proposition of an IT project aimed at "improving" a company like yours?

Earlier we mentioned things like the introduction of new products, changes in the economy, or even public policy changes that might change the value proposition for a technology deployment. Now, however, we need to turn our eye to technology-specific elements that might also affect the value proposition of a project already underway.

I am not sure why, but my more than 25 years in dealing with business technologies has clearly proven to me that firms reaching out to make technology purchases assume (far too frequently) some measure of clairvoyance on the part of their technology vendors. It is clear, and the purchasing companies' management teams seem to recognize, that they cannot know everything there is to know about the technology they are buying. However, that same management team will somehow come to the tacit conclusion that the technology vendor must know and understand all there is to know about the company that wishes to buy and deploy their technology.

Okay! Maybe I'm exaggerating; but just a tiny bit.

The managers on the buying side may not actually assume that the vendor's team understands or knows everything about the buying company's firm and operations, but they generally do assume that the vendor's team knows and understands enough about the prospective purchaser's company and operations to ask every possible question in order to assure that every facet of the product or services provided will fit precisely the customer's expectations. Never mind that "expectations" are never plainly visible to either party in the transaction. Expectations far transcend anything placed in any agreement or "requirements" document. Expectations may be reduced to the number of mouse-clicks it takes to navigate a certain transaction, or the "look-and-feel" of screens, or where data is placed in the user interface. The list of expectations is, literally, without end. In fact, the purchasers themselves may not know or be able to articulate their expectations. They only know when their expectations have not been met.

The point is this: As a buyer, you and your management team need to recognize that, when first engaging a technology vendor, the vendor knows proportionately as little about every facet and detail of your enterprise as you know about every facet and detail of their technology and services. In essence, you have witnessed "a demo" of their technology and they have experienced "a demo" of what your company is like. Therefore, it is incumbent upon you, as the buyer, to beware – caveat emptor. You and your team must thoroughly and precisely know what you want and need the technology vendor to do in order to effect the change you have in mind – the change derived from your Current Reality Tree that will help your company reach more of its goal of making more money.

At this point, an "on the other hand" would be nice to hear. Am I right?

On the other hand, there actually is an upside to this mutual blindness between technology seller and technology buyer. Frequently I have experienced situations where, as the vendor and the buyer learned more about each other's technologies (on the one side) and operational requirements (on the other), fresh new insights emerged about how the buying firm could leverage to great advantage previously undisclosed features or functions in the technology. A management team employing the value-based New ERP approach can readily see that the presence of some unanticipated feature, function or capability might radically increase the value proposition to the organization. Unfortunately, this kind of value serendipity is sometimes missed entirely by tradition-bound managers and vendors totally enmeshed in "meeting documented requirements," deadlines and budgets.

[To be continued]

©2008, 2009 Richard D. Cushing

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]