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 45318 times

Related items

  • People vs Process Track Session/Keynote Example

    If you want educational keynote many of our presentations can be keynotes or track sessions. In the example below, the presentation People or Process: Which Impacts Project Success More? is given as a track session.  

    Example People vs Process keynote as a track session

    This session was given at the PMI Sioux Empire Professions Development Day help in Sioux Falls SD on September 9, 2014.

  • Visualizing Change Example

    Visualizing Change presentations have the impact of physicalizing inanimate objects and events. They are fun and involve many of the people in the workshop or presentation. In general, it is easy to get people interested in attending since mentioning that there are rope, chains, whips and blindfolds have a tendency to pique people's interest. But don't worry, as you will see from the video, this is a child-friendly event. The props physicalize constraints, chains of command, slave drivers, ignorance, and the like.

    Many discussions are held ahead of the event to ensure that the correct issues are addressed. This presentation can model nearly any problem or change by helping define the current and future states in a very jocular and interactive manner.

    Visualizing change presentations and workshops cannot be done online.

    Visualizing Change Example
  • What Would You Do? Presentation Example

    The What Would You Do? series of presentations have two goals: 1) educate the audience, and 2) get them involved with developing an answer. They are built on the premise that any audience has a wealth of knowledge and that we need to get away from the talking-head and engage the attendees. The example below is the presentation $305 Million Failure (At the time of this presentation, since it was still in litigation, it was only a $250 Million Failure). There are also ready-made presentations on sponsorship, ethics, and change management. If there is another topic you would like to see, please let us know.

    What Would You Do? example ($305 Million Failure)
  • Vision to Value Track Session/Keynote Example

    If you want educational keynote many of our presentations can be keynotes or track sessions. In the example below, the presentationVision to Value: Executing Strategically Focused Initiatives is given as a track session. This video shows the flexibility to work with the audience in ways that generally cannot be done in keynotes.  

    Example Vision to Value keynote as a track session

    This session was given at the 2014 Instant impact Conference hosted by PMI Olympia on September 5, 2014. It was given twice that day. This is the afternoon session.

  • Filling Execution Gaps: How Executives and Project Managers Turn Corporate Strategy into Successful Projects
    What Filling Execution Gaps Covers

    Filling Execution Gaps

    by Todd C. Williams
    ISBN: 978-1-5015-0640-6
    De G Press (DeGruyter), September 2017

    Project alignment, executive sponsorship, change management, governance, leadership, and common understanding. These six business issues are topics of daily discussions between executives, middle management, and project managers; they are the pivotal problems plaguing transformational leadership. Any one of these six, when improperly addressed, will hex a project's chances for success. And, they do—daily—destroying the ability companies to turn vision into value.

    Check it out on Amazon or the Filling Execution Gaps website

    Without the foundation of a common understanding of goals and core concepts, such as value being critical to success, communication stops and projects fail.

    Without change management, users fail to adopt project deliverables, value is lost, and projects fail.

    Without maintaining alignment between corporate goals and projects, projects miss their value targets and projects fail.

    Without an engaged executive sponsor, scope increases, goals drift, chaos reigns, value is lost, and projects fail.

    Without enough governance, critical connections are not made, steps are ignored, value is overlooked, and projects fail.

    Too much governance slows progress, companies cannot respond to business pressures, value drowns in bureaucracy, and projects fail.

    Without strong leadership defining the vision and value, goals are not set, essential relationships do not form, teams do not develop, essential decisions are not made, and projects fail.

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.

Other's References

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Upcoming Events