Claude Emond is one of the founders and president of Qualiscope Enterprises, a project management consulting, coaching and training firm based in Montreal, Canada. He has degrees in chemical engineering from Canada's Royal Military College (BEng) and Montreal McGill University (MEng), a MBA from Ottawa University, workshop leadership training from Le Centre Quebecois de la PNL, and is a certified PMP. He has over 25 years experience managing major public and private projects. He teaches project risk management in the Schulich School of Business Master certificate in project management and the PMP certification revision class for PMI, Montreal He is one of the authors of the current PMI Standards for Portfolio Management. Claude can be reached at This is the fourth and final part of my little series on the rules of Lean Project Management. I wanted to write another on multitasking. But, as for any project, this little series impacted my thinking and my expectations as it evolved. I finally realized that I had outlined the essentials on the foundations of lean project management, other subjects being of a more technical than philosophical nature. Since the intention was to deliver fundamental messages, I just found along the way that the essential deliverables were there and any new one, except a final wrap-up, would add little value at the level of discussion sought.
Lauri Koskela in his landmark article, The underlying theory of project management is obsolete (http://www.leanconstruction.org/pdf/ObsoleteTheory.pdf) says that the current theory of project management, as illustrated in the PMBoK, mostly defines project work as planning; not much is revealed with respect to work as executing. Projects are executed through people....and it just seems we do not know how to communicate this.
In the current theory, much emphasis is given to tools and best practices», what I call the know how to do. By the same token, when we talk about the so-called human skills (apparently these are soft), what I call the know how to be, we only pay lip service to them. This situation is confirmed and dramatized by the findings of Frederic Rodriguez, in his master degree thesis, Are the required best behaviours integrated in project management maturity models? (CESI, Aix-en-Provence, fall 2008 – my translation of the title into English). He found out that only 13 % of the points measured in OPM3 (76 out of the 589 best practices identified in the maturity model) had any link with managing or fostering proper human behaviours. So the answer to Frederic’s question and the conclusion of his thesis is NO!
I know that OPM3 is into its first revision and that there is a big international effort to develop a universal standard on project management (PMI, AFITEP, IPMA and the like all working together on this); I sincerely hope that more consideration will be given to the main resources in projects - humans.
Meanwhile, lean project management principles can really help us in this ill-covered area, as it mainly concerns itself with executing work through humans. Just look at the three rules I laid out previously:
- Rule 1 – The Last Planner rule - The one who executes the work is the one who plans the work: Expanding the project team means more last planners, the ultimate ones being those who have to materialise the project benefits once the project delivered what it had to. HUMANS PLAN AND EXECUTE PROJECTS
- Rule 2 – The Track Promises rule - Do not track time (effort) or cost. Track small promises that you can see over time: Expanding the project team means getting each promise made by the last planner who has a stake in it, and can really make it happen. HUMANS ARE THE SOURCE OF PROMISES AND RESULTS
- Rule 3 – The Expanded Project team rule - Expand the project team to include and integrate all significant stakeholders as part of the team as early as possible.
- HUMANS AROUND PROJECTS ARE MANY AND NEED TO BE ALIGNED TOGETHER THROUGH A SHARED VISION
Many people oppose PMBoK contents to lean project management approaches. I do not believe this is the proper way to look at this. Their focus is different, one promoting mainly best practices, the other calling for best behaviours. These are not opposed; they are two important parts of the same puzzle; they complement each other. However, until we merge them together to propose a better, more complete vision on managing projects successfully, I will continue to extensively promote lean project management and its fundamental proposition, spelt out here in its fourth and ultimate rule, a cry from the heart:
Rule No. 4 of LPM - Humans, Humans, Humans:
- Humans execute projects.
- Projects’ deliverables materialize through humans and for them.
- So be considerate to humans as, without them, no project can be a success.
Hits: 1105
Comments (8)
Subscribe to this comment's feed
written by galleman, November 10, 2008
Claude,
Care must be taken for Koskela paper. It is a critisim of PMBOK in the context of construction. The PMBOK for Construction and the PMI College of Scheduling (heavy construction focus) both address the issues Koskela brings up in what is now an "aging" paper.
Koskela also mistake themorstatic control for "feedback." Koskela's conjecture that feedback is too sloe, needs to be repalced with an understadnign that PMBOK does not specify the period for the feedback. Agile increases this feedback to 2 to 4 weeks. Nany large government contracts restrict this period to not more than one acounting period (45 days).
Applying directly Koskela's paper to software development is a popular but sporty business.
Care must be taken for Koskela paper. It is a critisim of PMBOK in the context of construction. The PMBOK for Construction and the PMI College of Scheduling (heavy construction focus) both address the issues Koskela brings up in what is now an "aging" paper.
Koskela also mistake themorstatic control for "feedback." Koskela's conjecture that feedback is too sloe, needs to be repalced with an understadnign that PMBOK does not specify the period for the feedback. Agile increases this feedback to 2 to 4 weeks. Nany large government contracts restrict this period to not more than one acounting period (45 days).
Applying directly Koskela's paper to software development is a popular but sporty business.
-
- +0
-
-
written by galleman, November 10, 2008
Asirota,
The notion of project management and software development management need to be clarified. Large unwieldy projects are the "norm" in many domains. The conjecture that they rarely lead to success needs a context. Defense, Space, Nuclear Power, Pulp and Paper, Petrochemicals. All successfull efforts in this field have professional planning activities.
To conjecture that more planners means more plans, without a context and a business domain, reinforces the notion that software development is not the same as project management.
PMBOK's role is not the define the engineering processes "managed" by project managers. Such process are domain and context sensitive. Agile software development (mis-named Agile Project Management) is one such engineering process. IMP/IMS in defense, and Prince2 in the UK are others.
Glen B. Alleman
VP, Program Planning and Controls
Aerospace & Defense
Denver, Colorado.
The notion of project management and software development management need to be clarified. Large unwieldy projects are the "norm" in many domains. The conjecture that they rarely lead to success needs a context. Defense, Space, Nuclear Power, Pulp and Paper, Petrochemicals. All successfull efforts in this field have professional planning activities.
To conjecture that more planners means more plans, without a context and a business domain, reinforces the notion that software development is not the same as project management.
PMBOK's role is not the define the engineering processes "managed" by project managers. Such process are domain and context sensitive. Agile software development (mis-named Agile Project Management) is one such engineering process. IMP/IMS in defense, and Prince2 in the UK are others.
Glen B. Alleman
VP, Program Planning and Controls
Aerospace & Defense
Denver, Colorado.
-
- +0
-
-
written by asirota, November 12, 2008
Glen,
Alex here. I recognize that there have been large projects successfully implemented with professional planning activities. I am not saying that we need to remove planning. What I am saying is that the way we do planning now needs to change. The notion that projects can have 3-5 year timelines -- that time has passed. There are too many unknowns changing, too rapidly for projects to have such lofty ideals.
In fact, it is projects that are developed iteratively, with constant feedback from external and internal forces that do well, no matter what domain they are in. It would be interesting to inspect projects like the Apollo missions, the iteration rates and other "agile" type of practices to compare them to longer planning cycles with less iteration.
I think you may misunderstand what the agile approach is -- it's not an engineering process at all. It's simply a way of thinking and organizing a team, and in many ways a culture change from top down hierarchical, 20th century ways of doing things. One of the interesting developments in agile is the exploration of the application of these approaches to domains other than software development.
Agile works netter within empirical contexts, rather than more defined contexts like construction and building (domains which you describe in your document).
Design in the pharma industry is one of the apocryphal stories where "agile" comes from according to the Ken Schwaber book (3M -> Fidelity Investments knowledge transfer).
Thanks for the discussion!
Alex here. I recognize that there have been large projects successfully implemented with professional planning activities. I am not saying that we need to remove planning. What I am saying is that the way we do planning now needs to change. The notion that projects can have 3-5 year timelines -- that time has passed. There are too many unknowns changing, too rapidly for projects to have such lofty ideals.
In fact, it is projects that are developed iteratively, with constant feedback from external and internal forces that do well, no matter what domain they are in. It would be interesting to inspect projects like the Apollo missions, the iteration rates and other "agile" type of practices to compare them to longer planning cycles with less iteration.
I think you may misunderstand what the agile approach is -- it's not an engineering process at all. It's simply a way of thinking and organizing a team, and in many ways a culture change from top down hierarchical, 20th century ways of doing things. One of the interesting developments in agile is the exploration of the application of these approaches to domains other than software development.
Agile works netter within empirical contexts, rather than more defined contexts like construction and building (domains which you describe in your document).
Design in the pharma industry is one of the apocryphal stories where "agile" comes from according to the Ken Schwaber book (3M -> Fidelity Investments knowledge transfer).
Thanks for the discussion!
-
- +0
-
-
written by galleman, November 12, 2008
Alex,
You'll need to bound the domain and context here. 3 to 5 years is about right for rolling out SAP across an moderate to large enterprise - 25 to 50 sites. 3 to 5 years is the standard duration for an interstate highway project. 7 years is a fast duration for a large aircraft or spacecraft program.
And BTW, itertive and incremental are embedded in those projects as part of the standard DoD development process.
When you generalize about project management (XP and Scrum are software development methods), establishing a domain and context is helpful to the reader.
I am famailar with agile software developing, having introduced XP on a large Department of Energy program here in Colorado, ~$100M/year IT budget. But the road is littered with "dead" agile projects, executed poorly, with little understanding of the business, process, and product engineering issues outside the team of programmers sitting in the same room with their customer.
As well, the firm I work for staffs the Planning and Controls team for the next manned spacecraft's avionics system. A read of the Apollo history - at the NASA oral history site - reveals much about the myth of emergent planning used there. When you here the participants speak about the lunar program - in person, http://herdingcats.typepad.com...amous.html - much of the myth around long-ago projects is removed.
CONTEXT, DOMAIN are crtically important to the success of any project management method. More so for agile software development.
You'll need to bound the domain and context here. 3 to 5 years is about right for rolling out SAP across an moderate to large enterprise - 25 to 50 sites. 3 to 5 years is the standard duration for an interstate highway project. 7 years is a fast duration for a large aircraft or spacecraft program.
And BTW, itertive and incremental are embedded in those projects as part of the standard DoD development process.
When you generalize about project management (XP and Scrum are software development methods), establishing a domain and context is helpful to the reader.
I am famailar with agile software developing, having introduced XP on a large Department of Energy program here in Colorado, ~$100M/year IT budget. But the road is littered with "dead" agile projects, executed poorly, with little understanding of the business, process, and product engineering issues outside the team of programmers sitting in the same room with their customer.
As well, the firm I work for staffs the Planning and Controls team for the next manned spacecraft's avionics system. A read of the Apollo history - at the NASA oral history site - reveals much about the myth of emergent planning used there. When you here the participants speak about the lunar program - in person, http://herdingcats.typepad.com...amous.html - much of the myth around long-ago projects is removed.
CONTEXT, DOMAIN are crtically important to the success of any project management method. More so for agile software development.
-
- +0
-
-
written by asirota, November 12, 2008
As with anything there is a normal evolution -- agile is not a silver bullet by any means, I am not purporting that it is. But I believe the idea of the $50-$100M dollar budgets for IT departments is over. I think IT projects will rest more in the domain of $100-$200k per year for multiple years. We can do a lot more with a lot less, so I wonder what will happen in other domains.
Interesting article on NASA -- I will definitely take a look and read up. I just saw the NASA Missions documentary and it struck me how quickly they were able to send repeated Apollo missions to get to the moon. It sounded very adaptive, so the people behind it know their stuff -- for real. We can only learn from them.
Interesting article on NASA -- I will definitely take a look and read up. I just saw the NASA Missions documentary and it struck me how quickly they were able to send repeated Apollo missions to get to the moon. It sounded very adaptive, so the people behind it know their stuff -- for real. We can only learn from them.
-
- +0
-
-
written by galleman, November 12, 2008
Asirota,
Good discussion points...
The $100K to 200K projects represent a single person year burdened to maybe 1 1/2 person years burdened. To stand up a Sharepoint server and the support contracts for right of way is $2M. So I puzzled how $100/200K is going to provide much incremental value at the enterprise level.
If you invert th discussion, leveraging $2-50M projects by 10% improvements (cost overrum avoidance for example but controlling the sunk cost of the work), seems to be a better approach than improving 10% to 20% of a $100K project.
The primary benefit to the organization of "thinking" agile (not to the individual developers), is to make visible the incremental project performance progress.
Here in our defense and space world, we ask the question all the time ... "how long are you willing to wait to find out you're late?"
This is the primary outcome of "agile" project management - if there is in fact a practice that is seperate from coding.
Good discussion points...
The $100K to 200K projects represent a single person year burdened to maybe 1 1/2 person years burdened. To stand up a Sharepoint server and the support contracts for right of way is $2M. So I puzzled how $100/200K is going to provide much incremental value at the enterprise level.
If you invert th discussion, leveraging $2-50M projects by 10% improvements (cost overrum avoidance for example but controlling the sunk cost of the work), seems to be a better approach than improving 10% to 20% of a $100K project.
The primary benefit to the organization of "thinking" agile (not to the individual developers), is to make visible the incremental project performance progress.
Here in our defense and space world, we ask the question all the time ... "how long are you willing to wait to find out you're late?"
This is the primary outcome of "agile" project management - if there is in fact a practice that is seperate from coding.
-
- +0
-
-
written by claudeemond, November 16, 2008
Just a little note about what I write here and what I try to do sharing my ponderings on PM.
WRT Agile not being mentioned. In terms of concepts, I do not make any difference between Agile and Lean and I said so before in other posts. I have no intention of reinventing the wheel, just working with many others to have it at least rolling. As was said in the comments above, not much is said in PMI (yet...I know it is coming)and the PMBoK about Agile or Lean...As for talking «methodologies», be it Agile or others, I stay away from those. I find it particularly disturbing actually that something is called «Agile methodologies» when Agile states that each project has its own and...it does not always require to be using agile approaches !!
Many of Glenn comments talk about saying things out of the right project context. I cannot agree more. I cannot agree more too to Alex saying that Agile is not THE silver bullet....There is no silver bullet, there will never be one. Project management is contextual and pushing for one methodology versus another all across the board is not a very wise idea.
However, looking around and picking up good ideas from other domains of work and trying those in our context...this I believe is a good idea. And my postings in this blog are all about that, talking about possible good ideas and asking people to consider them (maybe) next time they look at their projects and at what can improve their delivery. I expouse no project management school of thought, I just listen to all of them and make up my mind with my collaborators on what might work in our particular context. I believe we should stop «egotripping» about who is right and who is wrong and just work together with our individual differences to better the field, as good high-performing project teams do.
WRT Agile not being mentioned. In terms of concepts, I do not make any difference between Agile and Lean and I said so before in other posts. I have no intention of reinventing the wheel, just working with many others to have it at least rolling. As was said in the comments above, not much is said in PMI (yet...I know it is coming)and the PMBoK about Agile or Lean...As for talking «methodologies», be it Agile or others, I stay away from those. I find it particularly disturbing actually that something is called «Agile methodologies» when Agile states that each project has its own and...it does not always require to be using agile approaches !!
Many of Glenn comments talk about saying things out of the right project context. I cannot agree more. I cannot agree more too to Alex saying that Agile is not THE silver bullet....There is no silver bullet, there will never be one. Project management is contextual and pushing for one methodology versus another all across the board is not a very wise idea.
However, looking around and picking up good ideas from other domains of work and trying those in our context...this I believe is a good idea. And my postings in this blog are all about that, talking about possible good ideas and asking people to consider them (maybe) next time they look at their projects and at what can improve their delivery. I expouse no project management school of thought, I just listen to all of them and make up my mind with my collaborators on what might work in our particular context. I believe we should stop «egotripping» about who is right and who is wrong and just work together with our individual differences to better the field, as good high-performing project teams do.
-
- +0
-
-
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
Click Here to login or create a free account.
Click Here to login or create a free account.
I find it interesting that there is so much egotism in the Project Management space, as if each PM finds their own "aha" moment and starts to realize that big unwieldy projects rarely lead to success and that adding more "planners" only leads to more "plans" rather than work being done.
The topic of Lean PM is a worthy one -- but we need to stop talking and actually find new ways of reinventing PMBoK to support these techniques and modernize the PMBoK. Many organizations have adopted the PMBoK as a bible and make their own versions of the PMBoK. Of course they omit agile/lean because the PMBoK does not contain any worthy discussion of well defined agile/lean principles as far as I know.