CCPM

Destuction and Creation

2011-12-18T15:05:00.000-07:00

Hi, Folks

I had occasion to re-read John Boyd's Destruction and Creation paper. It is an Appendix to the reference below. If you don't know John Boyd or the reference I suggest putting the reference on your Christmas list.

The paper is the result of some very deep thinking. Boyd included some key references but we know Boyd had a much deeper reading list. You can Google him and the reading list if you want to know more on that. You can also find some of his presentations. He worked before death by PowerPoint.

The point I wished to address in this blog is about so-called "resistance to change". He concludes from a few scientific principles that, "whenever we attempt to do work or take action inside such a system...we should anticipate and increase in entropy hence an increase in confusion and disorder". In other words what people perceive as resistance to change is actually how such systems naturally behave. It has nothing to do with people resisting anything.

There is a well-known effect in psychology called the "fundamental attribution error". It is inherent in how our brains work. We blame people for things they do not actually control.

When you understand this you plan and execute different actions while seeking to bring about change in organizational behavior. You expect the confusion and disorder and plan to sense for it and mitigate it. Boyd suggests, "uncertainty and related disorder can be diminished by the direct artifice of creating a higher and broader more general concept to represent reality".

Coram, R. (2002). BOYD The Fighter Pilot Who Changed the Art of War. New York: Back Bay Books

Kahneman's THINKING, FAST and SLOW

2011-11-27T13:57:00.000-07:00

I just finished reading the title book. I highly recommend it. It adds much to the earlier works of Nobel prize winner Daniel Kahneman.

The book provides much food for thought relevant to critical chain and more generally to the Theory of Constraints (TOC) and to management in general. It is geat material to help act on Dr. W. Edwards Deming's point of Profound Knowledge: psychology.

He structures his work around two brain "Systems". But he notes (in something
that I believe applies as well to much of the right brain/ left brain stuff),
"the systems do not really exist in the brain or anywhere else. "System 1 does
X" is a shortcut for "X occurs automatically." And "System 2 is mobilized to do
Y" is a shortcut for
"arousal increases, pupils dialate, attention is focused, and activity Y is
performed." (OK, there really is a physcial right and left side of the brain but
ascribing functions to them is like the preceeding.)

One of the strongest messages (there are many more) that I got is that we really
have to do away with the "cut task estimates" approach. It was a huge
psychological mistake for Eli G to put it that way and for those of us like
myself to uncritically follow that wrong advice. Many people view that as a loss
and consequently will fight it.

Instead we need to convey that task estimates should be made assuming 100%
resource focus for the resource that causes the task duration (other resources
needed on a task can be less than 100% when considered for the whole duration of
the task). Then the project scheduler should put a portion of that estimate into
the task itself and use the remainder in sizing the buffer. It needs to be clear
that nothing is lost. In fact with critical chain buffers individual tasks can
go far over what is associated with the individual task in the schedule without
causing to project to be late: in fact everybody wins by gaining access to the
buffers.

Some will claim it is semantics but research clearly shows it matters to most
people (i.e. upwards of 85%)...a lot. And it is a systematic effect so its kind
of dumb to ignore it once it has been brought to our attention. Alas one of the
other points of Kahneman's work is that it is human nature to do exactly that.

The Passing of Dr. Elyahu Goldratt

2011-07-15T18:35:00.001-06:00

It has been over a month now since Dr. Eliyahu Goldratt passed away. I am deeply saddened by the loss and not sure what to say about it other than to send my strongest compassion to his family, friends, and close associates.
Although we spoke briefly a number of times I know I feel I knew him much more than he would feel he knew me. I don't even know if he would have recognized me or my name. But having read all of his books, attended many multi-day conferences where he spoke for many hours, and having seen many hours of video tapes of him I feel a strong connection and sense of loss. He and I are the same age within less than a year. Perhaps that affects how I feel: an increased sense of the reality of our short existence.
Although he didn't live as long as some people do he accomplished far more than most. I consider him above all an outstanding teacher. He challenged everyone to think and worked his life to help us think more clearly. That should be his legacy.
I have seen several postings where people thought it necessary to point out his sometimes aggressive answers to questions or comments from the audience after encouraging such questions. I actually quite enjoyed his frankness. He once had some comments on a presentation that I gave at a TOC upgrade in Colorado Springs. Some people came by to sort of apologize for him. I sincerely appreciated and agreed with what he had to say! I love that kind of open dialog...it is one of the things I will miss about him.
Mostly I think we can honor him best by keeping his memory alive and practicing clear thinking!

