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.

Simpler is better: Dynamic Buffer Management (DBM)

Somehow, in the dark recesses of the past, someone came up with the idea that we should (at least in our minds) segregate our regular stock (inventory quantities) from our “safety stock” as if there were some difference between the two. “Safety stock,” APICS and others suggest, is to cover “variations” in lead-time or demand, while our “regular stock” is to cover “normal demand”—whatever that is. But for most businesses today, variation in demand is the rule, and not the exception. Furthermore, isn’t it true that our whole stock quantity is really what we want to manage—not some isolated portion of our stock that we describe logically as “safety stock.”

Simpler is better. Our whole stock quantity should buffer the system (read: the whole enterprise) from losses in throughput (read: profits).

For years I have worked with small-to midsized enterprises (SMEs), many of which I first touched when they were in transition from entrepreneurial to enterprise in nature. When I found them, they generally knew very little about their inventory. Oh, sure: they knew in a general sense which items were profitable and which were not. They also had a general handle on which items in their inventory were the “fast movers” and which were “the dogs.” Nevertheless, when it came to managing their inventory quantities they almost all struggled with the all too common problem of being sold-out of some items (and thus incurring losses of potential sales and profits) while, at the same time finding that they were overstocked on dozens of other items (so that they were simultaneously incurring high carrying costs and lower cash flows as a result). The problem was, from month to month, it was almost never the same items that were sold-out versus over-stocked. They could never predict what quantities were going to sell, so they couldn’t predict what quantities to stock.

Constraints management (Theory of Constraints) suggests—as I said above—that our whole stock of any item (taken in total) should serve one purpose: to buffer the system from losses to throughput. Now, it is not the purpose of this present writing cover all of the various details of a full Dynamic Buffer Management solution. The simplicity of Dynamic Buffer Management (DBM) is what makes it so appealing. The following is a real-life application of DBM in action.

The raw data we have on our example SKU looks like this:

We have just two months of data from 2007, full years’ data from 2008 and 2009, and a partial year for 2010. Note that demand in 2008 was fairly stable, ranging between 72 and 220 units per day. However, demand is 2009 become wildly erratic—ranging from just 1 unit per day to 389 units per day. Over the entire recorded history for this SKU, we find the following statistics:

If we graph these data, the results look like this:

Now, it’s nice to know that a third-order polynomial curve fits pretty nicely with a six-period moving average of these data, but most SMEs do not have a staff statistician available to them to help analyze all their inventory history in order to determine how to set parameters like stock levels, safety stock, reorder points, line points and more. Nor, do they have confidence that statistics will necessarily serve them better than their intuition has in the past.

What they are looking for is something SIMPLE, RELIABLE, EASY TO UNDERSTAND and EFFECTIVE. Dynamic buffer management is all of that.

Let’s imagine that we are at the end of year 2008 and we want to set up DBM for year 2009. We’re going to do so based on our 2008 history.

The first thing we need to know is: how big should our starting buffer be for this item?

Well, it ain’t rocket science! Establishing a starting buffer quantity requires the knowledge of a few facts because it is more important to be “approximately right” than to be “precisely wrong.” No matter how much precision (read: time, energy and money) is put into calculating a “precise number” for the size of the buffer (or any other business ‘forecast’ number) that number will end up being “precisely wrong” 99.999 percent of the time.

So, to find an “approximately right” number for the starting buffer is more important than finding a “precisely wrong” one. In our example, we used the following formula:

Starting Buffer Size = average period consumption over the Last 12 months + (safe replenishment time in days * average consumption/day * 2 * paranoia factor)

Some of these numbers are arbitrary:

