Own a system for all time your Cash Loan Company Cash Loan Company faxless hour online website.

Rules of Lean Project Management

by Hal on November 9, 2008

in Last Planner, lean, project control, project planning, project scheduling

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Claude Emonde writes the weblog Surviving the Project Age at Project Times. He recently finished a four-part series on the Rules of Lean Project Management. Overall, he did a good job. Those of us who developed and teach the lean project approach don't refer to these ideas as rules. For us, we tend to think about principles. But, Claude has done a good job.

Make your choices and commitments at the last responsible moment.

Let's take a look at Claude's four rules.

  1. The Last Planner® rule:1 The one who executes the work is the one who plans the work
  2. Track promises rule: Track small promises that you can see over time
  3. Expand the project team rule: Expand the project team to include and integrate all significant stakeholders as part of the team as early as possible.
  4. Humans, Humans, Humans… be considerate to humans as, without them, no project can be a success.

Claude left out a few important ideas. The first is to make your choices and commitments at the last responsible moment. We've noticed a habit on projects to lock down requirements early, to get material on order early, to grab resources early. These steps rarely help and usually adds waste to the project. Further, we lose options when we act early.

Large batch production misses the opportunity for learning, creates the circumstances for waste, and delays the completion of the project.

The second is to PDCA everything. Much has been made of the tools, techniques and methods of lean ways of working. But behind it all is Deming's (Shewhart's) Plan – Do – Check – Adjust cycle. It's the embodiment of the scientific method. No company does it better than Toyota. Make it your habit.

The third has to do with batch size of one or single-piece flow. Large batch production, whether it's placing concrete, writing software code, doing design, or performing administrative work misses the opportunity for learning, creates the circumstances for waste, and delays the completion of the project. Couple Claude's four rules with these three ideas and you have the basis for doing projects lean.

  1. The Last Planner is a registered trademark of the Lean Construction Institute. [ ⇑ back ]

{ 12 comments… read them below or add one }

1 Claude Emond November 10, 2008 at 5:53 am

Hello Hal. Thanks for the post and your comments about a few missing elements, the three of them I also believe in and apply. I will revisit the «rules» to include those. :)
I had the intention to eventually summit them to you for your blog, but was not sure yu would agree with my simplifications. Seems I have done and acceptable job, so I am very pleased for your comments here.

Best wishes


2 Glen B. Alleman November 10, 2008 at 10:55 am