Kanban and LPM?

2011-04-17T23:20:00.000-06:00

You may have heard of Kanban as a tool used in production for "Just in time" production of parts needed for an assembly line. That's about all I knew about it until I read David Anderson's new book: Kanban. The subtitle is "Successful Evolutionary Change for Your Technology Business".

Although David discusses the application of Kanban for Agile software development I immediately saw it as a huge breakthrough for larger projects of almost any kind. At least I can't think of a project type it wouldn't work for. It can solve two huge issues confronting many implementations of LPM/CCPM:
1. Supervisors have a difficult time removing the multitasking of their staff when driven by both project work and non-project work; e.g. operations or field product support.
2. All managers want to wait on reducing multitasking until all the projects are scheduled and pipelined with critical chain schedules. This often can take some time and they are losing the immediate benefits achievable by avoiding multitasking. Kanban reduces the Work in Progress (WIP) to that which can be sustained with focuses work; i.e. without multitasking.

Kanban as applied this way has three major elements:
1. Visual control at the work group level of ALL work.
2. Limiting WIP to that which can be accomplished with focused work (no multitasking).
3. PULL of work by each performer: select the next task to start only when you finish one.

I strongly recommend reading David's book...but if you don't do software you have to be a bit of free thinker to realize his method has very little to do with software. It can apply to all work. That was my first realization.

Second I have developed the process for completely linking it with critical chain project schedules. This makes it applicable to very large complex projects; not just the small groups of developers David addresses.

I'll add some figures and a presentation in future posts.

In the mean time, if you want to hear me talk about it come to Ogden, UT on May 5: http://cpi-symposiums.com/11sympweber.html

Lean "vs." TOC Addressing of Variation

2011-03-17T10:47:00.000-06:00

A recent comparison of Lean "vs." TOC noted that TOC puts much emphasis on managing variation while much of the Lean literature does not address it.
I will add that Six Sigma makes reducing variation the main goal...a different focus than Lean or TOC.
This time I must say all three are right. Again there is no "vs.", which is why I put it in quotes.
Lean comes from a production background of more or less continuous flow. So does the Drum Buffer Rope (DBR) component of TOC. Both emphasize using Pull to control work flow. Both also emphasize reducing the Work in Progress (WIP). This naturally requires steps to reduce variation in production step durations.
Of course all methods recognize defective product as waste to be eliminated. Thus variation in production operations of the sort that causes waste is the enemy for all three perspectives.
TOC employs time buffers as an explicit management tool to control variation in output flow. While Lean and Six Sigma do not explicitly address using buffers for this purpose I see no conflicts in doing so.
You can indeed have your cake and eat it, too!

Lean "vs." TOC Improvement Focus

2011-03-17T10:38:00.000-06:00

I was recently asked to review a comparison of Lean and TOC. One of the items noted was that TOC focuses improvement on the system constraint while Lean encourages continuous improvement of all processes.
I believe this is a good case where both are right. Everyone in the organization needs to participate in the culture of continuous improvement of all processes. Much of the Lean discussion focuses on the actions of what we in the west would consider the first level supervisor coaching the work team to continuously improve. That is their job. It is what they should do. It does not conflict with TOC at all. That is the reason I put the quotes around "vs.". There is no "vs." in this topic.
Indeed, TOC suggests there is never a "vs.". Conflicts are only appear to exist due to different assumptionns.
Higher levels of management need to work to improve the value streams. That means focusing on the constraint as first priority.

SMART Goals

2011-01-17T16:01:00.004-07:00

You have all heard of using the acronym SMART for goals. Everyone knows the acronym but there is not agreement on the meaning of all of the letters. Most agree on the first two and the last: S is for specific, M is for measurable, and T is for time specific; i.e. setting a date.

Rather than go through the alternative meanings for A and R, I will just pose (and post, too) my recommendations. If you want to see what others use do some Internet searching. I recommend:

A is for the Accountable person, by name, for delivering the goal result. It can only be ONE person, and it must be by name. That person may need to engage a cast of thousands to get it done but that person is accountable for the result no matter what.

R is for the Reason for achieving the goal. The more you can make the reason evoke emotion in the goal achievers the better a reason it is. If you want to know more about the reason why I suggest this please read SWITCH by the brothers Heath; in particular p. 82.

I will also elaborate a little on my take for the other letters.

