Skip to main content

Author: Claude Emond

Managing and Surviving Imposed and Unrealistic Time Estimates

Written by Claude Emond on . Posted in Articles. 7 Comments on Managing and Surviving Imposed and Unrealistic Time Estimates

I am sure you have never been forced to accept and include in your project schedule unrealistic data, most likely resulting from your project sponsor or your boss making a promise on a target end date. Never? Right!

Well, we all know that this happens all the time, the result being that:

  • In most surveys on project management, many project managers and teams complain that they work on unrealistic schedules
  • The same project managers and teams are still being blamed for not meeting those dates
  • Sponsors, bosses and organisations do not seem to be learning anything from this and
  • The same pattern goes on again and again, unresolved.

I tell my workshop participants and the project managers I coach that they should stop complaining about unrealistic schedules and do something about it. I am still appalled at project managers accepting to meet dates that do not make sense, or try to meet them without discussing the affect on cost (fast tracks cost more) or on quality. Eventually they end up having to play the role of scapegoat on a sinking project because they failed to challenge their sponsor, boss or other power, when they applied their magic thinking on these projects.

It is a fact that sponsors and bosses are here to make things happen, and the faster the better. And this is quite alright. It is also a fact that many of them just do not have a clue about what they are asking you to achieve. When I tell project managers that their sponsors or client very often do not understand the conditions required the meet the dates they “force” on them, some are quite surprised. I ask them them why upper management sets such unrealistic goals…do they really think their bosses are that stupid?

Unless project managers present the facts and stop accepting unrealistic dates without conditions, they will not do an effective job of helping their management better understand the nature of the projects in question. When they do understand the situation, they will hopefully provide adequate resources and timeframes. Who’s stupid? The one asking for results or the one not explaining the conditions required and complaining delays are unrealistic…after accepting this situation by default?

Here is an example of such a situation and how a project manager can help the project sponsor or client become a better project stakeholder and supporter. During a recent coaching session, a project manager told me that he was working on a new project involving the development of new injection molded plastic components. They had worked on similar projects for many years and testing and adjustments on the new molds always took between two to five weeks before going into production because of the sheer complexity of this piece of equipment. The project sponsor provided a project end date that did not really make sense, particularly because of this historical constraint. The sponsor was told that the only way the schedule could be met was if the testing and adjustments could be completed in a week, something not achievable for this type of mold. The sponsor went into “magical thinking mode” and told the project manager that, he felt that the testing and adjustment it would go extremely well and that the one week time frame would work.

So what could the project manager do? I told him he had of course to go along with the unrealistic end date….but to make sure he documented in the project charter the fact that this date was based on the sponsor’s assumption of a one-week testing and adjustment period for the new mold. Then once the mold has been tested and the adjustments required to make it work were finally known, I told the project manager that he would have to return to the sponsor with the charter and get his new estimate for the mold adjustments, so that it can be documented again. I told the project manager that his sponsor would learn something important. Among other things, he has to accept ownership for imposed unrealistic delays (and that he will, because he is not an unreasonable person) and that he better leave things he doesn’t know about to those who do..

Many project managers react strongly when I talk about challenging their sponsors and clients on obviously unrealistic imposed project end dates. They think they put themselves at risk by doing that. In fact the contrary happens. If you do not challenge and explain why these schedules are unrealistic:

  • you will have very poor team mobilisation, because your project team will not buy into this schedule and they will work on other projects, rather than be part of a projected failure
  • you will fail to meet the schedule
  • you will be the scapegoat for this project because you accepted it without asking the right questions
  • when you tell them at the end that the project schedule was unrealistic, you will be asked why you did not tell them at the start
  • you are on your way out as a successful project manager

Project sponsors and clients are not unreasonable, they are not stupid. They try to do their best with the information they have at hand and the promises they are also forced to make. They deserve better from project managers than silently working on unrealistic delay and failing. And unless project managers do their job of challenging, informing and counselling their sponsors and clients in matters of realistic delays on their projects, they will continue to work on projects where a four feet thick concrete slab supposedly will cure in two days or where the paint will already be dried before we apply it. I have seen that in project plans but it has never happened in factual physical reality. And everyone can understand that when you explain to them, including project sponsors and clients.

Don’t forget to post your comments below

Summarizing the Rules of Lean Project Management

