AddThis Social Bookmark Button

The Rules of Lean Project Management: Part 3

The Expanded Project Team

I am back from my journey to South East Asia. It is time to resume my little series on the rules of Lean Project Management. This third entry will discuss the nature of the project team and its composition. It is an invitation to expand the boundaries of a project team to include all project stakeholders. It is of course linked to the proper execution of the two other rules already discussed:

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 this project has delivered what it was intended to.

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.

The current edition of the PMBoK still makes a difference between:

  • The “project team.” Those directly involved in the realisation of the project deliverables (the issues and management of this team being treated in Project HR management), and
  • The “project stakeholders.” Those affected by or able to effect the realisation of these deliverables (the issues and management of these “separate” groups being treated in Project Communication Management).

And the new version of the PMBoK, coming out soon, continues to support this paradigm. This way of discriminating among project players is one of the reasons for our low project success rates (29 %), as documented by the CHAOS Report. Merging those two groups into one, the expanded (or integrated) project team, is one of the main explanations for the high project success rates (85%) documented in the British Constructing Excellence program, mentioned before in other blog entries.

I have a very fresh example in memory to illustrate the need to change the conventional view on who is and who is not on a project team. During a project management maturity diagnosis I was making with a customer (a highly innovative manufacturing enterprise), I met the manager responsible for after sale customer service. He told me of his last experience with the introduction of a new product. Since he has nothing to do directly with delivering the new product for production, the main objective of their new product development projects, he was not considered part of the project team. He came across some technical documentation on the new product just before it went to pre-production, only to realise then that the product included the very same component that was causing 90 % of his customer complaints about a similar product already in full scale production and on sale. These complaints were resulting in major on site service costs and loss of recurrent customers.

He immediately went to the CEO and had the pre-production phase stopped right there. The project team» had to go back to the drawing board, with an expensive prototype in the garbage bin and much rework to do in the very small time left to seize the window of opportunity for this new product. This mess would have been avoided very easily if this very important last planner had been integrated to the project team at the very start of its definition.

If you think that you must restrict the number of people in a project to those only involved in the direct realisation of deliverables, I hope that the little tale of disaster I just presented will have you refine your “need to know” and project team definition to include - as early as required - those who have to materialise the ROI on this project.

So LPM rule No. 3 is: “Expand the project team to include and integrate all significant stakeholders as part of the team as early as possible”.

Comments (1)Add Comment
Sharon Willson
...
written by swillson, November 10, 2008
While I completely agree with bullet 1, and somewhat agree with bullet 2, I have found that bullet 3, while helpful in some situations generally causes a lot of bloat in the amount of time spent on a project by the collective team due to meetings, etc. It can be helpful to ensure that wires don't get crossed, I completely agree, but doing it in such a way as to have people maximize their productivity would be very important.
At this point, we are trying to be more lean in terms of the number of people on our projects - just ensuring that they are the right people.

Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.

busy

Project Management Articles

In-depth project management articles and the latest news from around the world.

Project Management Blogs

Leading PMP experts share their thoughts on latest trends and issues in the world of project management.

Project Management Webinars and Training

PMI PDU Online Training by Profesional PM leaders on educational topical subjects

Project Management Books

Complete library of all the latest and greatest project management books

Project Management Whitepapers

Download free project management whitepapers.

Project Management Software

Comprehensive directory of project management software including requirements management tools and software