S is for specific. If you think of the 5Ws and an H (What, Why, Where, Who, When and How), the S answers What and Where. BTW, because this is a goal and not the plan we aren't going to include the H.

M is for the measure. I like Joseph Juran's ideas on how to specify the measure: first in terms of the units of measure and then by an operational definition of how to take it. Since this is a goal it should include the Target value for the measure.

T is for time specific. Usually that means a due date. Since we are in the realm of Lean Project Management, you should think of that as a buffered end date for the work to do the task. For more complex goals requiring a project to achieve them setting T may need to be a two step process. The first step sets a desired due date and the second agreed upon due date is the buffered end date of the project schedule.

2010-09-13T17:59:00.000-06:00

Little’s Law and Lean Project Delivery
by Lawrence Leach, PMP
President, Advanced Projects, Inc.

Little’s law relates Throughput (T), Work in Progress (W), and the Cycle time (C) through a system. Cycle time is the same as project duration. The law is:

T = W / C

Looking at it, one might think “Ah-ha! If I want to increase T, this means I need to increase W.” That isn’t what it means. It just means that over time, systems will tend to level out with this relationship applying.

Since the law relates three variables, we need to have two more equations to solve for the variables. One or two of the equations could be setting variables to a constant.
Let’s consider a relationship between W and C that applies to a system that might have multitasking. Define the ideal state as having no multitasking. We know that multitasking increases the duration of projects by at least the increase in the number of projects we are doing simultaneously. So if we let W represent the number of projects, then C = W * D, where D is the duration of the single project. For the rest of this analysis, we are going to set D = 1. The graphic illustrates three identical projects with no multitasking.

The first thing that multitasking does is make each task take longer. Now let’s suppose that the resource switches between the three tasks above. You might expect to get something like the following.

In this illustration, C increases to something over twice what it was before. If I had put in more switches, it would increase even more…in the limit, to three times the original duration if the switching is between three tasks. I sometimes draw the lower case with three horizontal bars to better illustrate that.

Alas, that isn’t what you get. Research shows that task switching causes lost time. Although computers might be able to task switch with a single clock cycle even computers use up some computing power to control the task switching. Task switching for humans is much slower and involve es much more waste. For tasks with mechanical work, they have to get to the new place, change tools, arrange things, etc. For mental work, they need to arrange information both in their environment and in the brain. Let’s call the task switching time e, and suggest this means that C = W (1+e). So if, for example, the task switching loss is 20%, you might expect the cycle time will increase to 1.2 times the single cycle time was. But it happens each time you switch. So you might expect to get something like:

That’s OK for going from working on one task to working on two tasks. But what about working on three or more tasks? Isn’t it likely that the task work will get more difficult as the number of active tasks increases? Each task requires some storage of information and often communication about how it is going and to get and give information. For example, if you are working on tasks for three different projects at the same time you at least will have to provide status information on all three, and maybe have to go to project meetings on all of them. Perhaps the e factor applies for each task, not just one time. The way to write that is C = W (1+e)^(W-1). Pictorally, this means you should expect something more like the following with three times multitasking.

Notice that if W =1, (W-1) = 0. You should recall from algebra that anything to the power of zero is one. So we are back to C = W for a single set of projects where there is not multitasking.

Putting these equations into an Excel model for various values of W and e yields the following tables:

To read these tables, start with some level of multitasking, represented by W, and m ake an assumption about the task switching loss, represented by e, that currently exists in the organization. You can get an estimate of the amount of multitasking by asking people that work on project tasks, “How many project tasks are you working on today?” Sometimes people are assigned to work certain percentages on tasks from different projects. Let’s say that the average reported amount of multitasking is 3.

Then you need to estimate the task switching loss. Usually no one has a clue what this is. If people offer an estimate, suspect that estimate. It’s probably too low. Research shows that the % of task time wasted by task switching can be 40%. In specific kinds of tasks, it can be a fixed amount of time lost. One study showed it took 15 minutes to get back to where you were on an intellectual task. Another study showed 20 minutes. Let’s make a conservative estimate of a task switching loss of 20%, or 0.2.

The first table has the value of 0.59 in the box for W = 3 and e = .2. That means that the current level of T is 59% of what it would be with no multitasking. Put another way, it means that if you can change the organizations behavior to focus on one task at a time, Throughput should increase by about 70% (41/59). This is a common result with Lean Project Management.

The second (C) table has a value of 4.3 in the cell for W=3 and e=.2. This means that cycle times would decrease to less than one fourth of the current cycle time; a 75% decrease. That amount of decrease is not often seen. It suggests the model may be missing something.

