TOC states that at any time there is only one limiting constraint in a system that restricts throughput. By identifying and improving that constraint the throughput of the entire system can be increased. If the constraint is eliminated altogether then some other part of the system becomes the new constraint or bottleneck.

In a project, the critical path is the constraint. This limits our capacity to deliver the project any faster. But just identifying the critical path is not enough. We need a tool to manage it. TOC provides us this tool, which is called Critical Chain.

Delivering Projects the Hard Way

Traditionally projects almost always run over time because we currently plan for them to do so. Not consciously of course, and certainly not on purpose, but we don't manage them to be early or even on time. We don't allow for human nature, such as the student syndrome of not starting things until the very last minute when they are due, or the way in which tasks tend to fill up all of the available time allotted to them.

When tasks finish late the flow on effects delay the project. But when tasks finish early, do we really get any benefit? Usually the next task isn't scheduled to start right away and in fact doesn't start until the project plan tells it to. The necessary resources may not be ready because they weren't planned to be ready until the project schedule told them to.

So, the project gets all of the delays from tasks finishing late but receives none of the gains when tasks finish early! We just don't plan for that to happen! It seems WE, as project managers, are the biggest impediment to finishing early.

So Much Safety, So Little Time

To get the benefit of Critical Chain, we must understand how project schedules are determined in the first place.

To digress just a little, the following is taken from Goldratt's book entitled Critical Chain (Eliyahu M. Goldratt is considered the father of TOC and has published many books which are highly recommended reading, starting with The Goal). The following graph shows a typical Gaussian or normal distribution, in this case for the probability of a marksman hitting a target. The probability of the marksman missing the target altogether is very low. The probability of hitting the bullseye is not 100% but it is higher than the probability of hitting any other point on the target.

Goldratt then gives the example of the probability of you driving home tonight. In that case the distribution would look more like the following.

You have zero chance of getting home in less than a minimum amount of time. The chances of all kinds of delays creeping in are significant. And if you stop off on the way to go shopping you could take many hours to get home! So the probability distribution is no longer "normal" but is elongated in time. If you were asked how long it will take you to get home tonight for dinner, what would your answer be? Would you promise a time you had 50% chance of hitting and risk your dinner going cold, or promise a time you were sure you had 80% or 90% of hitting.

If you think about it, isn't this the way we estimate individual task durations in a project? A typical schedule is full of safety margins throughout because when we come up with esimates for individual task durations we factor in all kinds of safety.

We don't promise a date we have 50% chance of hitting. We promise a date we are sure we have 80% or 90% chance of hitting and in our minds we allow for all kinds of "what if" distractions and delays that could occur. From the graph above we can see that if we use an 80% chance of completing the task then the duration can be twice as much as the duration at 50%.

On top of the individual safety inherent in every task, the project manager usually adds other safety margins hidden throughout the project. We try to add more than enough to compensate for all kinds of uncertainty. Of course there is the usual slashing executive management does before the project is approved (they must know or at least suspect there is all that embedded safety - probably they scheduled their own projects before they got to be executive managers)!

Despite all of this inherent safety buffer time, we are still consistently late! There is very often pressure for the timeline to be extended or worse, for scope to be jettisoned, in order to finish in a reasonable time without upsetting the client.

We need to change something, but what? How can we access this intrinsic safety buffer and actually use it to our benefit? How can we measure project performance to know, for sure, that the project is slipping as soon as it starts to happen, not weeks or months later. We need to change something in the way we manage projects. We need to ask ourselves:

1. What to change?

2. What to change to?

3. How to cause the change?

Project Focus

Organisations perform work to achieve a set of objectives. Generally, work can be categorised as either projects or operations, although the two sometimes overlap. They share many of the following characteristics:

• Performed by people

• Constraining by limited resources

• Planned, executed and controlled

In operations people are often focussed on key business performance measurements, such as sales, profit, amounts of product/service sold, etc. In projects, people are often focussed on time and then cost. The focus on time is usually embodied by the developing and maintaining of a project schedule to map out all of the tasks required to complete the project.

How then to go about managing the project activities to deliver the end result in the time alotted by the schedule. What tools are at the disposal of the Project Manager to ensure the goal is achieved. 

Project Management

Project management is the application of knowledge, skills, tools, and techniques to a broad range of activities in order to meet the requirements of a particular project.

Project management is accomplished through the application and integration of five processes:

1. Initiating

2. Planning

3. Executing

4. Controlling

5. Closing

The project manager is the person responsible for accomplishing the project objectives. Managing a project includes:

• Identifying requirements

• Establishing clear and achievable objectives

