Why do projects fail? Just google it and you will find over 400,000 results. Check out the listings on the first two pages of the Google results and you will find they all list the same reasons.

Check out the famous Standish Chaos Report or Michael Krigsman's Why 37 percent of projects fail report. They point to common issues.

For example, many articles say projects fail because they lacked scope definition, proper requirements, executive support, goal alignment, and so on and so forth. Do I need to list them all here? No, you can easily find them on the web.

First of all, let's not limit ourselves only to the activity of "project management" as defined by what project managers should do.

We also need to consider the other non-project management activities in a project. These are the things that designers, builders, QA testers, approvers do. So, let's include those in the mix as well since they can drive success or create failures.

To remedy the habit of project issues, there are industry guideline standards, such as PMI PMBOK and PRINCE2. These present good standards on what to do to reduce risk of failure.

With all the articles, lessons learned, and industry guidelines, WHY do we still have issues, missed deadlines, and sunk projects?

I believe there are two underlining reasons for continued project failures:

1. We are missing the right steps.

2. We don't know how to do them the right way.

1. missing the right steps

Our project plan either has or doesn't have the list of tasks or process steps that help us stay out of trouble. Sometimes we do know the list, but may bypass some tasks due to time pressure.

Have you heard this one --- "The project is late coming out of the build phase, so let's skip the test phase in order to meet our deadline." Yes, this does happen!

Another common problem is that we may forget the right steps because we are human. We know to do them, but we forget a few items. This is true if we do not document the process. If we do document it we may not have the discipline stay on top of them.

We could also run into the problem of assumptions. Assuming something was done by someone else, so it gets checked off.

In the traditional model, the project manager may be the only one checking off the tasks as he or she owns the project task list.

A large company may have 50 large profile projects and over 5,000 small to medium sized projects. We hope the 50 large ones will get the experienced project managers. What about the other 5,000 small projects? Who helps these inexperienced "project managers" on how to define and drive a smart task list?

What to do about it:

• Get the list of best practice steps from standards, articles, and people's experience.

• Document the right steps for your project and make them part of your process.

• Use a business execution platform (i.e., PIEmatrix) that can bring all of these steps in front of each person as they do their work in real time.

• Assign accountability to those steps.

• Get everyone involved in owning their own steps.

• Govern all steps to ensure they were done.

• Drive discipline.

• Repeat.

2. We don't know how to do it the right way.

The second reason for project failures is that we don't always know how to execute our project tasks and process steps perfectly.

I strongly believe this is why our projects still run into issues or fail even though we do have the right list of steps and are checking them off as we go.

Over the years our work initiatives have become more complex and more global. They are affected by the changing workforce. We have less people to do more.

The knowledge of how to do the steps right are in silos --- people's heads. If a person who knows how to do a proper business case leaves, that person's knowledge also goes out the door.

Another issue is that different people will interpret a task differently.

Let's take the task "Obtain executive sponsorship and commitment". Let's give this task to managers in ten similar projects. What are the chances that the ten people will approach this task the same? My bet is zero out of ten. I also bet that a few will be very successful and a few will fail miserably.

One key reason is their differences with experience and knowledge on how to obtain the right level of executive sponsorship and commitment needed to foster success. Another key reason could be how to partner with the executive with an agreed upon amount of communication, feedback, and interaction. Lastly, it could be how to stay connected with the executive throughout the engagement.

Remember, we are not only talking about what the project manager does, but also what team members do that could make or break the project. For example there could be ten different ways for a data analyst, tester, architect, or superuser to execute their set of project tasks.

What to do about it:

• Start with your list of best practice tasks or steps as defined in the section above.

• Leverage industry standards that include the how-to.

• Seek out your rock stars! These are the few who have more experience and knowledge on how to best do certain steps.

• Include all of your team members who know the process when defining the details. They know the work and are your best experts.

• Document detailed descriptions for how to execute the steps the best possible way you can this week.

• Conduct a "user acceptance test" with your team. Don't just throw it out there since some people may resist to change since they were not included in the change process or you may have missed something they know.

• Leverage a simple and visual tool, such as a project and process management software like Pie to drive your how-to processes to the front-line people in real time.

• Capture lessons learned as you go and update these process step descriptions in real time.

• Keep the knowledge content in your steps fresh as possible, so next week's process is better than this week's. I call this "micro innovation".

• Drive discipline.

• Repeat.

Written by Paul Dandurand, Pie CEO/Founder

Photo by Pedro da Silva