kaizen

Many project management models are based on Robert Coopers original Stage-Gate model [1][2]. My experience is that it is often misunderstood. Two common such misunderstandings are:

• That the stages in the Stage-Gate model imply a waterfall development process in which development activities are mapped onto the stages and performed in a strict sequence.
• That a Gate is some sort of project impediment or, marginally better, any old milestone.

I will below suggest alternative perspectives. But first some background.

Risk and reward

The goal of most project management actions should be to maximize the value of the project. Net present value (NPV) is one way to measure the (expected) value of an investment such as a project [3].

The NPV of a project is the additional profit from the project as compared to other projects or other investments with the same risk level. A project with zero NPV is comparable with the “average” project or other investment with the same risk. Projects with NPVs greater than or equal to zero are thus worth pursuing. NPV can be seen as the ultimate result of the business case for the project. NPV is calculated as follows:

Here C_t is the expected cash flow for the project at time t and D_t is a discount factor at time t. D₀ equals 1 and D_t is always less than D_t+1. A negative cash flow is a cost, a positive cash flow is an income.

The empirical reason for discounting future cash flows is twofold: (1) one unit of money now is worth more than one unit of money tomorrow (money today can be invested to get more money tomorrow) and (2) certain (risk-free) money is more worth than uncertain (risky) money. The discount factor accounts for both these facts. A large D, due to high risk, will result in a lower NPV and therefore a less attractive project.

The NPV formula is really your best guess at any given point in time and subject to decisions and unforeseen events. It will therefore inevitably change as new facts unfold. It also assumes that you hold a whole portfolio of investments (such as projects) so that all risk that can be diversified away is eliminated. In a company setting you most likely don’t have that option. There is the department budget that you need to adhere to or run the risk of losing your bonus. And try to explain to your boss that you wish to start another 29 projects to diversify your risks. So you better deal with that project specific risk too! Despite its limitations, we can still learn a couple of things from the NPV formula:

• Cash sooner is better than cash later so a short project execution time is most often a good thing. I addition to the discount factor effect, customer preferences are likely to change during a long project execution time which may make your product obsolete even before it is released.
• Other things being equal, a risky project is worse than a risk-free project. Most managers prefer a €10 000 income with 100% certainty to a €10 000 000 income with 0.1% certainty. (And the Mediterranean debt being what it is they will soon enough prefer $10 000 to €10 000.)

In [1] Cooper also explains:

• The higher the amount at stake, the lower the tolerable risk. We thus need to lower the project risk level at the same pace as, or faster than we increase the amount at stake (investment). We don’t want to find out that the cold fusion drive that we bet our project on didn’t really work after having designed the rest of the space ship and built the first prototype. Instead we should buy an option by spending some money early on for securing that the cold fusion drive will work as intended.

Any old milestone. Or is it?

We thus need to control both the projected cash flow (the NPV calculation) and the risks throughout the project, as part of the project management activities, and try to get rid of the major risks as early as possible to make those later (and probably larger) investments as risk-free as possible.

The gates of the Stage-Gate model are good points in time to reassess the cash flow and the risk level, i.e. the business case. Ideally this should be done continuously but for practical reasons we have to settle for a few gates at strategic points in time.

Back to the misunderstandings at the beginning of this post:

Stage-Gate is no waterfall

It is easy to map the phases of a Stage-Gate model onto the phases of e.g. a waterfall system development process. The first Stage-Gate phase would be mapped onto the requirements analysis phase, the next onto a design phase and so on. From this sort of mapping it is then easy to arrive at a simplistic interpretation of the gates too. A condition to pass the first gate would mean that “all the requirements are frozen” etc.

Now, since we want to get rid of risk as early as possible, focusing on collecting every single requirement in the beginning of the project may not be the entirely right thing to do. Most of the early risk does have with requirements to do but not all of it. We may already know most of the requirements even though they aren’t written down yet and there is instead a major uncertainty about the feasibility of a certain technical solution (think cold fusion drive), about a new supplier partnership or some other issue not related to the requirements. Then these risks must also be mitigated early on, perhaps before writing down all the requirements and freezing them.

An approach in which all requirements must be frozen at a certain gate is thus often not optimal from a risk reduction point of view.

A Gate is not any old milestone

A Gate is an occasion when the NPV calculation and the risk estimates should be reiterated. Project cost estimates may have changed, the market demand (~ income) estimates may have changed, and the risk estimates may have changed. We may in particular not have reached the risk level we were targeting at the particular point in time. If not, then some further risk reduction activities are needed before committing more money, especially if the next phase is an expensive one.

A Gate only used as a regular milestone without reassessment of the business case including the risk level is a waste of time for the project steering committee and the other participants of the Gate meeting. Regular milestones can and should be tracked by the project manager.

* * *

The Stage-Gate model is a great tool for managing projects if used right. Used in the wrong way it adds bureaucracy without giving the expected benefits.

