Two Reasons Why Improvement Efforts Yield Little

Often, companies begin improvement programmes with plenty of noise and fanfare, with promises of performance leaps designed to take them "to the next level". Almost ojust as often, these lofty dreams fail to materialise. There are two main reasons for this: failure to focus and failure to subordinate.

In a number of previous articles we have likened organisations to chains with several links representing the resources. The strength of the chain is determined by ....

Even without seeing the end of that last sentence, I am certain you knew the next words should have been "the strength of its weakest link". In most organisations, no identification of this "weakest link" - the resource that currently constrains the ability of the business to generate throughput. How do such organisations decide what needs improving?

In many cases, companies decide that everything and everywhere needs improving. The resources available for the improvement effort are thus spread thin across all the areas. This is link trying to strengthen the chain by strengthening ALL its links. How much of the effort is useful to the goal of making the chain stronger? Only that which makes the weakest link stronger! Everything else is wasted, as far as the goal of impacting organisational results is concerned.

In this scenario, results from the improvement programme, where they exist at all, are very slow in coming and of far less magnitude than could be the case, given the effort expended. Disillusion sets i, momentum slows and everything grinds to a halt. Until another attempt, applying a slightly different set of tools is made - with similar outcomes. It is no wonder that every new effort meets an increasingly cynical workforce.

Thus we must keep in mind Goldratt's first two rules for properly managing and improving operations, namely:

1. Identify the constraint

2. Exploit the constraint

Next to identifying and exploiting operational constraints, the next most important rule is to subordinate the rest of the organisation to the needs of the constraint. This means that everything else is managed to enable the constrainted resource operate as close to full capacity as possible, while ensuring it works only on the right things.

Managing operations with these rules leads to a situation where all effort is directed at the weakest link. This means that every effort counts. Results are thus quick and significant.

A Better Way to Manage Projects: Guaranteed Scope, Due Date and Budget Performance

Our last article explained the reasons for the prevalence of completion delays in the vast majority of projects.