• Balancing the competing demands of quality, scope, time and cost

• Adapting the specifications, plans and approach to the different concerns and expectations of the various stakeholders.

Project management is also comprised of nine knowledge areas. These nine areas focus on management expertise in

1. Project Integration

2. Project Scope

3. Project Time

4. Project Cost

5. Project Quality

6. Project Human Resources

7. Project Communications

8. Project Risk Management

9. Project Procurement 

Delivering Projects using the Theory of Constraints

Traditional project management methodologies are based on the above definitions and often try to segment project management activities and optimise each one. TOC, however, proves that the local optima approach does not benefit the system as a whole, and yet our entire management practices are based on local optimsation and cost accounting principles! To implement TOC for Project Management we use Goldratt's five focusing steps which are at the heart of all TOC initiatives:

1. Identify the system’s constraints.

2. Decide how to Exploit the system’s constraints.

3. Subordinate everything else to the above decision.

4. Elevate the system’s constraints.

5. If in the previous steps a constraint has been broken, Go back to step 1, but do not allow inertia to cause a system constraint. 

In a project environment, where the constraint is the critical path, we need a method to exploit it and subordinate everything else to the critical path. We may also have other capacity constrained resources elsewhere in our business whose time must be carefully managed so as to avoid task contention and not impact the critical path of each project. What happens when we have a resource contention on the critical path? That will surely cause a delay. Clearly we have to think a little beyond just the critical path and that is exactly where TOC helps us with the concept of Critical Chain.

Critical Chain

We will provide here a summary overview of the essential basic elements of Critical Chain Project Management. For an exhaustive explanation you will be hard pressed to find a better resource than Kelvyn Youngman's website. Mr. Youngman provides it free online, and only asks you respect his copyright and not permanently copy it nor print it. Given the calibre of the information he provides us all for free, a very reasonable request indeed.

Is there really much difference in the processes and knowledge required to execute projects or run operational systems? Just like a project, a process has a beginning and an end. Even though individual projects come to an end, project organisations exist to execute their project execution processes over and over on different projects, usually with many occurring at any one time. This is akin to any production process.

As Kelvyn Youngman so eloquently points out, the main difference between projects and operational processes is in the task execution time, or "touch" time. In manufacturing processes, for instance, raw materials spend most of their time waiting in queues. The actual process touch time is nearly always very small in comparison. Whilst there is uncertainty in how much time materials will spend waiting, the process tasks themselves are generally quite certain in their outcome, thanks to quality assurance and quality control.

In contrast, project task touch time can be very large indeed. This is then combined with a level of uncertainty that goes with each task plus the intrinsic safety we add when estimating task times to counteract this uncertainty. This embedded safety gets "lost" in the project estimate as it cannot be identified separately to the estimated task duration.

So, whlist they are in some ways fundamentally the same as other industrial processes, projects also have these important differences. It is these attributes that guided TOC to the solution of Crtical Chain, historically based on the manufacturing Drum-Buffer-Rope concepts but identifying and managing these important differences.

What we need to be able to do is to access this intrinsic safety local to each task. An important aspect of Critical Chain is to modify the arrangement of this safety which is local and everywhere to just a few safety buffers strategically placed in accordance with the five focusing steps of TOC, thus allowing us to exploit and elevate the project constraint (the critical path) and subordinate everything else in the project to this.

Another important aspect of Critical Chain is treating the project not as a schedule, but as a sequence. Similar to the way TOC moves from an MRP schedule to a Drum-Buffer-Rope sequence, the only things we schedule are the start and finish. We don't assume that steps must be done one after the other but rather we expect that sometime between the first step and the last step the other steps will be completed in sequence. We may not know exactly when each step will occur and in fact it doesn't matter, providing all steps finish witin the total time allowed.

Let's explain with some simple diagrams. The first one shows a simple project schedule:

As we learned earlier, a significant amount of task duration time is embedded safety. Let's split that out more explicity. Experience with Critical Chain has shown that, as a rule of thumb, the amount of safety is in fact half the estimated duration time. This stems from our previous analysis where the 80% probable completion time is at least twice the 50% completion time.

Now lets aggregate the safety time, rather than having it distributed around the project. By aggregating it we make it available to the whole process.

Now we can also bunch up some tasks rather than have a whole lot of wait time with nothing happening. In that case we move all of the safety time to the end of the project, as shown below.

It is important to note that we haven't made the project any shorter at this point, only put all of the intrinsic safety lumped together as an explict buffer available to the entire project. If anything we've actually made the project longer in the last diagram above.