Links

[1] Robert Cooper. Winning at New Products. pp 123. Basic Books. 2001.

[2] Product Development Institute

[3] Richard A. Brealey and Stewart C. Myers. Principles of Corporate Finance.McGraw-Hill. 1988.

I have rewritten this post numerous times, I have deleted it and republished it. This is typically a sign of that I have a gut feeling about what I want to write but I haven’t yet been able to put words to that gut feeling. The rest of this post is my latest (but perhaps not last) attempt to find those words.

Everybody is looking for quick fixes to complex problems, especially if the problem initially doesn’t look all that complex and a fix is needed yesterday. Unfortunately quick fixes (with emphasis on the “fix” part) to complex problems are rare. A couple of examples of problems and their corresponding quick fixes:

• Something important is falling between the cracks in an organization. The quick fix is to create a new role or position that has the responsibility for exactly the thing that is being neglected. Perhaps a new coordinator (whatever that means) or even a new manager or vice president.
• A production stop is caused by a poor quality component. The quick fix is to appoint an ad-hoc task force for trouble-shooting.

Some cures, like the ones above, turn out to be worse than the illness. The new role in the first case above might end up having responsibilities that are already partially allocated to some other role resulting in confusion. The new role may also conceal the real problem: that somebody is not doing his or her job.

The task force in the second example may take on the responsibilities that would otherwise belong to the product support organization that for the moment is understaffed. If the product support organization isn’t exposed to the issue it will not be able to take corrective action to prevent similar problems in the future. Also the resource shortage may not be exposed as one of the root causes.

There are no ski-lifts up to Mt Complexity.

Many methods such as Toyota Production System’s A3 [1] stress the need for a thorough root cause analysis when solving problems like this. But fixing the organization or the work processes on a more fundamental level, taking into account all process interfaces and the responsibilities of all roles may turn out to be quite complex. The simple reason is that reality can sometimes be dauntingly complex; a space ship requires rocket science – less will not get it off the ground.

These are the phases I often see in the problem solving process:

1. “How hard can it be?”: The symptoms of the problem are in front of us. We start trying to make sense of it. It all looks simple because we haven’t started to scratch beneath the surface.
2. “Are we making this too complicated?”: Fatigue and impatience is setting in as more and more factors and dependencies are revealed. If we stop here and don’t get the complexity on the table and understand it, then the solution may well be simple but it is also likely to be wrong. Simple solutions are desirable but simple and good solutions can only be created once the complexity is understood.
3. “Over the complexity maximum”: If we have made it past the previous step then we are starting to get all the bits and pieces on the table. Our mental model of the problem is still complex but we begin to see patterns and connections. We see that that part over there is really the same as this part over here, that existing role already has almost the responsibilities that we at first were tempted to assign to a new role. And so on. We can start simplifying our solution from a position of understanding.
4. “The simple and good solution”: Having done all the simplifications in the mental model, we are ready to design the simplest possible solutions. But not simpler.

In a complex world, a simple and elegant solution can only emerge once the messy and initially inelegant complexity has been understood. One has to have the stamina and determination to climb Mt Complexity. Drilling a tunnel through the mountain might get you into the Valley of Despair.

References

[1] The Toyota Way. Jeffrey K. Liker.

Note

I’m indebted for the term complexity maximum to Anna, with whom I worked at a client more that ten years ago. She had many other interesting ideas too including the habit to take a new seat at the table after every break during a long meeting. She claimed it would keep us all flexible and ready for fresh thinking. She might have had a point although I must confess I found it quite annoying.

Every so often organizations that aren’t happy with their operational performance embark on a process improvement program of the “one-size-fits-all” variety, decide to implement the latest hyped-up development process, or purchase the latest model-based development tool without investigating what their prioritized improvement needs really are. One company that I was helping had for instance planned to ramp up their verification and validation activities as part of a general “quality improvement” effort. When we started talking about their quality and other priorities, we found that both customers and other stakeholders were very happy with the quality of the products but not with the responsiveness to new customer requests. Clearly, in this case, more verification and validation was not what they needed the most.

A simple process for finding improvement opportunities.

A good starting point when looking for the most important improvement opportunities is the organization’s set of business goals as stated in a business plan or similar. (When no business plan exists, key people within the company can usually write a good enough business plan in about one hour.) Information that I want to find in a business plan include:

• What customer segments do we want to target?
• What value do we deliver to the customers?
• What value do we deliver to the customers’ customers?
• With what products and major product features so we deliver that value?
• What are our tactics to lock out the competitors and lock in the customers?
• What are our unique selling points? Why buy from us instead of a competitor?
• Do we have other stakeholders with specific requirements or needs, e.g. authorities or employees?

From this information we can start reasoning about the results that our customers and other stakeholders expect from us and that will make us stand out relative to our competitors; what we need to be really good at producing. Particularly important results are those that support our unique selling points, the product features and our interactions with the customer that make our company different (and hopefully better).

