How to prevent failure: project education

According to Standish Group, top causes of failed IT project are these:

• lack of end-user engagement,
• unclear specification,
• changes in scope,
• lack of management support,
• lack of planning,
• unrealistic and unclear goals.

I haven’t seen too many failed Microsoft Dynamics NAV implementation projects, but those that I did see fail, have failed precisely for a selection of these reasons.

Take a closer look at the list above. Doesn’t it seem that the blame lays mostly on the customer? But is it really customer’s fault?

IT projects are difficult. But it’s not because there is something inherently difficult in developing or implementing software. There isn’t, or at least shouldn’t be, this far into the software industry development. What is difficult is that customers don’t understand the process, and sometimes we don’t seem to care.

It’s not customer’s business to understand how projects work. They are (typically) not experts in project management; they are experts in their industry. Customers who don’t understand how projects work, often exhibit those symptoms of failed projects.

Many times I’ve seen consultants rush into failure by not following the project best practices. They say things such as: customer doesn’t need the design documents, customer doesn’t want to have a separate testing environment, customer won’t assign that person to the project team, customer wouldn’t agree to a contingency reserve, customer will be unhappy if we reject this change. Customer this, customer that…

And it’s not about customers at all—it’s about the consultant.

When you are implementing software for your customers, it’s your job as an expert to tell them how projects work. Of course, there is a document called the Project Management Plan which does exactly that, but some projects go as if it doesn’t exists.

To prevent project failure, by all means write a good project management plan. It’s the document which explains all the hows of the project.

Then, hold a project management workshop with your customer. Present and explain the project management plan to them. Tell them how exactly it affects them. Make them aware that they are the biggest success contributor; if you don’t do it, they’ll naturally think that it’s you.

Customer spends more time on the project than you do. For each man/hour you invest, they’ll have to spend two to three. If they don’t know how the project work should be done, they are likely to mess up. If you know how the project work should be done, and you don’t explain it to them, and they mess up, then it’s your fault, not theirs.

Also, they probably aren’t aware of the biggest project risks. What are biggest risks of a HIV drug research project? Or of a presidential campaign project? If you didn’t do these projects, you probably don’t know. Your customer doesn’t necessarily know the risks of a software implementation projects, and it’s your job to tell them.

Project success is a strange animal. It’s mostly in the hands of the customer, but if you don’t explain to them how exactly they can (and should) influence the success, then might not know. It’s you who should teach them how.