Hal and Claude
Care must be taken for Koskela paper. It is a criticism of PMBoK in the context of construction, with specific assumptions that are incorrect in some instances. While PMI likely overstepped its capabilities when claiming Project Management is a profession, Koslela then amplified this to mean there must be a theoretical basis of project management as his thesis. This approach is likely seriously flawed, since the conjecture of a profession by PMI is itself flawed. All could have ended there, but Koskela continued on (as do several critics of PMI) to expound on this “house of sand.” Too bad, since there are useful elements of PMBoK that have no need to be “tossed out with the bathwater.”
One flawed Koskela approach is the rewriting of PMBoK’s description of projects to a “production” point of view. Once that has occurred, Koskela argues that PMBoK is not appropriate. This is circular logic at best and a tautology at worse.
While there are legitimate criticisms of PMBoK 3rd edition, the PMBoK for Construction and the PMI College of Scheduling Guidebook (heavy construction focus) address some issues Koskela brings up in what is now an “aging” paper.
A second is Koskela’s use of the thermostatic control analogy for “feedback.” This control loop algorithm is a simple but effective approach to controlling an “on/off” process. Koskela wants us to accept that PMBoK suggest a thermostatic approach is recommended. This is simply not the case, but Koskela continues to argue the failings of this non-recommended approach.
In fact Chapter 6 of PMBoK 3rd edition has four activities in Schedule Control: 1) Determining the current status of the project schedule, 2) Influencing the factors that create schedule changes, 3) Determining that the projects schedule has changed, and 4) Managing the actual changes as they occur. PMBoK 3rd edition states (in the context of how the Process Groups interact) “The Monitoring and Controlling Process Group must provide feedback to implement corrective actions to bring the project into compliance with the project management plan or to appropriately modify the project management plan.” Feedback is required and stated as such in numerous locations in PMBoK 3rd Edition.
These, like all PMBoK elements, are activities that should to be performed during the management of a project. “How” they are performed is left to the execution side of project management.
Koskela’s conjecture that the sampling period for feedback is poorly defined in PMBoK is correct. This needs to be replaced with an understanding that PMBoK does not specify the sampling period for the feedback – just that “control” is needed. While the criticism may be appropriate, the term “obsolete” is likely overstated. A simple survey of any control system book reveals many algorithms for fine grained control appropriate for project management. Even feed forward algorithms like “earned schedule” and Monte Carlo Simulation based analysis tools. And since PMBoK does not specify the algorithm, substituting one of those solves the problem without using the term obsolete.
As we all know Agile defines this feedback in 2 to 4 week intervals, and in some instances feedback is provided daily in XP shops for software development. Many large government contractors define the feedback period to not more than one accounting period (45 days). For alternative guidance beyond PMBoK in Defense, look to DID81650, DFAR, DOD PMBoK, Part 2.B.3 of DoD Acquisition Strategy, DFARS 252.242-7001 and other for specific “execution” instructions from DOD in the Acquisition Guide.
Applying directly Koskela’s paper to software development is a popular but sporty business. As well, care must be taken in applying PMBoK to the “production” phase of a project, especially in construction. Execution in construction is not execution in software or execution in operations of a manned space flight mission or even the avionics systems for the spacecraft. I am deeply familiar with all of these domains and it would be dangerous to apply PMBoK in the absence of experience or consideration of the actual activities on the project. PMBoK is “A” guide and even then an introductory guide. But obsolete? Koskela’s thesis is unsubstantiated at best and a thinly disguised sales tool for Last Planner at worse. Not a problem; everyone has to make a living But using Koskela as a reference academic paper – as has become popular in the agile community – is troubling for those like me with a academic background.
No one in Defense sees the role of PMBoK to state HOW to execute the project – although increased advice would be helpful at times. Nor do they see it as “obsolete,” – just a starting point – possibly naïve at times. Adding value to PMBoK is the result in DoD PMBoK.
The sport of PMBoK and PMI bashing seems to be unique to Agile. It is time to mature Agile execution and ask how to increase the probability of success (P(s) is an official notion in defense program management), and build on the foundation of the Knowledge Areas and Process Groups – all of which should (must) be present in some form for project success.

3 Hal November 10, 2008 at 5:18 pm

C’mon Glenn,

You are going after something that is incidental to the points Claude was making. Lauri Koskela and Greg Howell neither attacked the PMI nor the PMBoK. Their work was about theory. There’s a very good reason to look at theory that has nothing to do with its relevance to a profession. Knowing the theory has allowed the human race to do some amazing things. Operating from invalid and incomplete theories has resulted in failures. Lauri and Greg investigated the situation where standard practice was not getting reliably successful projects. Their paper explained what they found in investigation. I wrote a series of postings examining and elaborating on their paper. You’ll find the compilation of those postings Notes on Obsolete Theory.

4 Claude Emond November 10, 2008 at 9:43 pm

I do not really understand what is going on here ! Projecttimes is a blog managed by people actually very close to PMI and they like getting a little controversy once in a while. Questioning oneself and one’s own paradigms is fundamental to one’s evolution and alignment to changing environments. Asking questions and confronting paradigms is not bashing, it is conversing and exchanging. So this is what I do here, in Projecttimes, on other platforms and with every single workshop participant and manager who I meet.

