• Increase font size
  • Default font size
  • Decrease font size
Home Blog: Back From Red General Blog Five of the Ten Stupidest Management Actions on Failing Projects
E-mail Print PDF

Five Of The Ten Stupidest Management Actions On Failing Projects

In many years of recovering failing projects, I have found a few management actions whose rationale seem completely absurd. Regardless of my efforts, I am unable to understand or dissuade them from their decisions. These decisions either precipitate the failure or greatly exacerbate the project's dilemma. Regardless, due to management's level of shear desperation, they can only be classified as stupid decisions. If there were the Darwin awards for management, these would qualify.

1. Add Functionality When The Project Is Behind

A project had fallen behind schedule and the customer is complaining that they will miss the deadline. This is creating additional manual work that is not in their budget. To handle this they demand a stopgap solution. The project manager agrees to adding scope to the project to help the customer overcome their hardship. This is analogous to throwing a drowning man a bucket of water. The scope increases, the budget is blown, and the time to deliver the project drags out even further.

The correct answer is, when the project starts to slow down, remove scope. Identify the critical functionality and deliver it as close to the release date as possible. Deliver the rest in a later release. Although this lengthens the project, the staff can be reduced, since people working on the delayed components can be assigned to other non-project tasks, minimizing the impact on the budget.

2. Adding More Resources

Throwing people or money at a project to fix it is never the answer. Neither can solve every problem. As the saying goes, nine women cannot make a baby in a month. The statistics show a baby a month, however they all appeared in ninth month. Maintenance costs will skyrocket, since now there are nine babies. In reality, adding people will slow the project as training, conflict resolution, and team-building tasks all require more effort from the entire team.

The same is true for money. Having too much of anything on a project can be damaging. Too many people means that people are looking for things to do, additional time removes the sense of urgency, and excessive money allows people to buy more functionality than they need.

Instead, have people focus on the most important features; remove superfluous tasks and limit outside distractions.

3. Trying To Get Different Results From The Same People

Some project teams do not have the skills to do the task at hand. If they fail once at creating the product, it makes no sense to ask them to do it again. Einstein once said, "the definition of insanity is doing the same thing over and over again and expecting different results." Continuing to try to get different results from the same people does not work. Do not try to teach a pig to fly, you only annoy the pig.

If required skills are missing from the team, determine what is required to finish the job and train or replace staff to get the needed skills. Both will add time to the project, but less than ignoring the issue. Replacing people is often the only option sensible action. New resources have to ramp up on the ideas of the project, retraining people takes time for training and dispelling the attitudes in the entire team about the failing project. Training is the best option before the project gets in trouble.

4. Assume The Scope Can Be Completed In The Original Time Frame

Once a project starts to fail it is very difficult to recover the lost time. If it falls significantly behind, it is impossible to recover. Bringing in a recovery manager and demanding all the scope fit in the remaining time, is wishful thinking at best. Either functionality must be removed or the quality compromised to make the deadline.

The only option is to restrict the scope to the critical functionality and deliver only the most needed features on time. It simply does not work any other way.

5. Cancel Training

When projects start running into budgetary problems, management starts looking for ways to cut costs. Their first choice is to trim internal project costs. The quickest is to cancel training on the tools they need to build the product. However, the math does not work. A weeklong training course costs on the average four thousand dollars, a week of a resources time is about two thousand dollars. For a person to learn the same amount on his or her own, will take a minimum of four weeks. This will delay the project by three weeks. On a project with thirty people, the cost training is only four days of burn. Being late three weeks, is over $125,000. This does neglects the cost of the diminished quality due to poor understanding of the tool.

On a project that had been a dismal failure, I found a reference to the "autodidactic staffing plan." I had never heard of the technique and looked it up. After reading the brief definition, I understood why the new deployment tool did not function properly. On the recovered project, I added training back onto the budget.

Let's Hear From You

Delicious Delicious
Add to Technorati Favorites

Yes, this is only the first five of the ten I have ready to share. But before I do that, Let's hear from you! What are the stupidest decisions management has ever made on one of your projects. What were the results and how did you recover?

Tags: , , ,

Previous Blog Next Blog


+1 # Guest 2010-05-16 23:45
Thanks for the list - and thanks especially for the suggestions for fixing the problems. It's always easier to point at problems than do something about them.

"...when the project starts to slow down, remove scope."
Reply | Reply with quote | Quote
+2 # Guest 2010-05-17 05:29
Another bad move: institute more status reports and status meetings.