In Critical Chain we call the safety time buffer on the critical path the Completion Buffer and buffers on feeding paths are called, naturally enought, Feeding Buffers. Because the previously localised and embedded safety has now been made explicit it will be utilised much more effectively and hence we need less of it. The Critical Chain rule is that only half as much safety buffer is required which leaves us with a buffer size equal to half of the reduced task estimate. This is always the case in Critical Chain.

So, we have saved a quarter of the original estimated project duration thanks to the aggregation and placement of the safety buffer time. Tasks that finish late can be offset by tasks that finish early. Remember, we no longer have a schedule but rather a sequence. We don't expect each task to occur in the duration specified nor necessarily start as soon as the previous task is complete. We can expect the normal range of project variation but this can now be absorbed by the global buffers. Now there is a definite focal point of the project working through the critical path as soon as work is available to be performed, not when it was scheduled to be started as in the traditional PERT or Gantt chart method. The aggregated safety buffer provides us a tangible measure to take from and add to as tasks are finished. Before we had no leverage point in the project to monitor or control our situation. What's more, we now plan to complete the project in only 75% of the time!

Critical Chain is more than the critical path. The critical path is the longest path of dependent tasks through the project that sets the minimum project duration. The Critical Chain, on the other hand, goes one step further by considering resource requirements and is the longest chain of dependent resourced tasks in the project. Because of this consideration of resourcing, the critical chain can span multiple paths. The critical chain method is more realistic because it takes into account that resources are finite whereas critical path does not.

Critical Chain Measurement

By measuring how we use up the global buffers, we now have an excellent indicator of project performance. We do expect to use up some buffer time. This is normal given the variability and uncertainty in the tasks that have to be performed. The measure of buffer consumption is called Buffer Status, and is calculated as a percentage in terms of:

Buffer Status = Buffer Penetration /  Buffer Duration

where

Buffer Penetration = Sum Task Estimates - Days Elapsed - Active Task - Remaining Tasks

We could produce a graph of buffer status for a project which will indicate how we are doing relative to the end date of a feeding chain or the critical chain which would look something like this:

The straight dotted line represents Project Status.

Project Status = Elapsed Duration / Total Project Duration

As long as the Buffer Status is less that the Project Status we are ahead of schedule. But don't forget the schedule is 75% the duration of the original estimate!

Requirements Management

Analysing customer requirements is one of the most challenging parts of any new initiative or project. This is especially the case when:

• The product or service required is complex.
• The product or service is to be delivered over an extended period of time or geographically diverse area.
• The customer organisation is large and there are many internal "customers" and stakeholders.
• The customer doesn't know what they want.
• Requirements change depending upon what's available.

The requirements defiinition (e.g. User Requirements Specification) reflects the knowledge of the authors at one point in time, usually the beginning of the project. But as most projects take some time and involve the gaining of a lot of knowledge, It stands to reason that clearer or more requirements will be developed as knowledge is gained over time throughout the project phases. It is therefore quite reasonable to expect the original requirements specification to change. In fact it would be extremely unlikely and surprising if it didn't. Why then do so many projects struggle with the concept of changing requirements?

A mechanism needs to be in place to manage this change and ensure that only approved changes are added to the list of user requirements. But this also opens up another aspect related to requirements management which is scope management. This must be addressed very rigorously to protect the bottom line of the service or product provider in the relationship.

It stands to reason, also, that some requirements are more important to the client than others. These should be separated out as they are more negotiable as the project progresses. Typically requirements can be separated into three classiifcations:

1. User Requirements. In this context the "user" is the "business", not an individual. Regardless of how a project is implemented the User Requirements must be delivered and are not negotiable. They might include what products or services are going to be supplied by the customer and in what capacity and to what quality standard. These requirements are dictated by the business and market the customer is in. Project delivery suppliers can not impact on them in any way.
2. Functional Requirements. These are the next level down requirements of what the client wants it's systems to do. They might be dictated by precedence or by the knowledge of the client's team on what is wanted. Still, if a supplier can demonstrate a better way that is cheaper and quicker, the client is highly likely to change.
3. Design Requirements. These are the lowest level requirements and the most negotiable. These stipulate how to deliver the functional requirements above. These are easily changed during design when superior alternatives can be articulated.

By separating out the types of requirements it becomes easier to focus on what is important and challenge what is not. 

Requirements Traceability

Additionally, it is important that requirements remain traceable throughout the project to ensure all requirements are implemented and verified. A unique numbering system should be applied to each requirement for this purpose, but beware of word processor field numbering systems as they can automatically re-number requirements beyond the user's control. It is better to have a user assigned number that will not change to ensure external references to requirements do not get broken.