The model in fact misses many things, including:
• Task synchronization; i.e. where a task cannot start because it lacks input or a resource.
• Variation, not addressed in the model.
• Mistakes.
• Task escalation…efforts to recover schedule over-runs.
• Projects are made up of many tasks linked in various ways.
Models are always simplifications of reality. Hopefully this application of Little’s Law with the model helps you see better what it means in terms of what you have to do to increase Throughput: stop the multitasking!

© Advanced Projects, Inc. 2010: You can make copies of this as long as you keep the copyright notice with it.

Implementing Lean Project Management

2010-09-12T16:57:00.000-06:00

Hi, Folks

Lean Project Management works to create huge benefits in most organizations by driving new non-intutitive behaviors. If the behaviors were intuitive the organizations would already be doing them.

Behavior change is hard for both individuals and organizations. I believe it is harder for organizations than for individuals. Each of you has probably tried to change some your own behaviors and found how hard it can be even when you are completely bought into the change; e.g. stopping smoking, exercising more, losing weight, etc. Of course it is harder to get a whole organization to change their behavior to your way of thinking, especially when the changes you want are not intuitive.

The model I recommend for this follows the steps of Dr. John Kotter from Harvard. His books The Heart of Change and one he coauthored, the Heart of Change Field Guide, provide the best approach I have found. Even it doesn't work all the time, but it's the best I have found. If you find something better, please let me know.

When I was first introduced to the Theory of Constraints (TOC), I learned Goldratt's model for change. It answers three questions:

1. What to change?
2. What to change to?
3. How to cause the change?

For the last, it suggests a model called the "layers of resistance" model, which I will refer to as the LOR model. The LOR model was put forth by Eli Goldratt, and is repeated by many TOC practicioners. It suggests people have to go through five steps or layers in order to embrace change:
1. Agree on the problem.
2. Agree on the solution.
3. Have promises that unintended consequences of the change can be overcome.
4. Have confidence that obstacles to implementation can be overcome, and
5. Overcome fear of being the first or only to take action.
Note that some break step 2 into two steps and others add layers but this basic LOR model is most common.

While I liked the logic and bought into it at first, I didn't find it useful to create organizational change. First off, people did not raise the obstacles suggested. Instead, they first wanted to know about organizations just like them that had made the change and the success they had. Second they usually had something else going on, so although they agreed that the solution was just what they needed, they felt that now wasn't the right time. One might say they jumped to level 5 of the Goldratt model.

Research on organizational change and thinking it through has led me to understand that Goldratt's model has little value, and why it has little value. These are the issues I see:

1. The model has no basis to start with. There are no references to preceeding work or data that lead to those five items.
2. The model has not been tested. When I tried it, definitely not a controlled experiment, it failed.
3. The model up to the last step is purely logical. It assumes people think things through stepwise. People don't think things through, much less stepwise. They react emotionally first. Kotter's model starts with this understanding.
4. We are seeking to change behavior. Behavior change is not a logical thing. Behavior is a result of reinforcements. Changing behavior takes time and repetition. The LOR model does not address behavior change.
5. Organizational change is a social phenomena, not an individual one. The LOR model does not address the sociology of the change. Kotter's model starts with this premise.

So although Goldtratt's LOR model makes a nice story, I suggest you not depend on it if you want to cause change in your organization. Lean Project Leadership helps you lead successful change using Kotter's approach.

Boiled Frogs

2010-05-27T12:07:00.004-06:00

