Archive for the 'Theory of Constraints' Category

I won't bore you with all the references to how multi-tasking produces waste. But do understand, the company policy to have very high utilization of staff creates the requirement for multi-tasking. Full utilization is not sustainable. Until you can lower utilization, thereby creating slack, you won't be learning and innovating. You can't be lean.

Clarke Ching, writing for Sticky Minds, uses a simple exercise to show just how evil multi-tasking is. Do the exercise for yourself and then have your boss do it. It goes like this:

Read the rest of this entry ¶

Over the years I've written quite a bit about constraints. In the process environment there are physical constraints which are easy to spot. You'll see work piling up in front of the constraint. Projects are always constrained. We think that the big constraint is time. The project promise date (deadline) provides a limitation on how much can be accomplished. Most of us are familiar with physical constraints. Getting more done is limited in some way by how much capacity one can bring to the situation. It can appear that physical constraints are the only constraints. In other postings I've written about policy constraints and paradigm constraints. Perhaps I'll revisit them. Until last Friday, I hadn't considered that there was another class of constraints. Jim Dallas changed my mind. Read the rest of this entry ¶

David J. Anderson, author of Agile Management and the weblog of the same name posted a series of Lessons Learned from Eli (Goldratt):

• #1 Small Batch Sizes
• #2 Resistance to Change
• #3 Don't Assign Blame
• #4 Lean and Six Sigma

Have a look. David is a solid writer and avid learner. He doesn't just stop at the lesson he learned. David offers a refreshing perspective. If you like what you read, then join his Agile Management Yahoo! discussion group. You won't be disappointed.

This posting came from Clarke Ching, Scotland, writing in the TOC Experts Yahoo! Group on November 10. Clarke is a regular reader of this blog and the contributor of Project e-Tip 009: Eliminate Multi-Tasking to Speed Project Completion. Clarke is a smart guy who writes well. He graciously allowed me to reprint his posting. Thanks Clarke.

[Look for my comments throughout the text.]

A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM). Here's Clarke's reply.

Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations - between 1 and 12 weeks each.

The core conflict for software development projects (and most others I imagine) looks like this.

[This is a fine example of Goldratt's Evaporating Cloud]

    D - Allow change throughout project
  B - Build functionality required by customer
A - Have a successful software project
  C - Deliver on time and to budget
    D'- Agree scope up-front and don't allow change throughout project

Or this see this graphic provided by Clarke.

[Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D') to agree to the scope up-front and not allow changes throughout the project. (D) and (D') are in conflict and cannot coexist.]

In a traditional/waterfall environment "change control" is the mechanism used to do both D and D' poorly.

The agile approaches attack three assumptions:

Assumption CE1

We can prevent change if we spend enough time to ensure we get everything agreed and signed off up front. Agile/lean says that CE1 is just plain wrong (in all but the simplest environments). Therefore, E doesn't even give you C. Even if we get the requirements right up front, they will change, so if we don't change them as we go then while C (finish on time and budget) is satisfied, we won't satisfy B (customer gets what they need) so that A (the project) isn't successful.

Assumption CE2