Written by Claude Emond on . Posted in Articles. 4 Comments on Summarizing the Rules of Lean Project Management

 

My previous blog entry was presenting the last element of an eight-part series on the Rules of Lean Project Management (LPM). I wrote this series because I felt that, although it is viewed more and more nowadays as the path to better project management, LPM is really not well understood. In this context, presenting the main rules of LPM, as I see them, was aimed at helping us all better understand under what conditions project managers can really claim to use and live by Lean principles.

I summarize here for easy reference the eight rules of LPM (until these are revised or more rules are stated by others). This summary is complemented by a white paper I wrote integrating, in one single reference, the blog entries that I dedicated to this subject during the last few months. You can download this white paper at the following web address: https://www.projecttimes.com/wp-content/uploads/attachments/LPMRules_CEmond.pdf

The eight rules of LPM as I practice, coach and teach them are as follows:

LPM Rule # 1: the “Last Planner ®” Rule. The one who executes the work is the one who plans the work

LPM Rule # 2: the “Tracking Percent Promises Complete (PPC)” Rule. Do not track time (effort) or cost; track small promises that you can see over time

LPM 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

LPM Rule # 4: the “Humans, humans, humans” Rule. Humans execute projects and projects’ deliverables materialise through humans and for them. So be considerate to humans as, without them, no project can be a success.

LPM Rule No. 5: the “Rolling the Waves” Rule. Roll the waves. Make your choices and commitments (promises) at the last responsible moment. Make them in the form of work packages that will deliver the desired results anticipated with a high degree of certainty. Plan the work, execute the work, learn and adapt, plan the work, execute the work, learn and adapt, plan the work, execute the work…succeed

LPM Rule # 6: the “Opening, Adapting and Closing Often” rule. Open-Adapt-Close, Open-Adapt-Close, Open-Adapt-Close… all the time. The IPECC (Initiate, Plan, Execute, Control, Close) cycle is a recurring process; this recurrence is the true key to successful projects, lean-influenced or not. In order to close a project, you have to open-adapt-close formally at the phase level, to open-adapt-close formally at the work package level, to open-adapt-close for each required deliverable (small concrete promises), to open-adapt-close each required activity undertaken.

LPM Rule # 7: the “Executing Your Small Promises on Single-tasking Mode” Rule. Execute your small promises on single-tasking mode. Once your deliverables are cut into smaller pieces, deliver them one after the other, as much as possible. By cutting your project work in smaller pieces/promises, you will save on set-up time each time you are interrupted, thus accelerating delivery. This accelerating effect can be increased furthermore, if you also try to execute these promises, one after the other, this saving an additional amount of set-up time. In a multi-project/multi-tasking environment, the most productive strategy is to single-task, doing these multiple tasks in series, when possible.

LPM Rule # 8: the “Using LPM Principles to Implement AND Adopt LPM” Rule. Live and use what you preach to implement LPM; by «walking the talk», you will succeed in increasing the speed and extend of LPM adoption and ensure a lasting and fruitful change.

The Rules of Lean Project Management: Part 8

Written by Claude Emond on . Posted in Articles. 3 Comments on The Rules of Lean Project Management: Part 8

Using Lean Project Management Principles to Implement AND Adopt LPM

In my last three blog entries, I addressed some project management issues as they were happening to me, thus postponing my series on the rules of LPM. I continue here to expand my set of “rules”. I will conclude the series with this 8th rule, probably not the last word on this, but the essence of LPM as I see it…for now.

