Don’t Kill The Golden Goose of Project Management – The Crisis
We certainly would not sell off the fairytale Golden Goose to pay for today’s meal. We would find a way to eat today or go hungry and keep the Golden Goose until she laid that next Gold egg. Yet, too often we ignore each project management tool Golden Goose as it comes along.
We were in a crisis. The project was running late, again, just like all our previous projects. We were sure this one was going to be OK. However, it was too late to worry about what really went wrong. Our job was to work hard to get the project back on track – just like everyone else did on those previous projects. We would defer doing anything about what went wrong until the “retrospective” or the “lessons learned” at the end of the project.
We just killed the Golden Goose. When the energy is high and we are well aware of a problem is arguably the best time to initiate a fix to it — to lay the Golden Egg. The Golden Egg is often a small incremental fix to the process but it can also be a big change. For those of us who work on multiple projects, all in different stages of project progress, the fix is often too late for the current project. Those projects still in their early stages, however, are often perfect candidates for an improvement.
We had just passed a major early milestone of what was going to be our company’s biggest project. It was the mega-project that would make the company profitable for the next few years. The problem, however, was that we took an existing project, tripled the number of products it was to have and increased the number of new product features by 450%. And, oh yeah, we reduced the schedule by two months. We all just needed to hunker down and work hard.
As miracles do sometimes happen, a small group of folks decided that we needed to carve out some time and make better sense of how we picked products and when we planned to deliver them throughout the year. The team completed an initial step of identifying the critical months during the year to release new products. Everyone was very satisfied with this result because a huge part of the problem in the current mega-project was we had decided very late when the product needed to be ready. I then spoiled everything.
I too was excited about knowing the yearly delivery dates. I then added that each product not only needed a delivery date, but also an associated kickoff date. I shared with the team the data I had collected over the years on how long it was taking to put out a new product. I then showed what this meant for each delivery month laid out for the year. They pondered my numbers, then decided that the average project durations I offered were too long, and picked shorter durations (Huh? What about all the data? Oh well.). The durations were still longer than what we were using on the now late mega-project. We now knew what a year would look like, when we needed to deliver and when we needed to start. But, there was another problem.
We always had multiple projects going at any one time. They overlap such that while one project (possibly a group of products) is getting started another group is about half way through the project development cycle. A final group is just about ready to deliver to the customer. The problem? All the projects planned were already late by the solution we just laid out. Every single one of them. Actually, this should not have been a surprise as this company had a reputation of always delivering their products months late.
For a short period of time a small group of managers got it. We were planning our projects to be late. We were starting them too late for when we wanted to deliver them. I would like to say this changed the organization. It didn’t. At least not immediately. We delivered the mega-project months late. It would take us a few years until we were once again in a position to plan a mega-project with an objective schedule (see Project Management Crisis? Do Nothing!). We finally achieved on time delivery for that mega-project and also for the vast majority of projects later completed on that baseline.
The Golden Goose of project management is often the crisis. When the crisis hits is arguably the best time to address the root cause that is troubling the project and possibly the company. The crisis is when our energy is at its highest and when our awareness of the problem is at its peak. We may not rescue the current project but newer and future projects can benefit from our crisis – our Golden Goose.
Are you making the best use of each crisis on your project?
Filed Under Change Management | 6 Comments
Tagged With Crisis Management, Estimation, Golden Goose, Project Management Tools, Schedule
Comments
6 Responses to “Don’t Kill The Golden Goose of Project Management – The Crisis”
Leave a Reply
[...] This post was mentioned on Twitter by Steelray Software, Bruce Benson. Bruce Benson said: Don’t Kill The Golden Goose of Project Management – The Crisis http://bit.ly/cWahKy #pmi #pmp #cio #agile #PMOT #PMOT #scrum [...]
Boy can I relate to this article. LOL
If you can’t address the problem immediately, at least make a quick note in a log of what went well and what didn’t. Then, HOPEFULLY, I know its rare, you’ll have a post project review. Never try to remember EVERYTHING that went well and didn’t after the project. For a project of any length, you won’t. No, you won’t, unless you have a photographic memory.
As Bruce noted, unfortunately, MOST companies aren’t interested in addressing or fixing the cause of a problem. They keep making the same mistakes, and usually the people in trenches suffer the most. The attitude is, again unfortunately, nature of the beast. Like it or leave it. Especially in this economy, there are plenty of replacements available.
How do you get companies to buy into post-project reviews and process improvement? Great question. I’m all ears, or eyes in this case.
Brett,
I’d prefer not to have post project reviews, simply because they are almost always too late, we forget so much, and we are now focused on the next thing, and not interested in talking about the past.
That is why improving the process and fixing the problems needs to be done as it happens. Agile Scrum has a retrospective but it is after each sprint (which is 2-4 weeks) so this is a good compromise (at least in terms of timing).
One nice and unexpected benefit that comes from getting schedules right (good estimating) is that it just about always enables improvement efforts to happen while we are doing the work. When we fixed the schedules for organizations who are perpetually late – their quality improved dramatically and one reason for that is they can take the time to do it right – and that often means taking some time to fix existing problems and improve existing processes rather than continuing to work around them.
I’ve seen one great lessons learned document from a completed project. It was so good, had such good data and good suggestions, that it became my plan for how I did my project. I’ve only seen one (1) truly good output from a post-project review in over 30 years of digging through these kind of things.
Let me add that I don’t mind the post project review, only when we use it as an excuse to defer fixing anything until then.
Good points
Obviously, the objective is to take corrective action to prevent the SAME old problems from recurring, however you do it. Of course, the real problem is getting people to do it.
I would be VERY interested in success stories on getting this corrective action to actually take place, and how they made it happen.
Brett,
On successful corrective actions:
http://pmtoolsthatwork.com/seven-ways-to-make-that-silver-bullet-work/
Bruce