Sunday, 16 May 2010 00:00

Five of the Ten Stupidest Management Actions on Failing Projects

Rate this item
(0 votes)

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

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?

Read 10745 times

Related items

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

  • Disband Your PMO

    After nearly 30 years of project work, I struggle to understand the role of a project management office (PMO). Even though, I have written of the pros and cons, and read a plethora of articles, opinions, and how-to guides little has been done to convince me that the PMO is reducing project failure. It seems to be nothing more than a tool to fill a void in leadership? Even the acronym, which is so widely thrown around, has little meaning as the "P" has no less than four meanings. It is an executive's crutch for their lack of understanding in how projects work. These, like other, unattended holes in the corporate accountability create opportunities for new and greater bureaucracies and empires that further obfuscate accountability.

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps and they head down the road of failure. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, they did not know, ironically, since there was no procedure in place).

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap