Who moved your cheese?

Who moved the productivity cheese?

“Who Moved my Cheese?” is the title of a great little book on change by Spencer Johnson. If you haven’t read it yet, I recommend it. It stars two mice, Sniff and Scurry, and two small people, Hem and Haw. All four get up every morning to go to chese station C to get their fill of cheese, until one day there’s no more cheese. Sniff and Scurry quickly run off to find new cheese. But Hem and Haw–well they hem and haw. They keep showing up at Station C hoping that tomorrow will see their station refilled. But of course that particular cheese is gone.

Businesses have spent the last 100 years getting their productivity cheese from Station “Task Efficiency.” It worked really well at first. We automated tasks to be faster and cheaper and lo and behold we got higher productivity which led to higher value. But today new systems are implemented that often have no discernible effect on value. Even process improvements seem to work at first, but then initial gains are lost.

Could it be that Cheese Station “Task Efficiency” is out of cheese? Are you still looking for it?

So, who did move my cheese?

I think the title for the book should have been “Who ate my cheese?” rather than “Who moved my cheese?”

The thing is: no one moved the cheese. The organization has been eating the cheese over the decades. Every time an attempt is made to make things cheaper through task efficiency, a bit more of the “task efficiency” cheese is gone. Initially the cheese was manual work done by people. This cheese was eaten away by machines. Then it was clerical work. This cheese was eaten away by business software. When an old machine is replaced by a new one, or when new software replaces old software, we don’t see the same gain as we did the first time. Of course that makes sense because that cheese has already been eaten. New machines and new software may prevent us from backsliding but they don’t move us forward much anymore.

Virtually every methodology in existence today, from Lean to Six Sigma to Process Engineering is based on the same principles: look for ways to to cut task waste and look for ways to speed up the remaining task work. Both strategies attack task efficiency. And I only say “virtually all” instead of “all” because I can’t prove that it’s actually all methodologies, although that’s what I believe.

Task efficiency assumes that increasing productivity (ability to produce more stuff) will result in more value. This was initially true. Now, producing more stuff doesn’t usually produce more value. So what’s a guy to do?

So far, we’ve been like Hem and Haw going back to the same “task efficiency” station hoping that someone will replenish it. But we really need to be more like Sniff and Scurry. We need to stand back and smell the cheese or lack of it like Sniff and Scurry. But they had a big advantage. First of all, they could detect the diminishing smell of cheese. Secondly, because there was less smell from the current cheese they could better smell large piles of better cheese that was further away. 

Enter the Relational Process Model described in More Perfect by Design. Using the principles outlined therein, we can develop and organization version of  “Sniff” and “Scurry”. We must develop what nature has deemed fit not to hardwire within us.  We need a ”Sniff and Scurry” scorecard that tells us when a certain kind of cheese is about to end and where to go for new,  more valuable cheese. And what is that new kind of cheese? It’s value. We need to start looking for value waste if we want to again capture significant gains.

What we need is some way to smell how much opportunity is left within the current process paradigm and when we need to seek a new process paradigm. We need a way to help us sketch out what the new paradigm might look like so that we can more easily find it. The Relational Process Model is a framework that helps us do both. It helps organizations become more like Sniff and Scurry and less like Hem and Haw. It helps an organization become value aware and value effective in addition to task efficient.

Learn all about the first true integrated business modelling framework for designing and managing business processes.  To learn more about the book, please visit www.MorePerfectByDesign.com. It’s available from your favourite online retailer.

Angelo Baratta

Performance Innovation

 

Accountability as motivation …

The root cause of root causes …

“Every function takes the limits of its field of vision for the limits of the world.” - Arthur Shopenhauer  (modified slightly by me)

Accountability is what defines that field of vision. In most hierarchically designed organizations, it is the function silo that determines which problems it will solve and how it will solve them. In my previous post I suggested that a function will only solve those problems that directly impact it and that it causes (Type 1 or IN-IN problems). Type 2 problems (impact the function but caused by another) will be ”handled” or “resolved.” Put another way each such problem will be re-solved, managed or handled (MH), that is, they will be solved every time they occur, which is often. Type 3 problems (caused by the function but impacting another) will be ignored by the function because from its point of view, it isn’t a problem.

Look at the diagram below. It shows problems as arrows. The head (pointed end) indicates the location of  impact. The tail (circle) indicates the cause. On the left we see that function B has a couple of problems (Type 1) whose impact and cause are completely inside the function. On the left is a diagram that shows what the situation is likely to be after some time has passed.  The Type 1 problems have been solved. They are gone. But Type 2 and 3 problems will remain. In most organization, these problems will never go away, unless we establish a higher accountability that includes the cross-functional problems.

The end result is that every function in an organization ends up handling or resolving a list of problems which are caused by other functions. So the question is “If I’m causing your problem and you’re causing my problem why don’t we get together and solve each other’s?” The answer lies in accountability. Accountability is about the ability to account for a particular effect. Accountability is about caring about a certain impact. Accountability is an organizational motivator.

If I know that I’m causing a problem to some other function but am not accountable for that effect, then I have no reason to care about the effect.

In a functionally organized enterprise, there are always cross-functional effects for which there is no defined accountability. So there is no one to care about those impacts. The only way to solve those cross-functional impacts, in the absence of defined accountability, is through “goodwill” or “teamwork”, which is difficult to come by. Type 2 problems require that one function makes an investment (sows) while a different function benefits (reaps). Such goodwill is not sustainable.

The solution, of course, is to ensure that there is defined accountability for cross-functional impacts, not just functional impacts. This requires two distinct steps:

1. Implement accountability to prevent any function from creating negative impacts in other functions.
2. Identify negative impacts already in place and implement a root-solution to them.

Don’t rely on goodwill. Rely on good management. Too often organizations attempt the second step without implementing the first. This makes the improvement non-sustained. In other words, given time, the problem will re-establish itself.  Accountability tells us what we need to account for and who needs to care about it. The accountability structure should always be designed before the functional or authority structure, not the other way around. Accountability design is a critical step in total organization design.

Consider reading Chapters 3 and 4 of More Perfect by Design to learn more about the concept of an Accountability Chart of Accounts. To learn more about the book please visit www.MorePerfectByDesign.com.

Attending ProjectWorld/BAWorld on May 17? Consider attending my presentation. For more info click here.

Angelo Baratta

Performance Innovation

 

The single root cause of project failures …

The root cause of root causes …

“Every person takes the limits of his field of vision for the limits of the world.” - Arthur Shopenhauer 

Go to your web browser and search for “top 10 reasons for project failures” and you’re sure to get plenty of hits.

The top ten list changes little over time. In the end, the list seems to be a constant. If we know the reasons why projects fail, shouldn’t we expect success rates to consistently rise instead of plateau? The answer is “It depends.”

Below is a summary of project success rates according to Standish—publishers of the well-known Chaos report.

	Year 2009	Year 2006	Year 2004	Year 2002	Year 2000	Year 1998	Year 1996	Year 1994
Successful	32%	35%	29%	34%	28%	26%	27%	16%
Challenged	44%	19%	53%	15%	23%	28%	40%	31%
Failed	24%	46%	18%	51%	49%	46%	33%	53%

From 1994 to 1996 there is an initial jump in success to almost double. That’s progress. Then it plateaus entering a period of staggres (stagnant progress) levelling off at about one project in three. There are many reasons why projects fail but only one cause that persists. This is typical of progress in many disciplines including: Business Analysis, Process Improvement, Project Management, Six Sigma, and many others. Each of these eventually comes up against the same single constraint. It is behind most project failures and it is the primary obstacle to progress.

Want to know the reason behind the reasons?

Today I’m going to share that single root cause. It explains why things plateau in any discipline, not just project management.

____________________________

In any discipline, the first capability that we develop is our ability to solve functional problems. Punctional problem solving is a key skill both for individuals and for organizations. Our approach to problem solving is what causes both the initial jump and the subsequent lack of further progress. To determine why this happens, we need to understand the “field of vision” of a function and learn how functions go about solving problems. First let’s revisit our opening quote in terms of a function.