I do not consider anything as a «complete truth» be it written in the PMBoK or, even more, said by me. I know I have to evolve in my thinking and I know of many people associated to PMI who believe the same. PMBoK, as anything based on paradigms, is subject to questioning as it passes through time and will evolve to better contents as project management knowledge and skills are chalenged by more and more new attempts at materializing benefits from projects. The same can be said of Agile or Lean as they are applied today. None of these are religions and will not last if they are applied in bling faith, without any questioning.

One of the most significant book I read was a reading Greg Howell recommanded to me: The Structure of Scientific Revolutions by Thomas Kuhn. I believe it is required reading for anyone interested to understand why today’s paradigms will have to move aside for better ones, more aligned with reality as we discover how it really works. PMBoK as it is today is not the final word on project management; it is and will remain a work in progress (4th edition coming soon and not the last…) and if ever it becomes a «final edition», it will have engineered its own demise. So can we discuss PM evolution or not ?

And frankly, I really do not think Koskela article is a marketing stunt for the Last Planner. It tells you to question things and look at multiple perspectives, a very wise cautionary tale as I see it. I think it is a fine piece of reflective work and I will continue to encourage people to read it.

5 Glen B. Alleman November 12, 2008 at 11:02 am

The papers clearly state – PMI considers PM a profession, therefore there must be a theory, the theory is obsolete (PMI’s PMBoK), we have a better one. QED.
If that ain’t critisim of PMI and PMBoK , I don’t know what is.
Maybe you’re too close to them. From a distance. It’s seen as critism with several flaws in logic. Feedback from the field, that’s all.

6 Glen B. Alleman November 12, 2008 at 11:10 am

The Howell et al, have made several errors in their approach. (1) That the observed behaviours of malfunctioning projects are casued by a flawed theory. A theory that they conjecture shoudl exist, since PMI considers PM a Professional. (2) The methods used in their observed subjects were “good” practive – they were not. Deterministic scheduling, thermostatic control, etc. are bad practics, in no place sugegsted by PMBoK.
The papers are used by the agile commuity as examples of what is wring with PMBoK and by implication PMI.
So if there is a challange to be taken it is the underlying thesis of Howell et al, that there is actually a theory of PM and this theory is obsolete. The conjecture is ad hoc, with little or no basis.
In the end PM is NOT a profession in the way of Law or Medicine. It is a practice in the way of, air conditioner repair, and fine cabinet making, or software development (programming). Skill, experience, creativity, adaption to emerging knowledge, fundamental “laws” of materials (cost, schedule and technical performance are inseperable is one principle). But a profession like Law, no.

7 Glen B. Alleman November 12, 2008 at 11:18 am

When standard practice does not get reliable results one of two things is possible. But first a baseline is needed. If the standard practice is observed TO get relaible results in other sites – that’s called a control experiment – and must be used as a statistical comparison. How many observations were made? Was this enough to draw any inference conclusion – the theory is obsolete is one.
Then one of two outcomes are possible, (1) the practice is not effective, or (2) the application of practice is not effective. Possible some combination is in place, but that’s a difficult call to make with small sample statistics.
This is the core problem with anecdotal observations – no control group means no inferences to a larger population or a larger change process.
In the end, it’s irrelavant becasue the market place sorts this out.
I was just ranting on a rainy weekend. Sorry for the disruption.

8 Hal November 12, 2008 at 6:54 pm

I hesitate to continue with the conversation. But I have to let people know the conclusion that Lauri and Greg reached in their paper, in case readers don’t take the time to read this 6 year-old paper.

They said, “(i)t is the poverty of current theory that explains the other problems of project management, such as frequent project failures, lack of commitment towards project management methods and slow rate of methodological renewal. Thus an explicit theory is the crucial and single most important issue for the future of the project management profession.”

In spite of Glenn’s comments to the contrary, investigating theory isn’t the same as taking shots at PMI and the PMBoK. Both have advanced tremendously in the last six years. And with membership now over 400,000 people are voting with their wallets in support of the direction PMI is taking.

9 Claude Emond November 14, 2008 at 7:42 am