From the start of this series, I wanted to address the issue of implementing LPM. I was unsure how to tackle this, however. Once again, one of Hal Macomber’s most recent blog entries (http://www.reformingprojectmanagement.com/2009/06/01/991/) provided me with a good angle of attack. I thank him for that and for many other influences (good and bad!) he has had and still has on my thinking and that of the people I coach in adopting LPM best practices and behaviours.

In theis blog entry I’m referring to, Hal writes that implementing successful LPM is not possible by only going through the motions, i.e. use the Last Planner ® system, small promises, rolling wave planning, short recurrent IPECC cycles, extended/integrated project teams etc. It is only possible through “adopting” the collaborative behaviours that make these practises work. It has to do with taking seriously rule No. 4, which is to be considerate to humans and their individual interests to create the will to make a very important cultural change.

I believe that, in order to do that, some kind of chicken-and-egg approach is required. To develop the collaborative behaviours required by LPM (by all project management endeavours, actually), one has to use LPM principles to implement LPM. And this is exactly what I am doing with my clients when getting them to implement and adopt LPM. I have them go through the motions, using these motions to promote the behaviours required.

I use a technique I have called “changeboxing,” in which I apply a mix of LPM principles and a variation of the “timeboxing” techniques used in SW development to make real change come through. And it does come through very fast. Following a proper participative diagnosis and a workshop to promote a common vision of the change to be put in place, the definition of the new LPM process to be implemented is done coaching a team of five to 12 volunteers to develop and implement it themselves. This team represents the ultimate Last Planner ®, the end users of the LPM process (the project teams and main stakeholders). A changebox  takes the form of a fixed duration meeting lasting three to seven hours, with the obligatory requirement to deliver the promise made at the start of the meeting by the end of the same meeting. The deliverable could be a collaborative project definition, planning or follow-up tool, specific parts of the process, some sets of roles and responsibilities, a corporate policy for LPM, mini-guides, etc. One changebox, one deliverable! This deliverable is tried as a prototype by the team members on their own projects for a couple of weeks. Then we initiate a new changebox.  The first part of it used to adjust the previous deliverable for organisation-wide adoption; the second part to produce a new deliverable (promise) by the end of the meeting. The development/prototype implementation/adoption cycle is repeated again and again until the team members decide they do not want any more changes…for now! These same people who develop-implement-adopt are the ones who decide how, when and how much they want to change, based on their individual will to change. We do it this way because, in matters of behaviours (which are intimately linked to individual value and belief systems), nobody else can decide for you, when, how and how much you will change.

Hal concludes his blog entry by writing that to adopt successful LPM, it “takes the determined unwavering examples of leaders. Only that leadership will set the stage for adoption.” I agree; it is a question of leadership, of behavioural leadership in fact, and at two different levels:

  1. upper management must demonstrate “trust” leadership in empowering the ultimate Last Planner ®, the LPM process users, to decide what will be implemented and how, based on the participative diagnosis mentioned above, and
  2. these users must demonstrate “desire to take individual and team responsibility” leadership for adopting successful LPM, They must lead through their collaborative will and decisions to develop together and adopt these practices and behaviours.

So Rule number 8 of 8 of Lean Project Management is: Use Lean Project Management (LPM) principles to implement AND adopt LPM.  Live and use what you preach to implement it; by «walking the talk», you will succeed in increasing the speed and extend of LPM adoption and ensure a lasting and fruitful change.

From Lessons to Learn to Lessons Learned

Written by Claude Emond on . Posted in Articles. 5 Comments on From Lessons to Learn to Lessons Learned

At the end of many of my project management workshops, I discuss project or phase closing and the notions of post mortem and lessons learned.

I want the workshop participants to realise that a lesson is learned by a group or an organisation only once former behaviours have been replaced by new behaviours that reflect in a tangible way what has been learned. Having a document or a database with the title Lessons Learned, including a list of things learned in a project or a set of projects, does not change them magically into lessons learned, unless future behaviours prove otherwise.

I often explain the sad reality of so-called lessons learned systems, using as an example the Lessons Learned list developed by Futron for the NASA in 2001. I show to the workshop participants a summary of the findings on the Columbia shuttle disaster annotated with references to this list. The annotations demonstrate that not a single item of the Lessons Learned list is shown in the behaviours that resulted in this disaster. Nothing was learned!

In one of my recent workshops, one participating project manager came forward with this obvious observation (so obvious that it had evaded me, actually). He said that he lived the same phenomenon in his organisation. Their Lessons Learned experienced the same fate as those of the NASA, prior to 2003, when they lost the Columbia shuttle. He then said that maybe the problem was with the name we gave to those lists and documents. He said: “Our project post mortem documents do not include a list of Lessons Learned, but rather a list of Lessons to Learn. So maybe, if we want to send the right message, we should call these ‘lessons to learn’ instead, and then look at what should be done in our organisation to really integrate new behaviours, ensuring something has effectively changed for the better.”

I cannot agree more with this project manager. So if we want to ensure that significant lessons from projects are really learned and improve our project management processes and the delivery of our projects, we should talk of Lessons to Learn instead and then put in place mechanisms to change those into Lessons Learned.

What type of mechanisms are we talking about here? I had the privilege to work with an organisation that has such a mechanism, the telecom enterprise Microcell Connection in Montreal, Canada, now part of Rogers Communications. They considered any lesson learned in a list as a project to realise. They put together a continuous improvement program for their project management activities that included each Lesson Learned in their systematic project post mortems (done on all projects) as a continuous improvement element. This element had to be integrated into the overall project management practices, behaviours and supporting documentation, within a timeframe not to exceed (under normal conditions) six months after the acceptance of the project post mortem recommending the implementation of this Lesson Learned. And it worked very well.

So, you want real Lessons Learned?  Well, it’s easy. Just do like Microcell did. Turn each Lesson to Learn into a specific continuous improvement project, aimed at turning it into a Lesson Learned, something that will become part of your organisation’s best practices and behaviours. Changing a Lesson to Learn into a Lesson Learned is an organisational change and organisational changes will only happen if we take care of them…and taking care of them means delivering these changes as a project.

The New Project Management; the French … and Everyone Else!

Written by Claude Emond on . Posted in Articles. 3 Comments on The New Project Management; the French … and Everyone Else!

Since 2006, I have been giving project management courses as part of a master degree in “Management by Project” for three associated French engineering schools, in Lyon, Rouen and Aix-in-Provence. This master program is being extended to two new schools next fall, Nancy and Toulouse and in 2010 to Paris and Nantes. I might end up passing more time there than in Canada to coach and teach project management.

The French, as a whole, are a very creative people when it comes to many project-related endeavours, particularly in the field of international construction projects. They are engineering geniuses and fantastic bridge builders, both in France, for example the Millau Bridge (http://news.bbc.co.uk/1/shared/spl/hi/pop_ups/03/europe_the_millau_bridge/html/1.stm) and the Normandy Bridge (http://en.structurae.de/structures/data/index.cfm?id=s0000048), as well as outside their country, for example the Rio-Antirrio Bridge (http://en.wikipedia.org/wiki/Rio-Antirio_bridge) . So why this sudden fascination with project management, a domain that they apparently seem to control?

The recent rising of project management as a preferred mode of action is in line with the economic and social pressures of our current times, the Project Age: an era characterized by an ever changing business environment, high uncertainty and globalized human activities. It is also viewed by many as a major solution to deal with and adapt to the present world economic unrest.

But the type of project management we are talking about here, and which is required to deal with the current times, is a new type of management that has nothing to do with the project management paradigm of large construction projects. A major construction project is basically one that is highly hierarchically structured and uses dedicated full-time resources, something that works just like a well oiled traditional Taylorian organization. No wonder the French are good at realizing those large projects, since strong hierarchy and the cult of the “chef” (commanders-in-chief in an organization, be it the CEO or a service director) is an integral part of the French culture, an attribute that is almost impossible to change, even in very severe conditions that might call for a different way of organizing things.

The new project management is mostly a multi-project management paradigm, with ever changing targets, met through very few resources working part-time on a multiple projects, in an environment of unclear strategic priorities. In such conditions, a simple employee can basically end up deciding the strategic fate of a project by agreeing or not to work on it. So this type of project management goes really against the grain of the French culture; it will take very serious economic mayhem for it to be accepted as a way of doing business.

When I go to France to give these courses, I realize how hard it will be for those young graduates to get this new project management paradigm to work in their organizations, if anyone wants to take the chance of giving a job to those counter-culture prophets. I believe this is an extreme case of what is happening in our own Taylorian-inspired (not to say Orwellian) institutions, here in North America or, basically, everywhere else in the world. Project management today is not what it was when the first men landed on the moon or when the first PMBoK was written. It is more complex and calls for more collaborative, agile approaches to get highly-diversified project stakeholders to end up really sharing the same interests and working as a team. A friend of mine, an international expert in business governance, was telling me recently that managing a business endeavour, with the help of highly diversified, multiple-interests teams of uniquely knowledgeable, non-interchangeable people, is not anymore a matter of planning, commanding and controlling …. but rather a matter of being able to ask for help using the word “please” and to never, ever forget to say “thank you” with genuine humility. He says that power based on hierarchy and authority just does not work anymore in the business place.

So, I believe, based on what I am seeing in many organizations, that getting the new project management to work is not only a major cultural challenge for the French. It is a cultural challenge for a majority of organizations all over the world. And it represents a major paradigm shift for many project managers and their professional associations.