Most of you have heard the story about boiled frogs. I don't know if it is true about frogs, but just had a first hand experience with the idea that I will share with you while it is still, so to speak, staring me in the face.
In case anyone hasn't heard the boiled frog story, it goes something like this. If you try to boil a frog (I guess it presumes you are French) by throwing a live frog into a pot of boiling water, it will immediately jump out; so fast that it doesn't even get burned by the boiling water. On the other hand, if you put the frog into nice warm water, where it can happily float doing its normal froggy things, and then heat up the water, it will stay there and boil to death.
My boiled frog has to do with cataracts. Cataracts are fuzzy spots in the lens of your eye, that can increase over time. I was blessed with perfect vision for my first 40 years, so quite offended when I found I needed glasses to focus closely about that time. Over time, the eyeglass prescription changed, and I learned to live with it. More recently, I was noticing glare. First when driving at night, and then in brightly lit places. I was beginning to see a haze even on beautiful Idaho days. (We don't do smog in most of Idaho). My eye Dr. assured me I had cataracts slowly increasing, and left it to me to decide when to do something about it.
I did the research, and was sure the surgery was something I would do sometime. The risks are quite low, but hanging out there, albeit at very low probability, was the chance of completely losing your vision. I demurred. For several years.
Tuesday, two days ago, I bit the bullet. I am not sure what finally drove me over the decision threshold, but one contributor was that in most light conditions, I couldn't see the numbers on the speedometer and tach on my latest toy (Z4). Plus, I was collecting speeding tickets. That was just too much!
The surgery itself was nothing. They asked me to lay back, and started putting drops in my eye. That was as bad as it got. An hour later, my son was there to pick me up. They had a patch over my eye, and I was committed to keep it closed most of that day, except for peeks to put in more eye drops.
Later in the day, the Dr. called to see how I was doing. I told him fine, and asked if I could now start looking. He said sure.
The best thing I can use to explain it is like the beginning of the movie The Wizard of Oz, when Dorothy wakes up in Oz. For those of you that do not recall, the movie starts out in black and white, and when she awakes in Oz you are overwhelmed by the bright colors in the scene. Actually, it was much better than that, because at least Kansas was in focus, and I learned that I was not. So the bright colors brought with them textures that I didn't know existed, even with my glasses on...and now I was looking without glasses. Ohmigod! How could I have waited so long?
So what does this have to do with Lean Project Management? I got an email this morning from a prospect who wanted to put off their first two-day training class, because their management was busy restructuring, and wanted to finish that first. They also wondered if we could do the two-day training in one day, because they were oh-so-busy.
I can see them paddling away in their pot from day to day, while demurring like I did. They don't get that Oz exists just as soon as you decide to go there in your mind. Reality follows immediately, once you take the necessary first step.
I'll discuss paradigms in my next post.
OBTW, I have scheduled the next eye at their next available appointment next month.

Larry

3 Rules

2010-05-24T09:53:00.002-06:00

As described in Lean Project Leadership the lean approach to successful project delivery replaces the general direction of trying to create project success with more and more detail with a simplified approach using three new rules. The rules are Focus, Buffer, and Pipeline.
Focus means enabling everyone who works on a project task to focus on that one project task while they are working on it, and to complete it as soon as possible (ASAP). Focus includes responsibility to inform project management as soon as anything might interfere with timely focused completion of the task, such as a needed decision or task input. It includes escalating tasks for management help whenever assistance is needed to keep the task flowing.
The Buffer notion includes creating schedules with Project and Feeding buffers and using those buffers two ways during execution. Effective use of the buffers during execution includes effective statusing of project tasks so that the buffer can be used to prioritize tasks for execution by resources. Statusing also enables determining when and where project management must take action to ensure that the project completes within the project buffer.
Pipelining is controlling the Work in Process/Progress (WIP)to enable focus on one task at a time. Pipelining sets project start dates so as to not overload the most loaded resource during project execution. Not overloading the most loaded resource means that all other resources have additional reserve capacity. Pipelining introduces the Capacity Constraint Buffer, which ensures that even the most loaded resource is not overloaded, including all demands on the most loaded resource. When the most loaded resource is used to set the start date for projects, it becomes the Drum...the mechanism for controlling project WIP.

Project Plan

2010-05-24T09:36:00.002-06:00

I learned the need for an effective Project Plan early in my career. It made all the difference. I have found that people who know how to develop and use a Project Plan usually lead successful projects. Those who don't, don't.
Many confuse a project schedule with a Project Plan. Although a Project Plan includes the schedule for the project, it is much more than a schedule.
The Project Plan includes the scope, schedule and cost baselines for the project, and all of the operational procedures necessary for successful project execution. The operational procedures may be by reference in larger organizations that have standard procedures for such things as quality, safety, and configuration management, although usually these require project-specific implementation guidance. The Project Plan must include the project's procedures for schedule and budget status and control, including management of changes. It must include the communication process for the project.
Scale your Project Plan to the size and complexity of the project and the experience the team has working with one another on similar projects.

Work Breakdown Structure (WBS)

2010-05-24T09:25:00.005-06:00

I have recently found that some who teach Critical Chain (it can't be CCPM because of what follows) eschew the Work Breakdown Structure (WBS). I think this a huge mistake, and evidence of ignorance, or at least lack of skill in how to create and use a WBS.
A WBS does many things for effective Project Management: the PM part of CCPM. The first thing it does is organize the deliverables the project must produce. Having a clear vision of the project result is a prerequisite to success. Organizing the WBS logically begins the process needed for successful project delivery.
The WBS then helps assign accountability to create the necessary tasks to produce the deliverables, and to perform and deliver on those tasks. The hierarchical formatting of the WBS helps break the project deliverables down to managable chunks assignable to Work Package Mangers accountable to deliver those chunks.
Where appropriate, the WBS can also be used to organize the budget for the project.
The WBS provides a way to quickly identify project tasks for use during execution. Using the WBS number instead of a task name helps identify where the task fits in the overall project, and to drill down to more detailed task information when needed.
The WBS also supports a more detailed Statement of Work (SOW) when needed. The simplest form is called a WBS dictionary: a several word to paragraph description of each deliverable. The more complex forms can include or reference detailed specifications and drawings.
There are many good references for how to create and use a WBS. The Project Management Institute's Practice Standard for Work Breakdown Structures is simple and useful. There are larger DoD standards available on the Internet.

Feeding Buffers

2010-04-29T12:50:00.002-06:00

Hi, Al

I recently engaged in a discussion of the Feeding Buffer in another blog. I thought it might be helpful to post my thoughts here, as well.

Here is the case given:

Using the example of the 3 equal length chains (A, B and C) feeding into a single task (D) with the appropriately sized project buffer based upon the 50% rule, and without any feeding buffers.

Chain A = 60 days
Chain B = 60 days
Chain C = 60 days
Task D = 20 days
Project Buffer = 40 days
Project duration = 120 days

Note: if feeding buffers were inserted into chains B & C the project duration would be increased by 30 days (150 days total duration.)

As stated above any of the 3 chains could be named the 'critical chain', so let’s call Chain A the Critical Chain. During execution, variation is experienced on say chain B, this now becomes the critical chain, the variation is as expected absorbed within the project buffer. The effect of this variation is the creation of ‘float’ (proportional to, or less than the variation of chain B otherwise they would be the critical chain!) between Chain A and Task D, and Chain C and Task D. Any subsequent variation within Chain A and Chain C would be absorbed firstly by the float, and secondly by the project buffer if the variation is greater than the variation on chain B, and would therefore become the Critical Chain which would then create float for chain B.

Here is my reply:

Float is not a meaningful term with critical chain schedules. It is an accident of the network in critical path schedules that comes from using early start. It has nothing to do with task variation. Since CC resource levels and late starts feeding chains, as allowed by resource leveling, there is no float in critical chain schedules.

At least, it is confusing to call the gaps in CC schedules float, because they come from entirely different causes and are generally in different places than float in CP schedules. Some CP people can never get over that confusion.

There can be gaps in critical chain schedule chains. They are not float because they come from constraints. Gaps in feeding chains come from resource leveling. Gaps in the critical chain come from inserting feeding buffers in situations like the one you describe. The gaps are not float because you cannot move the tasks within them without affecting something else.

The network you describe requires completion of A, B, and C before D can start. If you have used 50/50 estimates the probability of having all three (A, B, and C) without feeding buffers is .5x.5.x.5, or only 12%. Thus, you need the extra buffering to account for this. The project buffer assumes that the probability of starting its predecessor is 50%.

In this case, it doesn't matter much if you stick the feeding buffers in the chains or move it to the project buffer. The only slight issue with the latter is that it affects your action criteria for buffer recovery; i.e. you need to have more days delay to trigger action at a specified % of buffer consumption with a larger project buffer.

One needs to be a little careful using very simple examples. They often magnify things that don't matter in realistic networks. Two of my networking guidelines for realistic networks are:
1. There should be at least ten tasks along the critical chain.
2. No single task should exceed 10% of the duration of the critical chain.
You need that if you want statistics to work for you.

In your case, I'd consider running the 30 day "tasks" as SCRUM sprints of 30 days, using a "feature buffer", if that works for the type of programming you are doing. So each could break into 30 one day tasks. Or, you could do the CC part of it with weekly statusing; e.g. four or five five-day tasks. Then I'd use a conversion of something like features planned to features accomplished to put in a pseudo "days remaining", because in reality you are time boxing the feature development. Can I suggest David Anderson's "Agile Management for Software Engineering"?

There is another way to think about it. Consider combining the three parallel tasks into a single task. That task must have a duration representing a 50% probability of completing in that time or less. Since the 60 days represents only a 12% chance of completing the work on all three subtasks within that time, the task needs to be longer than 60 days. How much longer depends on the task performance distribution, which no one usually knows. Let's assume it just happens to match what we would normally use as the feeding buffer: 30 days. So the combined task is now 90 days, the integration task (D) is still 20 days, and the project buffer must now be 55 days, for a total project duration of 155 days.

Real projects that follow the networking guidelines can have critical chain gaps, but they usually are not as dramatic as in this simple example. Running multiproject CCPM leads you to look at prioritized task lists for task selection and the project chain view for planning buffer recovery. Gaps in the initial critical chain just don't come into play. Try it, and you will see.

Regards,

Larry Leach

Lean Project Leadership

2010-04-29T12:42:00.002-06:00

Hi, All

My latest book, Lean Project Leadership, was published in April. You can find it on Amazon, or through my WEB page: www.advanced-projects.com.

I was recently asked, "Why publish another book on Lean Project Management?" The key is in the new title: Leadership. While many people easily get the ideas of Project Management, TOC, Six Sigma, and Lean, putting those ideas to work in an organization is quite another matter. Many organizations struggle for years to implement any one of those ideas alone, and many that make some progress lose all their gains within a few years. I thought it time to take a cut a lasting approach. The approach is all about Leadership.

To that end, Lean Project Leadership focuses much more than my other works on what it takes for a leader to implement and sustain Lean Project Management in an organization. I go into the necessary roles people must play, a proven approach to change implementation (following John Kotter), and end up with establishing an environment of continuous improvement.

In addition, as explained in the introduction, I tried a somewhat novel format. No, it isn't another TOC novel, although the format is something like Eli Goldratt tried in The Race. I fist saw the format tried in a book about time management. I know the author, but have lost the book. It has been replaced by a later book co-authored with Stephen Covey (First Things First), but that one does not use the two-page format. Too bad.

Lean Project Management

2010-02-18T14:21:00.003-07:00

It has been quite a while since I did anything with this blog. I spend a lot of time writing input to an online CCPM group. I have decided it is time to at least post the more significant contributions made there here as well.

Before getting to that, though, I thought this blog needed a little direction nudge. I have been putting more emphsis on a Lean approach to project execution, which I originally called Lean Project Management (LPM), the title to my second book. I am even moving beyond that with Lean Project Leadership (LPL...happens to match my initials) with my next book, which may come out next week.

The figure illustrates the four major inputs I consider for LPM; i.e. the Project Management Body of Knowledge (PMBOK), the Theory of Constraints (critical chain), Six Sigma, and Lean. These approaches agree on some things, which is nice. Sometimes one covers things the others do not, which is also nice. And, sometimes there appears to be disagreeement. I like the disagreement best, because it suggests we are missing something in terms of a management science.

So what is Lean about LPM? First, the focus does include the primay direction of Lean: reduction of waste. Alas, too many people interpret Lean as cost cutting, which isn't the same thing, or at least not the main thing. Lean derives from the Toyota Production System (TPS), which in my research, although including cost cutting, it does so from the perspective of the cost contribution to product price. I think the cost cutting focus adopted in the U.S., which often means firing employees, is a big mistake. Many U.S. Six Sigma practicioners make the same mistake. Six Sigma is supposed to focus on reducing variation. Most of the time, you hear success claimed in terms of cost cutting. While cost cutting can be a desirable end result, focusing it as the only thing or the main thing misses the system nature of all management systems.

The horse's mouth in the case of TPS is Taiichi Ohno, who wrote in his book The Toyota Production System, "The starting concept of the Toyota production system was...a thorough elmination of waste". (p. xiv) The publisher's preface (1988) includes a statement made by Mr. Ohono that then TPS focus was, "All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes".

CCPM focuses on reducing the time line for projects. Thus, it is clearly a Lean activity in itself. In my opinion, it is the "low hanging fruit"...easily reducing time lines by one half or more. So we should continue to do that first.

Ohno also emphasized "pulling" work to fulfil customer orders. I think CCPM is a little way there with the idea of Pipelining, but not far enough. Future postings will address what both Lean and Six Sigma can bring to CCPM, to make it LPM.

CCPM Basics

2007-08-27T16:04:00.001-06:00

Hi, Everyone

Since I expect we will get people new to Critical Chain Project Management (CCPM) on this blog, I thought I would start with a brief overview of CCPM.

The following article was published in Chief Project Officer some time back, thus there is a bit of IT terminology. CCPM works for all kinds of projects, hardware, facilities, and software, project that are large and small, and projects that have a wide range of work types, from resarch through construction and maintenance and repair.

Critical Chain Project Management Accelerates the Project Pipeline

Lawrence P. Leach, PMP

Critical Chain Project Management (CCPM) is rapidly becoming the new standard for project success. Introduced in 1997 as a new approach to plan and execute projects “in half the time, all the time”, CCPM delivers unprecedented results for a wide variety of projects and organizations. Users of CCPM claim it simultaneously reduces project duration by 50% or more, increases the organization’s throughput of completed projects (by up to 100%), enhances project delivery success in terms of scope, cost, and schedule, (to nearly 100% success) and reduces the stress on project teams.

The System

CCPM combines key elements of the Project Management Body of Knowledge (PMBOK™), the Theory of Constraints (TOC), Six Sigma, and Lean production management to develop a comprehensive project delivery process, from project selection through project closeout. Identification of the critical chain, instead of the critical path, and buffer management are key discriminators of CCPM. The critical chain differs from the critical path by requiring resource loading and leveling before identifying the longest path through the project. The critical chain can jump logic paths in the schedule. A critical chain plan also includes buffers, a concept not usually associated with critical path.

Key elements from each of the synergistic perspectives used to design the CCPM project delivery system include:

PMBOK™: Scope definition and control, project time management.
TOC: Identify the constraint (for a single project, the critical chain, for multiple-projects, the drum resource (most overloaded resource across multiple projects), Exploit the constraint through eliminating dysfunctional behaviors and buffer management.
Six Sigma: Understand variation and psychology,

Lean: Pull of projects into the system based on the constraint, eliminate waste leading to task and project delay. CCPM synergizes with any approach to effective project management, from earned value to the agile or light project management techniques such as RAD, JAD, extreme programming, and possibly even SCRUM (although the extreme advocates of some techniques have difficulty identifying the synergy).

Management Behavior

Deploying CCPM requires changing key management behaviors that cause much of the waste in projects. Managers must encourage and reward using a system that operates to complete all of the projects in the portfolio faster by delaying the start of projects to meet the processing capability of the organization constraint. This deploys the Lean idea of pull to cause acceleration of all project completions. Management must take the lead to
Experience with deploying CCPM shows that changing the work habits of the task resources (from task switching to relay racer) is easy if management supports the change.

Planning and Control

CCPM requires real-time active project control because variation is real-time. Project task managers must update their tasks whenever they start a task, finish a task, and on a set frequency that does not exceed the average project task length. The project team then uses updated buffer reports to decide which tasks to focus on next, and to determine when and where to take action to recover buffer. Identifying the tasks causing buffer penetration pinpoints where to start the buffer recovery process, but buffer recovery can be planned for tasks down the chain from the task currently working. This provides proactive project control.

Senior management uses the multi-project fever chart to, at a glance, understand the status of a portfolio of projects, and know where to take action (projects in the red zone). They concentrate on assisting project teams to focus resources where they will do the most good for the portfolio. (Note: a project that completes with 100% buffer consumption is on time!)

Conclusion

CCPM achieves unprecedented results by changing the way managers and project resources behave. Project acceleration comes from focusing resources to work as relay-racers on the right project tasks. Enabling relay-racer task performance requires planning projects using the critical chain instead of the critical path, pipelining projects to the capability of an organization’s resource constraint, and measuring and controlling project performance using time buffers. Achieving this success requires some non-intuitive management behavior, such as not using project task completion dates, delaying the start of projects in order to accelerate completion, and adding time buffers to reduce overall project schedule time.

Initial Post

2007-08-27T15:52:00.000-06:00

Hi, Everyone

This is the first post to this blog.

My primary intention is to meet the needs of customers of Advanced Projects, Inc., and others interested in deploying Critical Chain Project Management (CCPM). I am also very interested in helping all workers, including managers, by fostering the continuous improvement of all management improvement theories, with emphasis on the Theory of Constraints, the Project Management Body of Knowledge, Six Sigma, and Lean.

To that end, some initial topic threads come to mind, such as the following. Good practices for;
1. Implementing organizational change.
2. Project delivery system design and continuous improvement.
3. Project delivery system measurement and control (operation).
4. Project modeling practices.
5. Using Advanced Projects, Inc. products.
6. FAQs.
7. Questions for me.
I will seek to start these and others over time. I welcome your suggestions.

Regards,
Larry Leach