Bad managers do this because they are shocked when they figure out that the project is failing. So they burden teams with over the top status meetings, presentations, and reports
Reply | Reply with quote | Quote
0 # Guest 2010-05-17 08:20
What is interesting about this list, is that in some cases, the action is not illogical, and may actually provide benefit (including Karen's addition). The key is whether or not the action is implemented in a controlled way after an honest evaluation of the issues, or whether it is just a knee-jerk reaction (which then yields the results you describe).

One other point, but not only are there wrong actions that can be taken, but inaction is often a culprit as well. At some point, a decision must be made on a course of corrective action, and it followed.
Reply | Reply with quote | Quote
+1 # Guest 2010-05-17 09:03
There are 2 inactions I can think of that belong on this list.

1. Failing to assess and address why the project went wrong in the first place.
2. Failing to consider that whatever new work follows to correct the failed project needs to be looked at through the lens of its own set of the triple constraint, not the set of the project that just failed.
Reply | Reply with quote | Quote
0 # Guest 2010-05-17 09:27
I couldn't help but chuckle out loud a few times. [1] Yep, saw that attempted last week. [2] Yep, that one as well. [3] Am I seeing a trend here? [4] They call it faith for a reason. [5] Oh, why not? Who needs it? [6] What, are they out of Ummmm, ya, they're screwed.

Being a fly on the wall is sometimes both entertaining and painful.

Thank you for the enjoyable post.
Derek Huether
Reply | Reply with quote | Quote
0 # Guest 2010-05-17 15:00
Others I would add that I've seen:
-Cutting testing time (a.k.a. not slipping the final release date accordingly as Code Complete/Dev Done/Code Freeze milestones slip).
-Basing milestone completion on today's date, rather than actual status as of today
-Trying to do functional and integration testing at the same time. What a mess.
-Mandatory overtime for a whole project team, regardless of role and their role's importance/ability to contribute at that particular stage of a project
Reply | Reply with quote | Quote
+1 # Guest 2010-05-18 06:37
I find No. 3 to be interesting and contradictory to all the advice we received as youths. We can all remember hearing the words "practice makes perfect" and "try it again" or "sound it out", increasing repetitions until we made the basket, solved the math equation or pronounced "Des Moines" properly. In each of those cases, we were practicing. And completing the task properly, as No. 3 illustrates, is about a time when practice is clearly over with and solutions need to be delivered. A-squared + B-squared struggles are over: can you bring out C-squared, please?
Reply | Reply with quote | Quote
0 # Todd C. Williams 2010-05-18 11:14
Great comments, everyone!

To Bob's point, inaction is an issue, but action needs to be well thought out. Knee-jerk almost always creates more problems than it solves.

Being an agile proponent, I am not into status reports, so I have to agree with Karen. Managers should be involved enough to know what is going on and not need status reports. If managers have too many projects to know what is happening, then attack that issue.

Kathy, you are spoiling some of my list for later, but of course we were on that project together.

Dan, "Try... try, again" is great when you are learning. If you have a product that you know you are going to be learning with, then switch it to agile and "Try... try, again," just set a limit on how many tries. If you can afford on-the-job-training, it better be on a line-item so everyone knows that is what is going on. Otherwise, get someone who has the skills.
Reply | Reply with quote | Quote
+1 # Guest 2010-05-21 02:02
I find point 3 interesting. You say:

"If they fail once at creating the product, it makes no sense to ask them to do it again." Why not? It depended on how you ask them! My main point here is how do people learn? If it is done in a structured and supported way then they won't make the same mistakes again. If they do....

From where I sit in the UK project management has a poor record of capturing learning and ensuring that skills are developed (and knowledge)

Interesting article and thanks. Ron Rosenhead
Reply | Reply with quote | Quote
0 # Todd C. Williams 2010-05-21 05:41

In the confines of a short blog it is difficult to place all the conditions and parameters around a failure. It would make a conglomerate blog like this quite long and boring; it would read like a legal document. Therefore, I wrap it up in the two words--project failure. On this one, the biggest assumption is that the skill set of the team was a major contributor to the failure. This is really quite rare, teams as a whole are usually not the problem (that honor is reserved for one of two people that simply do not have what it takes).

If the project is in serious trouble, let's say it has burned through seven of its eight million dollars yet is only half way through its tasks (this project), or it is deemed a failure, there is no money to train anyone. The training is "that hurt, let's not do that again." You need to get people that know how to do the work and get the project done.

When a project is starting, put a number of junior people on the project. add training to the budget, make sure there are mentors and watch them closely. If they do not meet expectations, assign them tasks they can do and quietly hand their original tasks to someone that can. Even if you are later in the project, and someone is under performing, ask for the funds to train them. However, in the latter case, you had best ask for funds and let everyone know you are doing OJT.

By the way, I am pretty careful to avoid saying that the root cause of the failure was the team not having the skill set. I am not sure how that can ever be the root cause. The most common cause of this issue is executive management assigning them to the project and not providing training. Somehow they think the team will learn the skills through immaculate conception--not going to happen. Management is usually responsible (as was the case in this project).

Lessons learned? Wow, I will add that to my blog list. Maybe in a couple weeks.

I hope that addresses your comment, Ron.

Reply | Reply with quote | Quote
0 # Guest 2010-05-24 15:48

The scary thing is how many times I've seen those same four mistakes that I listed on other projects since we worked together.
Reply | Reply with quote | Quote
0 # Guest 2010-05-28 02:20
Number n : Stop the project and spend the remaining budget on hiring an external consultant that will audit the project and report on who was (not) to blame.

(not from practice)
Reply | Reply with quote | Quote
0 # Ardvark 2012-01-30 19:20
I work on a project where the senior management imposes unrealistic deadlines and expects everyone to work lots of unpaid overtime (in a union office!) to get it done. If it fails, they point at us instead of themselves. In the meantime, in order to meet these deadlines, quality starts to diminish. If you raise the issue you are portrayed as a "pessimist" rather than a realist. The culture is unfortunately embedded at a high level. So we continually set ourselves up for failure but do not learn from our mistakes. I am looking for work elsewhere.
Reply | Reply with quote | Quote

Add comment

Security code

Who's Listening To Us...

Fortune/CNN Money logo
Forefront's logo
Enterprising CIO's logo
Slashdot's logo
The CEO Maagzine's logo

Read and Hear More...

Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany

Flag of France

Flag of Italy

Flag of the PRC
Flag of Japan
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

The Toyota Way
by Jeffery Liker

Related Items