The Top Reasons Projects Are Unsuccessful

By Richard Morreale

Over the years, I have been asked to review and audit many projects—projects showing signs of trouble, projects in what could be considered “terminal trouble,” and projects that had already given up the ghost. I was asked to do this for several reasons. The first was to see if the projects showing signs of trouble were really in trouble and, if they were, what we could do to keep them from going terminal. The second was to see if the projects considered in terminal trouble really were terminal and if there was something we could do to save them. And the third was to see what lessons the organization could take away from the projects that had already given up the ghost, so the mistakes made on that project weren’t made again.

Projects are unsuccessful for many reasons. What I learned, however, over the years of managing projects, speaking with other project managers, and reviewing and auditing projects was that the same problems showed up repeatedly. The following are many challenges that cause projects to be unsuccessful.

1. Lack of Agreed Requirements

The lack of agreed requirements is the number-one reason projects are unsuccessful. And it doesn’t matter whether you are developing something that will take you a month or take you a year. It’s still the same. The lack of agreed requirements is the number-one cause of unsuccessful projects. Now, no project manager should start a team working on a project without first knowing what the client wants, but some project managers do. They start the project without clearly understanding what the client wants. The project starts without an agreed requirement, or if there is one, it is usually an inadequate one. People start working to deliver what they think the customer wants, and soon enough, they discover that they really don’t know what the customer wanted, and they’ve wasted lots of time, effort, and money. The project starts on the wrong foot and continues out of step. Morale could be affected. It’s just a bad scene. Look, when you are not talking about information technology projects, it’s easy to see why you need requirements documents. It would be foolish to have a carpenter come to build a house for you on some land you owned, and the requirements were that you wanted a “real nice” house that’s “big enough” and has “enough” bathrooms. Oh, and by the way, you want it finished in three months, and you want to know how much it will cost. You see how foolish that sounds? Well, the same thing can be said about requirements for IT projects. Attempt to build a system without a set of requirements, and you know you will be in trouble.

2. Lack of Proper Project Planning

Most projects I’ve reviewed that are in trouble do not have a proper schedule in place. I’ve found projects with high-level schedules that haven’t been updated in months. I’ve found projects where there is a schedule, but it is on the shelf and the project manager is running the project by what only could be called “seat of the pants” project management. Without a proper schedule, the team members don’t know what they are expected to do and by when. They don’t know how what they are doing fits in the overall project. They don’t know, with any certainty, how long the project will take, what resources are required, how much time is required of the client, and loads of other stuff they should know to have a successful project. The information that should be included in a proper schedule includes: • What must be delivered on the project—the individual products that make up the project delivery. • The activities required to develop and to deliver the products. • A dependency network detailing how the various activities fit together. • The resources required to complete the activities. • The planned start and end dates of each activity. To me, a schedule that includes this information is an excellent project schedule that I can work to and monitor, track, and report on achievement.

3. Poor or Lack of Proper Change Control

Another major reason that projects are unsuccessful is because of poor or lack of proper change control. I have never asked a project manager, “Do you control changes?” and had him or her say, “Nah! We just let those suckers fly.” They always say they control changes. But, in almost all cases, they don’t control changes as rigorously as they need to. So, when I ask for the agreed baseline documentation, say, the requirements or design specification, he or she usually can’t produce it. So I wonder what they are writing changes against—the ozone? What seems to be the problem then? Why do most projects not have strict change control processes and procedures in place? What I’ve found is that most do have processes and procedures in place, but most project managers are not as insistent on the achievement team following them as they should be. In addition, what I’ve also found is that most change control procedures are bureaucratic and are followed creatively, if followed. I’m sure you know what I mean about being followed creatively. Anyway, what we need to do is be creative in writing the procedure and bureaucratic in following it. The definition I use here for bureaucratic is strict. Therefore, we must be creative in designing our change control process and strict in following it. I’ve seen, as I’m sure some of you have, many situations where changes were made without impact assessment being conducted, and the change caused project slippage, increased costs, and technical problems. Proper change control is one way to stop these problems.

4. Inadequate Cost Control

Another major reason for unsuccessful projects is inadequate cost control. Most projects I reviewed did not track costs against achievement. They did not do cost/schedule reporting. It’s great to be right on schedule, but it’s not so great if you’ve had to spend twice the money you were supposed to spend to stay on schedule. You ask a project manager if he is on schedule, and he says he’s right on it. Right where he’s supposed to be. Great, then you ask him this, how much money has he spent to be on schedule? Most of them hem and haw and admit they are unsure, or when they are sure, most of them have spent more than they should have. Most successful managers track both cost and schedule.

5. No Agreed Development Process

Too often, project managers use the old seat-of-the-pants method to manage their projects. That is, the project is started, and it continues to be run without an agreed development process in place. One of the biggest problems with this is that the project manager is the only one who knows what the overall plan is. At least, he thinks he knows what the overall plan is. But these projects usually do not have a good project plan in place, either. The project manager is making it up as he goes. And that causes big problems. A standard development process in place makes it easier for the project schedule to be developed as the products, activities, and deliverables are already identified. That’s half the planning job right there. You then need to identify the resources, estimated effort, and the elapsed time for each activity, get everyone’s commitment to the schedule, and you’re on your way.

6. Poor Communication

Communication is usually a big challenge, even in well-run projects. And, for sure, poor Poor communication causes team members not to know what the project schedule is. Poor communication causes the project to lose focus. Poor communication causes team members to make decisions on the project where they do not have the authority to make the decision. Poor communication causes the development team not to develop what the client wants. Poor communication causes gossip and assumptions on the project. The project needs a communication plan, and the team needs to stick to it so that communication is a success multiplier and not a failure.

7. Lack of Focus

Lack of focus is another thing that pushes projects off the rail. Often, we start with laser focus on what we should be doing, and then things change. We start to lose that focus. Clients ask us to do things a little differently from the way the requirements say it should be done. We’re nice people. We don’t want to say no, so we do it. It’s a little thing anyway. Then, other things get in the way. The enthusiasm we had in the beginning for the project starts to wane. We get enthusiastic about other things that come up. We have things that come up outside the project we have to do. Before you know it, you and your team have lost the laser-like focus you had on the project at the beginning. And once you lose the focus, it is difficult to get it back again. You can, but it would have been better not to lose it in the first place. The project manager needs to do everything in his power to keep non-project demands away from his team and keep his team focused on what it is the project is delivering.

8. Lack of Commitment

Lack of commitment is a killer. Most people are involved, not committed. You know the old example to show the difference between commitment and involvement. Take your bacon-and-eggs breakfast you might have had this morning. For that breakfast to be a success, the pig was committed while the chicken was only involved. Commitment is jumping in the pool to see whether it’s cold, whereas involvement is just sticking your toe in the water. When you have something to do, make sure you know what it is, and then just go for it. You don’t want to go for it and not know what you are going for. So, who has to be committed? You, your peers, your project team, the business, the users, the project sponsor, and all stakeholders on your project. A stakeholder is anyone who has a part in the project’s success and/or will be using what is being delivered. To learn more about ways to make your projects successful, read Top Gun Project Managers: Reaching the Top by Richard Morreale. Richard is also offering a FREE webinar to PMAC members on this very topic. [FIND OUT MORE]