Reforming Project Management » Theory of Constraints

Does Reliability Matter in Project Planning?

Hal — Wed, 22 Apr 2009 01:20:27 +0000

: Image via Wikipedia

Ihad an interesting question about plan reliability. "Why does reliability (PPC) matter?" My first thought was, "Where do I start? Of course it matters!" Ok. Breathe in; breathe out. I know what to do.

A good planning system will enable project team members to fulfill their promises just as they make them

Let's start with PPC. We recommend measuring planning reliability using the measurement percent of promises completed. Our thinking is if people can do what they promise to do, then the planning is good. It doesn't mean that the future should be just as we planned it to be. Life's not like that. But, if we're doing a really good job with our planning, then most of the promises we make for completing work will be kept. PPC is a measure of reliability.(...)
Read the rest of Does Reliability Matter in Project Planning? (220 words)

Feed enhanced by Better Feed from Ozh

Turn Rocks into Gold on Your Projects

Hal — Mon, 26 Jan 2009 00:27:40 +0000

Clarke Ching, regularly blogging at Clarke Ching — More Chili Please, just published his second book titled, Rocks into Gold. He wrote the book in response to the sorry state of the worldwide economy, particularly for those working on projects in the software industry. He tells a story of optimism in the face of our everyday pessimism. It's a book about ingenuity, frank reality and a touch of cynicism for it to ring true.

He tells a story of optimism in the face of our everyday pessimism.

The story opens with a software development firm losing a contract with one of its biggest clients. The loss will likely lead to significant layoffs. People are devastated. One person, it could be anyone of us, finds a path forward.

(...)
Read the rest of Turn Rocks into Gold on Your Projects (153 words)

Feed enhanced by Better Feed from Ozh

Clarke Says, Multi-Tasking Is Evil, I Agree

Hal — Fri, 16 May 2008 02:22:01 +0000

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 Clarke Says, Multi-Tasking Is Evil, I Agree (233 words)

Feed enhanced by Better Feed from Ozh

Understanding Project Constraints

Hal — Mon, 05 Feb 2007 04:57:12 +0000

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 Understanding Project Constraints (130 words)

Feed enhanced by Better Feed from Ozh

Lessons David Learned from Eli

Hal — Fri, 02 Jul 2004 22:44:20 +0000

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

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.

Feed enhanced by Better Feed from Ozh

How Do Scrum and CCPM Compare?

Hal — Fri, 14 Nov 2003 18:07:16 +0000

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.

Feed enhanced by Better Feed from Ozh

Don’t Use Percent Complete

Hal — Sat, 25 Oct 2003 19:51:38 +0000

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."

Feed enhanced by Better Feed from Ozh

Project e-Tip of the Week

Hal — Thu, 26 Jun 2003 06:08:45 +0000

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.

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

Feed enhanced by Better Feed from Ozh

Customers, Promises, and TOC

Hal — Sat, 19 Apr 2003 00:36:13 +0000

Article Series - Down n Dirty with the Theory of Constraints

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

Feed enhanced by Better Feed from Ozh

5 Practices for Managing (Constrained) Projects Successfully

Hal — Fri, 18 Apr 2003 01:22:27 +0000

Article Series - Down n Dirty with the Theory of Constraints

Theory of Constraints Perspective for Projects
Physical Project Constraints
Policy Project Constraints
Multi-Tasking Leads to Project Delays
Take Good Care of Constrained Project Resources
5 Practices for Managing (Constrained) Projects Successfully
Customers, Promises, and TOC

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

Feed enhanced by Better Feed from Ozh

Take Good Care of Constrained Project Resources

Hal — Thu, 17 Apr 2003 00:05:20 +0000

Article Series - Down n Dirty with the Theory of Constraints

Theory of Constraints Perspective for Projects
Physical Project Constraints
Policy Project Constraints
Multi-Tasking Leads to Project Delays
Take Good Care of Constrained Project Resources
5 Practices for Managing (Constrained) Projects Successfully
Customers, Promises, and TOC

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

Feed enhanced by Better Feed from Ozh

Multi-Tasking Leads to Project Delays

Hal — Wed, 16 Apr 2003 01:26:36 +0000

Article Series - Down n Dirty with the Theory of Constraints

Theory of Constraints Perspective for Projects
Physical Project Constraints
Policy Project Constraints
Multi-Tasking Leads to Project Delays
Take Good Care of Constrained Project Resources
5 Practices for Managing (Constrained) Projects Successfully
Customers, Promises, and TOC

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

Feed enhanced by Better Feed from Ozh