I agree PMI and many other organizations, involved with fostering better project management practices…AND BEHAVIOR, are evolving towards a better understanding of these «highly context-driven» processes. There is a huge effort right now internationally (PMI, IPMA, AFITEP, APM, etc) to get a good standard for project management that shall remain, really on the «guidance» and governance level, not much more.

I consider some stuff in the PMBoK universal and genial: the open-close recurring process (that is also used more frequently in Agile in the form of timeboxing and scrum, and in Lean in the form of promisses completed), its definition of success (meeting the expectations of ALL stakeholders) and its definition of quality (quality = quality of the destination + quality of the journey). I always use and teach those ensuring that at least the open-close processes cover the 9 knowledge areas identified in PMBoK plus a 10th one which is not very well covered in the current version (but will be for sure one day): change management. For the rest, depending on the volunteers who worked on a new edition, I take with a grain of salt, since i smell of a specific context (Edition 3 smells like IT stuff, while edition 2 and 1 were smellin more like engineering-construction stuff).

PMI is a very strong, powerful organization. I teach in France and it is becoming very present, although I believe the approaches proposed are culturally biased (more north-american than anything else) and will have a hard time making their places in the highly hierarchical French organizational culture. I find the treatment of Best behaviors is really missing in PMI standards (I had a master degree French student counting, for his thesis on the behaviors to foster in PM, the number of elements in OPM3 that related to behaviors and he fond only 11% of the 570 or so «measurable» elements of porject maturity were concerned with behaviors. For this reason, I find IPMA model of good project management (three axes: best practices, best behaviors and context-driven) more balanced and more transferable from on cultural context to another.

The high focus Lean and Agile give to human aspects, perceptions and behaviors is the main reason I push for those practices. I believe all those approaches show complementarity and I am just feeling sorry that the dabate between Agile or Lean and so-called «traditional» PMI aprroach very often sounds like a religious war fostered by strong egos. I do not believe any single paradigm is the right answer and I find it more constructive to try to combine their respective strengths when possible than trying to discredit one or another pointing only at flaws (real or imaginary).

I find this exchange between Glenn and Hal very interesting. I just hope that so-called bashing will stop being reacted to by counter bashing. There are great minds on all «religious sides» of PM. All we have to do is just converse and grow together in our search for better project management

10 David Green November 16, 2008 at 9:36 pm

One of the reasons for project failure in my experience is not so much the machinery of the project, or the particulars of the management approach (and I’m a keen ‘lean’ proponent), but the lack of informed organisational commitment. This shows itself in areas such as not providing resources, not recognising prior allocations of people to the project (ie stealth multi-taking occurs), and not communicating expectations, or accepting advice from the project team. In an implementation of an ERP I was involved in for a government agency, one of the problems was refusal to change a decision when advised that the ERP was the wrong system to use for project management (ironically). This represented a requirements-capability mis match that has lead to project ‘failure’.

11 Claude Emond November 20, 2008 at 7:55 am

very interesting example of disfunctional decision making David. As usual, the key to resolving this issue lies in managing perceptions and meeting expectations through aligning interests. Obviously, there were non congruent interests among the different project stakeholders, which led to not taking proper decisions, which resulted in project failure. very sad !

12 Claude Emond July 17, 2013 at 6:56 am

Hello Hal.

I just came back here – http://www.reformingprojectmanagement.com/2008/11/09/883/ – by «fate» (I was refering to this blog entry in my white paper on the Rules of Lean Project Management – http://www.qualiscope.ca/LPMRules_CEmond.pdf -and just checking the web links I had in there). Very interesting comments here. Fight of the century :) . 5 years later, I believe time has proved some of what we say here right :) . So we were not doing so bad then.

Not sure you come back here. Just taking a chance and take this occasion to say to you how much I loved our discussions then. I hope you are doing fine

My very best regards


Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Note: This post is over 5 years old. You may want to check later in this blog to see if there is new information relevant to your comment.

Spam Protection by WP-SpamFree

Previous post: Myth of Multitasking

Next post: Out with Deterministic Project Planning