≡ Menu
Pawel Brodzinski on Software Project Management

Project Management Failure Stories: I Want Them All


Once upon a time there was a project. It was rather small and, to some point, not very important. Bob the Young Manager has chosen one of the specialists to run this project. You know, all this boring stuff like reading specs, splitting the work to small chunks, telling how much resources he needs and organizing the work.

Mike who was asked to do the job agreed willingly. At least something appropriate for his ambitions. For more than two months no one asked Mike how things going and by this time Mike was all stressed since he was more than sure he’s not going to meet the deadline. Finally the problem reached manager’s ear and it was the best time for Bob to show his skills and bring the project back to the right way.

What Bob did was to move all resources to help Mike in the project. Barely few people were left at what they were doing before – the rest was told “Stop doing whatever you do now! Go help Mike.” People followed the request of their boss. After all he was their manager. Bob wanted all people to rescue the project. And he got them.

Whether Mike’s project ended up well or not we don’t know. Actually it doesn’t really matter.


It doesn’t matter whether the project was rescued because failure was around all the time.

1. Lack of project monitoring

The first thing which was failed was project monitoring. If anyone supervised Mike they’d know much earlier there weren’t enough people engaged. Actually it was enough to measure how much work is marked as done and extrapolate it for the remaining time. At the deadline percent complete wouldn’t be anywhere close to 100%. Earlier assessment means earlier reaction. Earlier reaction means smaller fire to extinguish.

2. People left alone

Mike was nothing like a seasoned project manager – he was just a specialist who was given a challenging task. No one cared to coach him. No one thought he could have had some problems just because of lack of experience.

3. Project firefighting the worst possible way

What really happened here isn’t really about Mike delivering his project on time or not. It’s about the impact of crappy management on other projects run in the team. That isn’t something which is seen instantly. The effect of throwing all people to firefight in one project actually means they don’t other projects. To rescue one small project three other were sacrificed in some way. They’ll be late or will have compromised quality. And I bet when they approach their deadlines there will be even more project firefighting needed to put them back on the right track (with no guarantee of success).

As a side effect a couple of people refreshed their resumes seeing enough to realize they don’t want to work that way whole time.

See all project management failure stories.

in: project management

3 comments… add one

  • Dina February 3, 2010, 12:47 pm

    Good story, and yes sad but true. I would bet on that first project not doing so well either, Bob forgot that other rule from Frederick Brooks of “Mythical Man Month”, that adding people onto a project in the middle is not necessarily going to help save much time. So, firefights all around!

  • Pawel Brodzinski February 3, 2010, 12:59 pm

    Project firefighting is always a difficult thing to do. If you just randomly throw new people against the project you’d make it even worse and at the same time you’ll jeopardize others.

    I remember working in a constant firefighting mode in one company. It took year and a half to get things back on the track. And we allow at least a few projects to fail just to protect others, usually more important ones.

  • maria March 30, 2014, 4:26 am

    What was the project ?

Leave a Comment