Sunday, 20 June 2010 00:00

Five (more) Stupid Management Decisions on Failing Projects

Rate this item
(0 votes)

A few weeks ago, I posted an article on five of the ten stupidest decisions management had done on troubled projects, as promised, here are the other five. Although these may all bring a little light hearted laughter, the goal is to educate in order to avoid repeat performances. We all have seen, and made, dumb decisions; finger pointing and blame will not improve the result. So, read on, enjoy and then share your experiences so we all learn more.

1. Compromising Testing

"Testing is taking too long. The product has been tested enough; it is ready to be deployed." I rubbed my eyes and reread the email, certain the Director of IT would never say such a directive. I turned to the team of the failed project and asked whether this actually happened. The reply was simple, "Why do you think the customer is so pi**ed-off?" Over fifty percent of the customer installs had failed, every one of those could not use the sales tools.

In this specific case, the reason the testing was taking so long, was that the same director, to save money, had denied the purchase of new computers for the testing team. The testing staff's computers did not even meet the minimum specifications for running the product. Cutting the budget and then canceling the testing because the old computers were too slow has to among the top bonehead ideas.

If budgets needs to be cut so much that testing is has to be compromised, explore not deploying at all. Having sales tools that function but are missing new functionality, is much better than having no sales tools at all. Quality assurance should have the final say, if they indicate the product is not ready for production use, it should not be deployed.

2. If All The Needs Of The Customer Are Not Covered, I Will Quit!

In order to build the customer's confidence that they would get a great system, one project manager declared, "I will make sure that everything the customer wants is included in the project. If not, I will quit." Unfortunately, the customer thought this was an honorable statement and took it to heart. After months of gathering requirements and burning through half of the project budget, the project manager had to declare that the project would take at least twice as long as originally anticipated and its cost would triple. The project manager did not quit, nor was he fired; he was moved to another project.

As the recovery manager, I found out there were two end users for the system this created two sets of opposing requirements. After reviewed the inception documents, it was apparent that the system was only supposed to support one. By returning to the original concept, scope was drastically reduced. After a couple meetings, the single end user's expectations were reset to scope that could be completed in a reasonable timeframe. In the end, even the group whose scope was removed was pleased with the final system.

In order to determine what the customer really needs, the project team needs to probe the reason for a requirement and occasional say no. It is not easy, but the consequences from not limiting scope will kill a project.

3. Limiting Exposure to the Customer

Difficult customers are ones that always press the project team to add more features. To reduce the project team's frustration, the system integrator moved the team offsite. The tactic worked, the customer rarely bothered the team. Communication was so severely obstructed that the project team never heard that what they were building would not meet the customer's needs. When the product got to user testing, the customer rejected the entire system.

The appropriate method to solve this is to determine the reason for the requests. I have seen two reasons:

  1. The customer simply wanted more and did not realize that asking for more functionality would kill the project. Educating the customer's management on the consequences, solved the problem.
  2. There was a basic problem in the definition of the original concept. The customer's requirements team kept coming to the project team with new requests since they were realizing that solution was not going to meet their needs. The project was building what they had asked for, not what they needed. The project was stopped until the customer knew what was needed.

Work with the project team and the customer to understand and solve the problems. It is the project manager's job to get more involved with the team-customer interaction to understand the issues. Communication is essential in a project, shutting it down, rather than making it appropriate, is a big mistake.

4. Trying to Hide People on a Project

Most professional service organizations need to keep their staff billable. Therefore, there is often a policy that staff must maintain a certain billable level or risk being laid off. This creates a mentality of staffing projects with people that might be able to do the work, rather than whether they are qualified. The unfortunate result is that the tasks they are assigned to do not get done properly and the project runs into trouble.

The fault is squarely on management for:

  1. Failing to maintain their staff's skills through training
  2. Assigning tasks inappropriately
  3. Having a non-sustainable cost structure

To solve this, companies need to anticipate and budget for training and nonbillable time. If the type of work is such that they cannot plan on the appropriate training, they should look at hiring temporary resources with the correct skills to do the work.

5. Buying the Silver Bullet

As Fredrick Brookes points out in The Mythical Man-Month, there are no silver bullets. Trying to fix the project by buying some new tool or product is always the incorrect choice. All products look great when the sales people tell you what they can do, rarely do they meet their expectations, and often the troubles in switching to a new tool will create more headaches than they will solve.

In most cases, people can work with the tool and address its issues by:

  • Determining what is really needed; often problems are actually in areas that are non-critical
  • Eliminating non-critical scope in order to reduce dependence on the troublesome component
  • Determining a technical or operational workaround
  • Ensuring that existing technology cannot perform the functions

On one project, the technology that was going to "solve all the problems" was the source of most of them. The product's functionality was grouped into three different sets. Only the simplest was performed by the new tool, the other two group were assigned to other tools the company was familiar with. The decision met with a lot of resistance; I, for one, was unsure it would reduce risk. None the less, the project successfully completed on time.

Months later, when the new technology was investigated further, the company found out that it would have never been able to provide the functionality for the other two sets. A second $85,000 piece of software and eight months of work was needed to make it work. Had we used it, we would and never made our deadline.

Let's Hear From You

It is your turn, share some of your experiences.

  • What were some of the decisions you had to live with?
  • How about some decisions that you thought were stupid and they ended up to be the right ones?
  • How about some apparently smart ones that ended up being the worst you ever saw?
  • Most importantly, what were the factors that decided their fate?

Read 23409 times

Related items

  • Filling Execution Gaps

    Executives define vision, strategy, and goals to advance the business. Projects enable companies to meet those goals. Between strategy and projects, there is a lot of work to be done—work that lays the foundation for the projects’ success. Through experience and research, six common gaps exist in organizations that inhibit project success—absence of common understanding, disengaged executive sponsors, misalignment with goals, poor change management, ineffective governance, and lackluster leadership.

  • Get Recognized as a Leader: Four Core Leadership Actions

    Leaders make decisions. This requires a core set of actions to gather the best information, hear out the concerns of others, and making a decision that everyone will follow—even if they do not necessarily agree with the decision. This session covers the four core leadership actions (listening, dialog and discussion, selling a vision, and elimination of blame) that are critical in your journey as a leader. We discuss and practice these actions in small role-playing groups.

  • Build Your Leadership Style: Six Leadership Strategies

    As project managers, you need to change your leadership style based on the situation. The need for a situational style is more important in project management than in nearly any other business position. Commanding the six core strategies—directive, expert, consensus, engaging, coaching, and affiliative—allows you to build the style most appropriate for the conditions surrounding project.

  • 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.

Leave a comment

Filling Execution Gaps

Available Worldwide

Filling Exectution Gaps cover

Filling Execution Gaps is available worldwide. Below are some options.


PG DirectLogo
Limited Time Price $20.99
Amazon logo
Book or Kindle
Flag of the United States Canadian Flag Flag of the United Kingdom Irish Flag Deutsche Flagge
Drapeau Français Bandiera Italiana PRC flag
Japanese flag
Bandera de España
Flag of India
Bandera de México
Bandeira do Brasil
Flag of Australia
Vlag van Nederland
DeG Press Logo
Barnes and Noble Logo
Books a Million Logo
Booktopia Logo
Worldwide: Many other
book sellers worldwide.

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

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.