It is many times more expensive (i.e. Boehm's cost of change curve) to change the further we get into the project. Agile/lean says that CE2 is wrong too. For instance XP (eXtreme Programming), a cousin of Scrum, suggests that the cost of change curve quickly becomes flat when using test-driven development and refactoring in a iterative/incremental approach.

Assumption CE3

The project only delivers value when it is finished. Agile/Lean says that you don't have to deliver everything at once to get value. Instead you can get value quite quickly by delivering small high-priority increments of the product. At the very least you gain value by discovering what's not working much, earlier.

[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.]

The key points of Scrum are:

A product owner manages a product backlog.

This is a list of high-level requirements/features - e.g. user can register, user can login, user can add items to a shopping cart, user can search for books, etc - that has been prioritized by the product owner. It will also include "technical things" - e.g. install server, upgrade source management system - added to it if requested by the developers and agreed by the owner.

Every 30 days a new "sprint" starts.

Each sprint is a 30-day iteration where the development team picks a set of features from the product backlog that they estimate they can "deliver" within the next 30 calendar days. They then work on that sprint for the next 30 days.
During this time no changes can be made to the sprint unless suggested by the developers.

"Delivered" means that the feature could potentially, although not necessarily, be shipped or implemented.

It's fully coded and tested, the help is prepared, it's not going to break when the users get hold of it.

Each scrum team is self-managing with guidance from the "Scrum master".

Initially the team will struggle with self-management but, apparently, they learn quickly. Each day a 15 minute meeting is held where each person answers 3 questions - what did I do yesterday?, what will I do today? And what obstacles are holding me up? It is the Scrum master's job to clear the obstacles.

The theory behind scrum says that complex processes, such as software development, change too much and are too difficult to manage.

They need to be managed empirically, with constant inspection and adaptation.

[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.]

How does Scrum differ from Critical chain?

• CC aims to get the project finished as quickly and reliably as possible. Scrum aims to get working functionality delivered as quickly as possible.
• CC buffers with time. Scrum buffers with functionality.
• CC says "Don't put the safety in the task; put it in the project". Scrum says "Don't try and figure it all out up front because you can't. Things will change too much as you go. Instead, build working software quickly, inspect and adapt".

Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don�t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects.

[Good concise comparison.]

Write Clarke at clarke@chingz.com.

Don't yell at me. I'm just quoting Johanna. (But, I do agree with her!)

Johanna has this crazy idea of using inch-pebbles for tracking project performance. It's a play on the word milestone. She claims that percent complete gives a misleading view of a project. The calculation is either based on effort applied versus planned effort, or just a plain SWAG. As Johanna proposes a more useful way is to track the percent of tasks completed versus total tasks planned. You only take credit for finished work. The idea is to break the milestone or phase down into discrete (2-day) tasks that can be monitored.

Most of the time this must be done by milestone or project phase. Still you can't know the total tasks before the project finishes. The usual project is emergent. It unfolds. Additionally, there are ad hoc tasks that can be more critical to the project success than something planned at the beginning of the project or phase. Inch-pebbles alone won't provide confidence.

For over 10 years the members of the Lean Construction Institute have been using a similar measure of project success. It is known by the unfortunate name of project plan percent complete (PPC). It measures the success of completing promised tasks. Performers or workgroup leaders make the promises. Tasks are either completed as promised or they are not. You get 0% or 100% for each task. PPC is a measure of planning reliability. People who use the Last Planner System™ consider the PPC measure to be the key measure of overall planning system performance. Are you doing what you need to be doing and said that you can do? The key is the reliable completion and therefore release of work.

We still have to answer the real question:

Will this project finish as promised?

Since we've grown not to trust the answer to this question, we try to develop our own opinion by watching percent complete. But as Johanna explains, "After you've done 90% of the project, you have the other 90% to do."

This week's Project e-Tip was submitted by Clarke Ching, a reader in Scotland. Clarke reminds us of the perils of multi-tasking by sharing his story of book reading. Enjoy!

The Project Reformer's e-Tip of the Week

009: Eliminate Multi-Tasking to Speed Project Completion

I (Clarke) have a bad habit of trying to read 3,4,5 or more books at one time. My bedside currently has about 12 books, all of which are "in progress". It (unjustifiably, I think) annoys my wife immensely. If A-E represents the 5 books I am currently switching between, and I switch between each every so often then my reading looks like this: ABCDEABCDEABCDEABCDE … all finished                               a finished here                                 b finished here                                   c finished here                                     d finished here                                       e finished here Compare this where I read one at a time. AAAABBBBCCCCDDDDEEEE       a finished here               b finished here                       c finished here                               d finished here                                       e finished here While it appears that all five tasks finish at the same time. We know from our own reading that it takes awhile to get back into a book. We might have to back up to re-acquaint ourself. And maybe our retention falls off. Projects are just the same. Task completions often release work for another person, consequently multi-tasking significantly delays the release of work and the completion of the project. Submitted by Clarke Ching, Scotland shamelessly borrowing from Critical Chain.

©2003 Hal Macomber | RPM | e-Tip Archive | PDF | Submit Tip

Clarke selected a 1-year subscription to Business Book Summaries as his reward for submitting the Project e-Tip.

Final remarks on the series on Theory of Constraints

Frank, Joe, and I had fun blogging collaboratively on the Theory of Constraints this week. We hope you enjoyed it too. I want to underscore one point Frank made yesterday.

(M)y role in this series is to remind you that the reason we're doing the day-to-day work lies at the end of a string of days — at the end of probably more than one chain of tasks — and that while dealing with the current and immediate constraints, how we do so must take into consideration their import and impact on the larger constraints of the project as a whole.

We do projects to make good on a promise to a customer. The big promise at the end of it all. This is easy to see when a customer contracts for a new building. The customer is obvious, so are the conditions of satisfaction. But what about internal projects?

None of our advice on TOC matters when we act without a promise to a customer.

So often on internal projects someone has a good idea. S/he assembles a team. And they go to work. This doesn't mean it's a project. If you don't have a customer acting as the customer, then you don't have a promise, nor do you have a project. If you don't have explicit conditions of satisfaction for fulfilling the promise, then you don't have a promise, nor do you have a project.

We make all kinds of mischief (waste) in companies when we don't take care to be explicit about the customer and the conditions of satisfaction. So, as we leave the subject of the Theory of Constraints remember that none of what we discussed this week matters when we act without a promise to a customer.

Stop by and see what Frank Patrick and Joe Ely are up to.

Previous in series

Projects are always constrained. Accept it. Now what? (Day 5 in the TOC series.)

We've discussed three types of constraints, the focusing process for managing constraints, and the perils of multi-tasking in a world that work is not ready. Now what? Let's consider some practices we can employ on a day-to-day basis to operate successfully in the uncertain world of projects.

Manage the project in a way that keeps the constraints busy performing what should, can, and will be done.

• Planning is a practice that runs throughout the life of the project.
  Constraints will change. As the project unfolds plans can change to take advantage of what new is learned.
• Have an everyday focus on doing what you said you would do.
  Being reliable is the first step for improving project performance. It is also the step that allows you to anticipate demands on constrained resources. Reliability keeps the project flowing from one task to the next.
• Shield the constrained resources from variations in the release of work to them.
  The last thing you want to have is a constrained resource standing around. Have a queue of ready work (workable backlog) that the constrained resource can work down if a feeding activity fails to perform.
• Conduct the project anticipating you and the team will learn.
  The work breakdown structure used to plan a project to six levels of detail before the project has begun is not the way the project will be conducted. Keep re-planning. Do it with the people who are closest to the tasks. Adjust your plan considering the emerging talents and competencies of your team.
• Measure your planning reliability.
  How often are people able to finish what they said they would finish? When there is a failure understand why. Not to blame, but to identify the underlying source(s) of the failure. Take action to remove the underlying causes.

Particularly on large or remote projects you can't watch everything all the time. Status reports are rear-view mirrors. By keeping your eye on the constrained resources you will have your hands on the leverage point for your project. Manage the project in a way that keeps the constraints busy performing what should, can, and will be done.

Let's see what Frank and Joe have to say.

Previous in series Next in series

Multi-tasking can be eliminated (Ok, maybe significantly reduced). Day 4 in the TOC series.

We've been discussing constraints, resources in contention, and multi-tasking. Frank's posting yesterday showing the red, green, and blue tasks shows clearly that multi-tasking delays completion of some activities with no advantage to others. How could it be reasonable to follow a rule that resources in contention can only work on one thing at a time? Particularly in the world of projects where we often don't know what is needed from that resource 'til the last minute?

By queuing up ready work for people (resources) they can start work that will be finished.

The trick (technique) is to always have the work for a constrained resource in a condition to be started and finished PRIOR to the resource starting. Have you ever watched a person climb a ladder only to have to come down again to get materials or tools? Have you ever been asked to do something for someone and the person wasn't able to tell you what it meant when done is done? Joe offered this example yesterday:

The key? Making work ready for Loren to work on it. We have instituted standards for him to work on a request. No specs for the loading of a roof?? No truss analysis. Wow. That's a shock to the system of those who were used to calling and letting Loren work on unclear requests. But it is vital. If we have a true constraint then there must be a queue of ready work in front of him.

By queuing up ready work for people (resources) they can start work that will be finished. Finishing work on projects usually means work is released for others on the project. Further, when work is in a condition to be started and finished, the work gets finished reliably.

But how do you do that? How do you know ALL of what needs to be done? You as a project manager alone don't know. You plan with a team of people who are responsible for assigning work on your project. You do this every week looking out a month or so. In these conversations you will discover what resource will be constrained and what is yet to be addressed for making the work ready. These are the conversations to assign responsibility for addressing each of the issues that keeps the future work from happening as intended.

You know the routine — time to visit Frank and Joe.

Previous in series Next in series

Day Three of the Series on TOC in the Project Setting with Frank and Joe

Multi-tasking resources in contention is a principle source of throwing a project out of sequence.

The lift story was an example of a temporal constraint. We call these resources in contention (RIC). There could be plenty of overall capacity for performing over the life of the project, but at any given moment two or more actions must be taken by the same resource. Engineers find themselves in this dilemma. An engineer may be asked to get 2 (or more) tasks done for the same or different projects in the same time window. Trying to please both parties by getting a little done on each everyday, the engineer fails to get either done on time. On the surface this only looks like a physical constraint. But is it? There may be a 'policy' to always please the customer. That policy gets interpreted as not saying "No" to a request. Further, engineering organizations are often run to maximize the amount of time spent on engineering. To do that, they build up work queues for each engineer. This necessitates a practice of starting and stopping and then restarting. Does it sound like waste? It is.

Multi-tasking resources in contention is a principle source of throwing a project out of sequence. Projects that get out of sequence get delayed. So what can we do? Know who (or what) are the resources in contention on your project. Apply the five focusing steps to them. And, do not let team members start one task before they finish the task they are working on. Sound crazy? We'll deal with that tomorrow.

In the meantime check out these two TOC resources: CIRAS and TOC Dictionary. Then go see Frank's Focussed Performance Business Weblog and Joe's Learning About Lean.

Previous in series Next in series

Exploring the Theory of Constraints in the Project Setting (second in the series) with Frank Patrick and Joe Ely.

Physical constraints are not the only limiting effects on projects. Eli Goldratt identifies two other types: policy constraints and paradigm constraints. Let's work through an example.

On a multi-story building job site there will be an exterior man-lift for carrying workers and material up and down the building. Large jobs might have more than one lift. We can begin to understand the lift as a constraint considering it only holds 8 people. If there are 80 people to travel on the lift it will take at least 10 trips to get them to their place of work. It will take more trips when the lift is not full. On the surface this looks like a simple physical constraint. But is it?

On most job sites the policy is for workers to start at the same time. While some people will come early to avoid the rush, which will only succeed if one of those people is the lift operator, what inevitably happens is a queue builds every morning, at lunch, and again at the end of the shift. What if the policy was changed? Perhaps the iron workers would come in first, followed by the plumbers five minutes later, followed the electricians, etc.? The end of their workdays would also be staggered. While there could be a bunching up due to variation in the arrivals of the individual trades, you wouldn't have less lost time waiting for the lift. Still, iron workers, plumbers, and electricians will likely be scattered across a number of floors. Bunching by trade will result is losses in travel as folks are dropped off on different floors.

So what about paradigm? We live in a world that thinks whoever is in line first gets to go first. Further, if the lift is there, then one can ride it. Are these stated explicitly? No. But we do operate that way. What if we change the rules for riding the lift? Let's say it is reasonable for people to walk up one flight of stairs and walk down two flights of stairs. On what floors would the lift need to stop in a ten-story building?

[think]
.
.
[think]

In the usual case of first-come, first-served, a mixed group of people get on. Each time the lift stops some people get out, while others must wait to ride to their floor. That waiting time takes away from operating time. Adopting the proposed policy changes that. The lift only makes

- the fifth floor and the ninth floor. A policy could be added to have people arrive for travel to the fifth floor at one time and the ninth floor sometime later. That would reduce the waiting time for the lift and the waiting time on the lift.

In this example we turned a physical constraint first into a policy constraint, then into a paradigm constraint. Make your constraints disappear in the same manner. And, remember to check-in on Frank and Joe.

Previous in series Next in series

The first in a five-part series on applying the Theory of Constraints in the project setting.

Projects of all types get bogged down. Something happens - unexpected - that puts the team members into a react mode. From there it is all downhill. While many people will offer good advice (they've got no skin in the game) few can offer a perspective that can keep a project on track. Enter the Theory of Constraints.

In the simplest terms think of a constraint as a restriction to flow. A bottleneck restricts the flow of liquid. Widen the neck and the bottle is emptied faster. Cranes are an obvious possible constraint on construction projects. Anything that must be lifted has to be carried by the crane. On any given day there may not be enough crane time to move all the material desired. Therefore the crane restricts the amount of work that can be performed in the day.

These are the physical constraints:

• People - not enough engineers for the work needed in a given time
• Space (access) - often there isn't room for two people to be working in the same location
• Equipment - availability of any one tool can limit progress on a given day

Think of physical constraints as anything that carries a load — people, tools, equipment, space (access), and talents (special competence). Projects are often long enough that we often have time to address physical constraints.

We manage our physical constraints through a five-step process of focusing.

1. Identify the constraint - look for places that work bunches up
2. Exploit it - get everything you can from it.
3. Subordinate all other actions to it - don't use the constraining resource if you can use another resource…even if it looks less efficient to do so
4. Elevate it - find ways to increase the capacity
5. Repeat the cycle - usually another pass through will improve the situation

Of course, this can be done prospectively. Look forward on your project. Ask, "What could keep us from proceeding at the intended pace?" Use the five focusing actions to stay out of trouble.

Now visit Frank Patrick and Joe Ely for their concurrent postings on TOC for projects.

Previous in series Next in series

In the usual practices of project management establishing precendence relationships is a key step in creating a network plan for the project. Along with that the planner often establishes early and late start dates and a finish date. But these dates have nothing to do with what will be done when the time comes for the task. Why? One reason is due to the variation of task completion throughout the project. We can count on each task taking a different effort and duration than was originally planned. Let's consider an example:

The engineering specification expected to take 20 hours and due on the 15th of the month actually took 30 hours and was completed on the 20th. Further, the task was planned for one person, but that person needed others' help. To the extent that other work couldn't begin 'til the spec was ready (a usual case for a spec), the project accumulates delay. Further, there is less engineering hours available than were originally planned due to the variance in effort of the enginneer and the help provided by others. While it is true that some tasks take less effort than estimated, our project experience tells us that we rarely benefit from early completions. So we have a project that will require more hours and more duration than originally planned.

What can be done? First, one must identify the situations that are likely to vary from the planning estimates. Then, buffer other tasks from that variability and work to reduce the variability. How? For recurring tasks one can study the flow of work, reduce the waste, minimize ambiguity, and appropriately staff the task with necessary skills. Is this enough? No, because we have variablility popping up all over. The solution then must be systemic and organizational. (more to come)