Typical product features that might give us a competitive advantage include aesthetics, availability, ease of buying, functionality, performance, conformance (to standards and regulations) and price. In our interactions with our customers we could excel in e.g. responsiveness, innovativeness, security, accessibility, reliability, competence, credibility, and empathy.

A good example of the ease of buying product feature is Amazon’s one click shopping feature. It eliminates all time-consuming typing and makes it (almost too) easy to buy yet another book or widget. The same company’s success is very much tied to the security of the interactions over the web.

In parallel to identifying customer-oriented results that are important to our success, it is often useful to look at the same issue from an other angle by identifying risks for not reaching the business goals. As a complement to finding out what we need to do right, we here brain-storm what can go wrong. There are various more or less standardized risk analysis methods for finding risks. I will return to these in later posts.

Some capabilities.

Having the desired results and identified risks, we can start to identify what capabilities we need to produce the results and to mitigate the risks. It is also useful to think about what you can do less of (like in the example in the first paragraph of this post).

If for instance aesthetics is a unique selling point, or at least an important product feature, then we probably need to hire a designer or buy a corresponding service that will accomplish exactly that. We may also perhaps add a “look and feel” review in the development process or even a focus group. If conformance to regulatory requirements is crucial or even mandatory, then we need to know those requirements and build them into our work processes.

A number of general capability categories are illustrated in the exhibit to the right. (“Product baseline” refers to the previous version of your product. When developing a new version of a product, the starting point is obviously a very important success factor).

There is no rocket science here of course. But it does pay off to from time to time do the analysis according to the above steps in a structured way. If you are lucky, you may even find that you can actually do less to achieve more.

The exact string “high quality consulting services” renders over 100 000 hits on Google (without the quotes you get over 30 million). Having been in this business for some time, I always get a bit annoyed by such phrases. My platitude indicators are flashing red. What is meant by “high” I wonder. And by “quality” for that matter. And why is nobody ever offering “medium quality” or “low quality” services or products?

The word “quality” comes from the latin ”qualitas” which means “from what”. One common definition of the word is “The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.” (ISO 8402:1986). “Features” and “characteristics” are according to Dictionary.com synonyms so just “features” would probably suffice. But “stated and implied needs” is rather good. It says that we should not only address the explicitly stated needs but also those that we need to read between the lines or guess. “Bear on”, again according to Dictionary.com means to affect, relate to, or have connection with; be relevant to. Quality is therefore according to this definition the total amount of product or service features that are relevant to its ability to satisfy (customer) needs.

Quality according to Kano

Peter Drucker says “Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for.” This definition shifts the perspective from the product or service to the customer. The Japanese professor Noriaki Kano refines this by suggesting that not all features are equal when it comes to creating customer satisfaction.

Necessary features are those without which the product would be totally worthless. An example of a necessary feature of a car is propulsion. The graph to the right illustrates that you can never win a customer with only necessary features since all the competing products have them too. You can at best get a customer that is indifferent to your product or service.

Expected features are those that the customer typically puts on his or her shopping list. For a car that could be a navigator or a collision avoidance system. Yesterday’s expected features tend to become today’s necessary features. With enough expected features customers may prefer your product or service instead of that of your competitor.

Attractive features are features that makes the customer say “wow” in Tom Peters’ terminology. They are per definition unexpected. As illustrated in the graph, attractive features add substantially to customer satisfaction. It is hard to come up with examples of attractive features as they cease to be attractive as soon as the customer has got used to them. I said “wow” when I installed Ubuntu 9.04 on my laptop and the 3G dongle worked out of the box without configurations or installations. (With version 9.10 there was a regression of this functionality that made me rather annoyed. Attractive features soon become necessary features and may then backfire.) Still, attractive features are a very efficient way to increase customer satisfaction (when they work).

That all makes sense but we’re not done yet. In the book Zen and the Art of Motorcycle Maintenance the main character Phaedrus came up with the following definition of quality: “Quality is the response of an organism to its environment”. (Then he went mad.) Inspired by this rather philosophical definition I believe we can refine the definitions of Kano, Drucker and others to the following:

“Quality is what makes our customers do something positive for us, in response to our products and services.”

This means that quality is whatever makes the customer recommend our products for his or her peers and come back and buy some more. Quality doesn’t need to be in the product itself. It can be in the “One-click shopping” of Amazon.com that makes it (too) easy to buy books. It may emerge when we see to it that one of our customers writes a paper involving our products and presents it at a conference. Or it may be a friendly voice on the telephone.

This may not be the ultimate definition but I have the audacity to believe it’s better than most of the alternatives.

Links and references

[1] Robert M Pirzig, Zen and the Art of Motorcycle Maintenance

[2] Tutorials on the Kano model

[3] Alternative definitions of quality