To recap, we looked at the padded time estimates, Student's Syndrome, Parkinson's Law, Integration requirements and Multitasking all interacting with the heightened uncertainty (Murphy's Law) found project environments to more or less "guarantee" that projects will be late.

Local Versus Global Optimatisation
To explore an alternative project management approach, we must understand why time estimates are padded. It is to ensure that a project TASK is completed on time by protecting it against the impact of uncertainty. As we saw before, the combined effects of Student's Syndrome and Parkinson's Law then strip off the protection, exposing the project to delays.

What is our aim? Is it to finish a particular task on time or to complete the whole project on time? Of course it is to complete the whole project on time. If we aim to complete the project on time, we must relocate the protection (time paddings) from each task to the whole project. How do we do this?

Anyone with sufficient familiarity with project management knows that the determinants of the duration of a project are tasks on the so-called critical path. The critical path is defined as the path with the longest sequence of dependent tasks. To protect the whole project then, we must ensure we protect the critical path. This is done by stripping off the time pads on individual tasks so the time estimate for each task is reduced to half its original value. Half the stripped off protection is then added at the end of the critical path. Thus the new total estimate is at most 75% of the original. Why does this work?

Because individual tasks no longer have any slack, their performer is cured of Student's Syndrome because it is all he can do to complete it in the new allotted time. On the average because of uncertainty, half the tasks will finish late. Because of the complete absence of slack, the degree of lateness per task will be small. Some tasks will also finish slightly early. In this case the next person waiting to work on the subsequent task ensures that Parkinson's Law does not come into play.

Whatever delays remain (significantly less now because Student's Syndrome and Parkinson's Law have been eliminated) are absorbed by the accumulated protection at the end of the critical path. This protection is known as the project buffer. It is not under the control of individual project team members and so cannot be frittered away.

Critical Path or Critical Chain?
The critical path is defined in project management lexicon as the longest sequence of dependent tasks. In practice however, only structural dependence is explicitly accounted for. Structural dependence between tasks is dependence arising from the nature of the tasks themselves. For example in constructing a building, the foundation must be laid before pillars and beams are cast. Another source of dependence exists. This is resource dependence. This describes the fact that one project worker may need to perform tasks on more than one path in the project. While nothing in the nature of the tasks requires that they cannot be done in parallel, the fact that they are to be performed by the same individual implies it. Failure to explicitly consider resource dependence is responsible for the oft observed phenomenon where the critical path appears to jump from one path to another.

Because of resource dependence, tasks that determine the duration of the project may not necessarily lie on the same path. The name, critical chain was coined to reflect this reality.

Feeding Buffers
What about the non-critical paths? While they may not determine the duration of the whole project, their outcomes often need to be integrated with tasks on the critical chain. Thus delays in these non-critical paths will ultimately lead to the whole project being delayed. To prevent this from happening, each non-critical path that feeds the critical chain is protected in the same manner as described above for the critical chain: time estimates stripped to half their original estimate, with a 50% slack added at the end of the path.

Monitoring Project Progress
Project progress is monitored by assessing the percentage of tasks completed on the critical chain. As an additional measure of the amount of protection remaining, the percentage of buffer time consumed is compared with the percentage of critical tasks completed. Thus is 40% of tasks on the critical chain have been completed, while 55% of the buffer time has been consumed, the project is in danger of being late (no matter how far off the expected completion date).

These measures provide early signals to take extra measure to bring the project back on track.

Track Record (Data Obtained from Wikipedia)
Research shows that typically, projects are completed in 222% of their original planned durations at 189% of budgeted costs. In 70% of the cases, the scope is compromised. 30% are cancelled.

On the other hand, for projects that apply the ideas outlined here - collectively known as Critical Chain Project Management, 95% are delivered on time and within budget. Organisations implementing the method as their way of managing projects experience on average 69% percent reduction in lead time, 60% improvement in due date performance and 68% improvement in revenue.

Why 90% Of All Projects Finish Late

Activities classed under the term "project" are so diverse that it is sometimes difficult to appreciate commonalities among them. For example, social activities like the organisation of parties, picnics or weddings are projects. Construction work like building a bridge, developing a housing estate, power plant construction, expansion of a fibre optic network also constitute projects. So do producing a movie, developing software, launching a marketing campaign for a new product, implementing an ERP system or the relocation of a family from one city to another.

For each of the examples mentioned above, the following hold true:

The objective is a unique, non-routine outcome.

The effort required to achieve the outcomes desired is temporary. That is to say projects have a start and finish date. This is in contrast to operations which are ongoing.

The non-routine nature of projects accentuates the impact of uncertainty.

In spite of the many unknowns, executors of the project must make three commitments at the outset. These are commitments as to content or scope, commitments as to delivery date and commitments as to cost.

In spite of these commitments, the existence of a rich and detailed body of knowledge on how to manage projects, and the availability of purpose-built project management software tools, almost no projects are delivered on time. Unless there are major trade-offs in content and/or cost. Why is this the case?

Enter the human factor.

Project Time Estimates

The uncertainties involved in projects mean that time estimates used for planning are just that, estimates. What does estimate mean? It means that the time given for each project task is an average number. But wait a minute. Using truly "average" figures for time estimates would mean that chances are fifty-fifty that the task will be completed early or late. No one will give an estimate that has a fifty percent chance of failing.

So what actually happens is that the estimates are padded to account for uncertainty. The level of padding depends on how badly the estimator has been burned in the past when he/she provided inadequate "cover".

In addition for padding provided by each task performer, there is also an overall padding by their boss. For example if three resource persons working on various tasks in a project estimate 5 days, 7 days, and 3 days as their respective task completion times, will their manager report an estimated completion time of 15 days to his own boss? Highly unlikely. He most probably will offer 20 days and only very reluctantly allow it to be negotiated down to 18 days minimum.

If as described above, project times are already padded from the start (through padding of each task and further padding at each level) how come most projects still end up finishing late?

There are two psychological mechanisms at work that thwart individual attempts to protect the project against uncertainty and cause all the safety provided to be wasted.

Student's Syndrome

At the conclusion of a lecture, a professor informs students that they will be taking a test on the material taught in one week from today. What is the typical reaction of students? They will protest that they are not ready, that the time is too short... If the professor relents and gives an extra two weeks for preparation, do students immediately begin to study for the test? They do not, if they are typical students - until the night before exam.

In projects, having padded the time estimates, resource persons will typically delay (probably busy working on things unrelated to the project) to the latest possible moment before commencing work on the project task. And while they're working Murphy strikes. Since the extra time was already consumed by Student's Syndrome, the task is finished late. The next dependent task is forced to start late.

Parkinson's Law

Parkinson's law states that work expands to fill the time available for it. What is the implication for completion times of project tasks? Assume that a particular task estimated to take 7 days actually is completed in four days, does the performer deliver it to the next resource person? Not likely.

Because the time estimates given are negotiated numbers, reporting an early finish of a task means that future estimate given by the project worker will be trimmed by the manager. To avoid this possibility, rather than report early task completion, the worker is likely to spend the extra time performing checks and adding nice to have "bells and whistles" not strictly required by the specifications.

Result? Extra time gained is wasted.

Integration Requirements

In most projects, the final stage is an integration of the outputs of several previous paths. Assume in a particular project that the final stage is the integration of the results five paths. Assume again that the time estimates for each of these five paths is such that there is an 80% chance of on time completion, what is the change that integration will commence on time?

For the integration to commence on time, all the five paths must be complete. The chance that one path is completed on time is 80%. The chance that two paths are finished on time is 80% X 80% which is 64%. The chance that four paths are finished in time for integration is 64% X 64% or about 40%. The probability of all five paths being finished in time for integration to commence is about 33%! More likely than not, integration will commence late.

Multi-Project Environments

A further killer of time in multi-project environments (software development companies, construction companies, engineering departments) where more than one project is going on simultaneously and resources have to be shared between the resources, is multitasking.

The resulting lack of focus, combined with constant "set up" requirements leads to late delivery of all the projects being worked on.

Conclusion

We have shown that original project time estimates are padded to protect against uncertainty. However, a combination of Student's Syndrome and Parkinson's Law lead to a frittering away of the enormous safeties embedded in the estimates.

In addition the need for integration in most projects, and the incidence of "bad" multitasking in multi project environments lead to added delays, virtually guarantee that projects are delivered late.

What is the way out? A different way to manage projects is needed.

How to Identify the Core Problem

Whenever we are in a situation that we believe should be improved, the first relevant question is, "What do we need to change?" The choice of the word 'need' rather than 'want' is deliberate, because the latter will direct us to the most obvious undesirable aspects of the situation - namely the many problems that manifest.

As our last article showed however, there are two drawbacks with a direct attack on the obvious problems. The first is that they are too many and may require more resources (even if this is just management time) than we might be able to deploy. The second is that the obvious problems are merely symptoms of deeper underlying causes.

It is the underlying cause - the core problem - that we need to change, if we must impact the system as a whole.

The first step is to get a list of Undesirable Effects. Undesirable Effects or UDEs are conditions that in themselves are negative from the point of view of the business as a whole or from the perspective of individual members or units. They are the things people complain about or that reflect or create poor performance. For example a UDE might be that revenues are declining, scrap increasing, customer complaints or lead time going up. For an individual in the organisation, we might have loss of commission, poor relations with peers or loss of prestige as UDEs.

The list should be broad enough to capture all stakeholders.

The next step is to select the most pressing UDEs (five to ten) from this list and write them on movable cards or post-it notes using present tense wording. These are then inspected to determine if a cause effect relationship exists between any of the UDEs. Proposed causes are arranged below their corresponding effects. Cause and effect statements are connected using arrows.

Next we look at the cause statements and examine the broader initial list of UDEs to determine further cause effect.

All proposed cause-effect relationships must be verified by a set of logical tests - eight in all - known as the categories of legitimate reservations. These are Clarity, Existence, Causality, Cause Sufficiency, Additional Cause, Predicted Effects and Cause-Effect Reversal and Tautology.

Clarity: This determines that the UDE or other statement is clearly stated and reflects the meaning intended by the complainant.

Existence: A statement may be clear fail the existence test. This test examine whether the statement of the UDE is valid. To be valid it must have meaning in the experience of those to whom it is addressed.

"The cow jumped over the moon", a statement from a nursery rhyme, has no existence in most people's reality.

Causality: This test examines if a cause-effect relationship actually exists. That is we must be able to say that if the cause exists then the effect must exist.

Cause Sufficiency: This examines whether the cause(s) adduced are enough in themselves to create the observed effect. Otherwise, more causes must be found, which in combination with the already proposed ones, lead unavoidably to the observed effect.

For instance, saying that a spark led to a fire proposes an insufficient cause. Two other causes required in combination with the spark are the existence of combustible material and oxygen.

Additional Cause: This examines whether the effect could have resulted from a different independent cause of set of causes. The test here is to ask: If I eliminate the stated cause, is there any other circumstance under which I would observe the effect? If yes, then there is an additional cause.

Example:
Observed effect: The lady's temperature is slightly elevated
Proposed cause: She has an infection
Additional cause: She is pregnant

Cause-Effect Reversal: This test unravels the confusion between the cause and its evidence.

Predicted Effect: If the proposed cause-effect relationship exists, what other effects can we expect from the same cause? This is sometimes known as effect-cause-effect thinking. We observe an effect, for which we propose a cause. We then test our assumption by looking for other known effects of the cause.

Tautology: This refers to circular logic which offers the effect as the rationale for the cause.

Example:
Statement: The Super Eagles lost against Ghana because they played poorly.
Challenge: How do you know they played poorly?
Rationale: Because they lost the game!

Using these logical tests we are able to create a rigorous cause-effect diagram reflecting the current reality of the system or organisation under consideration. As we go deeper into the causes, we find fewer and fewer causes. When we reach a cause from which we can trace a significant majority of the UDEs, we have found our core problem. We have found what we need to change.