Projects fail all the time, in fact many more projects fail than succeed. In IT studies in the 80s by Capers Jones of the Stanford Group, projects failed 80% of the time. The Cutter Consortium in the late 90s found that project success has improved a bit, but the chance of your project failing is still pretty high. Sure, there is weirdness in the discussion of projects failing. First, what is a project? Many people work on projects and don’t even know it. Next, what does failing mean? Does it mean late, over budget, poor quality or does it ‘just depend’? Leaving this discussion for a later article, there are certain things that I see in my project management consulting work that fuel failure. Do these teams know that they are struggling? Absolutely. Do they know what to do about it? No. You’re probably on one right now. Here’s my personal autopsy on projects that I’ve watched die: • Meetings with too many voices Much of our research with companies shows that good, effective project meetings can improve a project more than anything else. However, bad, ineffective project meetings can kill a project quicker than almost anything else. One of the most common mistakes is inviting too many people to too many meetings. When a project is challenging, you are a lot better off going ‘guerilla’ – get the people who can make the decisions in a room quickly, and go. Building consensus is a great thing, but not when something is on fire. • Building overtime into the plan It is weird what I see in original project plans. These are the plans created BEFORE the project starts. This is the nirvana plan, the way you plan for it to go. Everyone knows that the project never really goes this way, and more likely or not, it is overly optimistic. Even so, I see so many plans built with overtime in them. Overtime should be a disaster strategy not a planned strategy. Burnout is not a good thing, and shouldn’t be built into a plan. I’ve also seen bizarre timelines, for example, it is not at all unusual for the Help documentation for software to be due a month after the first products ship. Ouch. • Letting technical people use MS Project Bad idea. Let technical people do what they are supposed to do – write code, build networks, create test scripts, etc. They have plenty to do. Hire someone who is an expert at project tracking and have them be the librarian for MS Project, or whatever tool you are using. Giving technical people new software to play with is like giving little kids a bunch of new colored markers in a bare room with white walls that you’d like to keep white. • No configuration management plan There are many methodologies to plan the development of something, like software or other products. The big lie is that development is a linear process. When you build, something surprising always goes wrong. Fixing that something, and letting all the people who are depending on your deliverable know that things have changed, requires handling complex communication. Teams don’t build plans for this communication until things get hysterical. Spend MORE time on your configuration management than on your original development plan, and build it early. • The wrong person as SME and/or no Executive Sponsor Same problem, different amounts of time before the project spins off into death. The Executive Sponsor is the single person funding the project, owning the business need and making decisions about scope. If there is an unclear sponsor, eventually the rug will be pulled out from under the project. If the SME (Subject Matter Expert) assigned to the project does not have the authority or expertise to help define requirements, you are also doomed, although it will take longer and the pain will be drawn out. Neither of these can ever work. • More than one Project Manager I do not believe in multiple project managers. I suppose there are projects that have been successful at the end with two project managers, but it’s uncommon. Think about it – how many pilots do you want flying the plane at the exact same time? How many Presidents of the United States do we want? How many Army Captains leading an infantry team through Iraq streets? Of course, backups are a good idea (like co-pilots) but only one person should be driving. In summary, be creative and be real. A large corporation showed an impressive Project War Room, with detailed large, colorful charts of all the projects they were working on. It appeared they were completely in control of their project investments. Later, the leader of the (PMO) Project Management Office confessed “Oh, those charts are all fakes. We have that room to keep people off our backs so we can get the projects done.” You know what you have to do. Lou Russell