Five (more) Stupid Management Decisions on Failing Projects

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?