If Our Project Management Crisis Is Obvious To Everyone Then It Is Too Late To Fix It
The first thing you need to do with your employees is you’ve got to be open,” says Heins [Thorsten, new ceo of RIM].” Tell them where we are. They’re thinking it themselves anyways. You cannot sit there and say, ‘Hooray, hooray, I’m rocking in the U.S.’ If you aren’t. So you have that realism there. … Smith [David, SVP RIM] realized that the project was foundering. There was no way they would be able to deliver a high-performing product on the schedule they had publicly committed to. … Heins encouraged Smith to be candid about the reasons behind the delay and go directly to RIM’s board with a revised plan. Denial was no longer a managerial option. “It was a bit scary,” says Smith. “But at the end of the day we executed on the plan. We delivered on what we said we should do.” … This time, reviews were largely positive though sales continued to be lackluster.” Bloomberg Businessweek April 9-15, 2012.
Yeah, it is not too bad now.
We’ll just hang on and keep saying we’ll be done on time.
Let’s wait until there is a clear problem — where things are really going bad — then we’ll do something radical.
Yeah, that is all we need to do. Make a real change only when it is clear that we are already … dead.
I’ve lived through too many of these. The more humorous one was where we said we’ll be done “next week” every week for nine months.
At the Software Engineering Institute, while I was deep diving into change management case studies, all the great examples of change management techniques seem to come from … companies that ultimately failed. The stress of trying to prevent failure generated some great change management actions and results, but they were almost always … too late.
Too late. I watched as an Air Force Brigadier general tried to fire up his Colonels — most of whom were settled into waiting for retirement — by saying “we have to treat this like we are at war!” The general had the right idea. The only problem was the Colonels knew they were not at war and by the time any war happened it would no longer be on their watch.
If we wait until it is a crisis and it is obvious to everyone, then it is simply too late. The best we can do then is not to drown along with the rest of the organization as the project crashes on the rocks and sinks to the bottom.
To avoid this pitfall we often have to be brutally honest and disruptive now (see we need to disrupt the project to make the big improvements) and suffer the slings and errors of “Why are you doing that! Things are not that bad yet! Let’s wait and see a bit longer.” No, let’s not wait. We need to change now, before it is a true crisis.
Is your project really going to succeed or do you need to make that brutally honest disruptive change right now to ensure it succeeds?
7 thoughts on “If Our Project Management Crisis Is Obvious To Everyone Then It Is Too Late To Fix It”
Comments are closed.
Almir,
Agreed, I’ve observed that an agile approach is especially useful on projects that are not well understood or have not been done by the team before.
Before “agile” we used incremental and exploratory methods to help manage the risk. I’ve observed that almost any well known methodology will work well if the folks doing it understand it and implement it with insight (i.e., not a mindless checklist approach, but a value added approach).
So if we do “agile” mindlessly it will probably be no more successful than any other approach. I’ve seen companies throwing new techniques and methodologies at its problems, but never succeed because they didn’t deal with the root cause, which could usually be identified as silly but well meaning management practices (which when we eliminated them, all the existing techniques actually worked pretty well).
Thanks for the comment.
Bruce
In current times of changes delivering project is extremely difficult, regardless of what methodology you use.
Using one of Agile development approaches/ methodologies, in my opinion, would increases the chances for success more so than Waterfall. It certainly is not a guarantee of a positive outcome but it’s is worth trying.
More comments from around the web:
Bob Hamilton • Hi Bruce,
Something that helps is to have some quite senior execs in review meetings who have no emotional attachment to the project. They tend to be more (a) able to see the project in the overall context of company goals, and (b) willing to kill a project when it no longer makes sense to go forward. Another good point is to NEVER allow people to say their deliverable is ‘90%’ complete; that last ‘10%’ always eats up 50% of development time.
Bruce Benson • Bob,
I had a PM instructor continually repeat to us throughout the course that “100% of nothing is nothing!” I try not to use percentages unless they have a concrete basis (i.e, things we can touch or run or …). I’ve often found it is the “completed” stuff that often turns out to be less than 100% (done, done) because we had a too relaxed criteria for declaring done.
Good points.
More comments from around the web:
Gunnar R. Bartels, PMP CSM • If our Project Management Crisis is obvious to everyone – it’s high time the project management professionals start working and kicking the right people in their b***.
It’s not a Project Management Crisis – it’s a people crisis, a crisis of the people who do things they think they can do but better should not do, for whatever reason, and of the ones, who put them in these situations.
Bruce Benson • Gunnar,
Agreed, it is a people crisis, but the solution — I’ve found — is not kicking b*** and taking names. Too often it was the “commitment process” up front that signed up to unattainable goals (schedule, cost, functionality, etc.).
So the fix is often to survive the current project, kind of a controlled but inevitable crash, and salvage something from it, then make sure the next project learns from this experience and doesn’t repeat the over-committment/bad estimating that is often the root cause of so many failed/supbar projects.
Thanks for the feedback.
Comments from around the web:
Bob Hamilton • Hi Bruce, it seems to me that the worst offenders are either not using, or miss-using, some form of stage-gate program management. Perhaps they’re avoiding the hard questions and uncomfortable answers during early stage reviews, and nobody is willing to say “We haven’t met our deliverables, and we need to stop now and make immediate changes. Other wise, we’ll fail”. It’s amazing how many people think that delays early in the program can be resolved by somehow “catching up later”. They don’t seem to be aware of historical proof that early delays usually get multiplied in later stages.
Bruce Benson • Bob, agreed. What I’ve often seen is a reasonable quality/gate/decision review that has, over time, been dumbed down to avoid admitting bad up front planning/estimating and to allow a project to continue, as we’ve already made a promise and have committed resources.
Also, often it is not hard to dumb down a review as judgments as to if a project is ok or not is just that – judgments. Sure, we have metrics, checklists, etc., but at the end of the day they are only indicators and not necessarily a complete view of reality. Indicators are to help our judgement, not replace it. However, I’ve never found it the case that the consensus thought everything was fine and it turned out not to be so. I’ve often suggested, but have never been taken up on it, that we have the team anonymously vote on if they thought the project would deliver on time (with good quality, etc.). I suspect this indicator would often differ with the “agreed” status, especially for struggling projects.
Also agreed, when things are not going right we need to take action and get it back on track. My experience has been primarily with organizations that regularly did not deliver projects on time. For them the most common solution was to recognize that they were regularly underestimating the projects and so the solution was to stop, make a new estimate – based upon past history/performance, move the end date out to where it should have been, and then work like crazy to hit that date.
I tell them that the notion of “catching up” only works when we first have a realistic plan/estimate. We won’t catch up when we’ve underestimated the project by 20-50%. If we do have a good estimate (and we’ll come to recognize when that is true) then all the classic “work around the clock and weekends” can actually make a difference and put us back on track. Too many consistently late and buggy project organizations regularly have their folks work late and weekends — and still deliver significantly late with low quality (and cost overruns).
Excellent points, thanks for the feedback.