“Every function takes the limits of its field of vision for the limits of the world.” - Arthur Shopenhauer  (modified slightly by me)

The field of vision of a function determines which problems it will solve and how it will solve them.

But what is a problem? It is  ”an undesirable effect that we are experiencing and that we don’t want to experience.”  In any function there are three kinds of problems:

1. Type 1 (IN-IN): A problem whose impact is inside the function’s field of vision and whose cause is also inside its field of vision.
2. Type 2 (IN-OUT): A problem whose impact is inside its field of vision but whose cause is outside its field of vision.
3. Type 3 (OUT-IN): A problem whose impact is outside its field of vision but whose cause is inside its field of vision.

Every function, person, and discipline will look for solutions to type 1 (IN-IN) problems  first. Since the cause of these problems is inside our field of vision, we tend to look for true solutions. A true solution removes the cause so that the problem no longer occurs.  To the function this is a true solution that reduces the frequency of the problem. For every such problem that we solve, productivity goes up.  Solutions will increase success.  It’s easy to determine if a discipline is in this phase–the list of problems will change as solutions are developed. Of course, at some point, we run out of such problems. So we turn our attention to the next type of problem.

A type 2 (IN-OUT) problem has its impact inside our function but its cause outside our function, usually in an upstream function. Since we can’t change the other function, we ask the question “How do we deal with these problems?” What we end up with is a resolution to the problem. What’s the difference between resolving a problem and solving a problem. Resolving means re-solving, or solving again. Since we haven’t changed the cause, the problems will still occur for future projects or transactions. Our resolution simply reduces the impact of the problem. Of course re-solutions have a price and they are rarely effective, meaning we still suffer much of the impact.  This is why we plateau. Since the problems occur project after project and since we are only reducing, not eliminating, the impact, the improvement is not as marked. Re-solutions tend to decrease failure rather than increase success. It’s easy to determine if a discipline is in this phase–the list of problems will remain fairly consistent from year to year. There may be a little movement in relative positions, but overall it’s the same list. Of course the list cannot go away since the problems haven’t been solved. They are simply being handled. Plateauing happens because the underlying problems remain.

That brings us to the last type of problem. The type 3 (OUT-IN) problem has its impact in someone else’s function and the cause in ours. Of course since the impact is in someone else’s function, we don’t really have a problem. Functions will rarely address Type 3 problems becuase they’re usually too busy coping with the type 2 problems. Of course a type 3 (OUT-IN) is simply someone else’s type 2 (IN-OUT).  So really there are only two types after all.

A type 1 is a functional discipline problem. A type 2 is first a management problem, then a cross-functional problem. It can’t be solved at the functional level alone. And all too often these kinds of problems get ignored until they are no longer tolerable. Of course that’s when we re-organize or dis-organize (go out of business).

The root cause of most project failures is that projects are stuck coping with type 2 problems whose root cause lies elsewhere. Of course not all project failures are caused by these, but this is where the majority lie once we get beyond the initial stage of any discipline. So if I’m causing your problem and you’re causing my problem why don’t we get together and solve each other’s?

We’ll begin to explore that one on the next post.

Want to know more on this topic? Consider reading Chapters 1 and 2 of More Perfect by Design. To learn more about the book please visit www.MorePerfectByDesign.com.

Angelo Baratta

Performance Innovation

Welcome …

In order to reduce the volume and complexity of problems, we should seek to discover a more perfect solution. And what is a more perfect solution? It is a solution with the following properties with respect to the current solution:

1. It is better for at least one aspect.
2. It is as good for all remaining aspects.
3. It is worse for none of the aspects.

A more perfect solution creates no new problems. A more perfect solution does not give up one measure for a gain in another. More perfect solutions are more difficult to discover than “better” solutions. This book provides a framework for the discovery of these solutions. In order for an organization to sustain continuous progress, it has to continuously implement more perfect solutions. Otherwise, it will stagger forwards and backwards.

More perfect is a higher standard than “better.”

I invite you to check in from time to time as I explore various parts of the book.