1. “Safe Replenishment Time” is nothing more than a “safe” estimate of the time it would take to replenish the item under normal circumstances. Almost anyone working in purchasing or replenishment or manufacturing can pick that number for items with which they work day-in and day-out. If one says, “Five,” and another says, “Eight,” then use eight. It’s that simple.
2. The number “2” used in the formula is also arbitrary. It is nothing more than an additional safety factor to cover unusually high demand or unusually slow delivery. In a moment you’ll see why it is not terribly important in the long run.
3. “Paranoia Factor” is our third arbitrary number. This value is used to cover management’s concern about things like:
1. “Our inventory will skyrocket” – so let management set a paranoia factor of less than 1.0 on some items
2. “If we run out of this item, we lose sales on other things, too! – so increase the paranoia factor
3. “This is a high-margin item and we don’t want to lose a single sale” – so make the paranoia factor larger

For our example, we calculated a starting buffer size of 11,954 base on a paranoia factor of 1.000. Let’s watch what happens using the actual consumption figures from year 2009.

Now, let’s see how DBM helps us out:

• Period 1: We just stocked up to almost 12,000 units and in period one we had the worst month ever! We sold only 23 units! Have we done the right thing here?!?
  Even though it seems like we have plenty of stock, we follow our basic rule: Whatever we consume, we replenish. So, we place a replenishment order for 23 units.
  
  At the end of the period, our “Buffer Status” = 99.81 percent. We have almost a full buffer.
• Period 2: Things return to normal now. We consume 3,315 units, we get our replenishment supply of 23 units, and we end the period with a buffer status of 72.27 percent. That’s okay. We really don’t get concerned as long as the buffer remains in the green zone—that is, above two-thirds.
  
  We dutifully place our replenishment order for your consumed quantity—3,315 units.
• Period 3: We consume 2,153 units and get our 3,315 units from our replenishment order. True to form, we order replenishment for the 2,153 units, and we end with the buffer solidly in the green at 81.99 percent.
• Period 4: Wow! We consume 7,903 units; get our replenishment of 2,153 units and our buffer status ends up in the red zone. The red zone is a buffer below 33.33 percent full. [NOTE: Here I’m going to play along with some anomaly in Excel’s failure to calculate and apply conditional formatting correctly. We’re at 33.89 percent and this should be “Yellow,” but it’s not. Excel says it’s “Red,” so we’re going to call it “red.” Close enough!] We take no immediate action other than to note that this is the FIRST PERIOD in which our buffer has fallen into the red zone.
  
  We place our standard order to replenish period consumption.
• Period 5: We have another great period for this item. We consume 8.476 units; get our replenishment order for 7,903 units, and end the period for the SECOND PERIOD IN SUCCESSION in the red zone. The buffer reached 29.09 percent.
  
  Other than placing our replenishment order, we take no specific action.
• Period 6: We’re hit with record sales and move 11,666 units. Even after replenishment order arrives, we still are sitting near the bottom of the red zone at 2.41 percent.
  
  Since this is the THIRD SUCCESSIVE PERIOD where we have ended up in the red zone for this buffer, we take action to INCREASE THE BUFFER SIZE BY ONE-THIRD. Our replenishment order is now for the 11,666 units consumed PLUS the buffer increase of 3,985 units.
• Periods 7 and beyond: We will continue to monitor and manage the buffer dynamically applying these simple rules…
• THREE CONSECUTIVE PERIODS IN THE RED ZONE, then INCREASE the BUFFER by ONE-THIRD
• FOUR CONSECUTIVE PERIODS IN THE GREEN ZONE, then DECREASE the BUFFER by ONE-THIRD

As you can see, this is a very SIMPLE, YET EFFECTIVE, way to facilitate stock management. There are some other principles that should be understood—such as the fact that the BUFFER actually contains both the stock in the warehouse and what is in-transit (or, in manufacturing, if a make-item) and is due within one “Safe Replenishment Time” period.

This is so simple!

Most inventory systems could do this with relatively minor tweaks. It is really just managing inventory by “max stock level”—when quantities fall below the maximum stock level, replenish back to the maximum stock level—with some kind of data view (perhaps even using Microsoft Excel™) to display the buffer status with action signals.

Let me know what you think.

[Cross-posted at Kinaxis Supply Chain Community.]

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