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

Related items

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

  • Strategic Alignment: The Key To Project Success

    Buy it now!

    Project success rates for many companies and government organizations are dismally low, yet executives never seem to look at the big picture. They continue to make adjustments in the way projects are run by addressing isolated problems. However, projects are part of a much larger system and should be addressed in that context. To do that, companies must define how their strategic plan will use people, projects, and technology to achieve their goals. This paper discusses one approach to make this happen.

  • Challenges In Executive Project Sponsorship

    Buy it now!

    eCameron took a serious look at project sponsorship by conducting a series on non-scientific interviews. Initially the focus was the healthcare industry. As patterns started to emerge, however, others outside of that industry expressed serious interest. To address that interest and better understand the larger issue we expanded the interviews to outside healthcare. Candid and confidential interviews were conducted with project related personnel including executives, sponsors, project managers, and Project Management Office (PMO) managers. In summary:

    • Sponsorship is an issue in all business domains.
    • Good sponsorship is an essential component in creating successful projects.
    • Many issues are pervasive across industries.
    • Sponsors need to work with project managers to design a successful project outcome.
    • Sponsor roles are neither properly defined nor supported.

    This white paper presents the results of the research and highlights areas where organizations need to improve to change their project success rates.

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