Having spent some years working on project implementations, I’ve seen everything….the good, the bad, and the ugly.  Projects which aren’t going well are the worst…everyone is exhausted, demoralized, either running or blaming.  In my experience, here are the top reasons why projects fail….

1. The project isn’t process-oriented.  Projects always change processes. People forget that.  They get excited about new capabilities. The difference between a process and a capability? A capability aspires to become a process. It’s no longer optional or standalone or theoretical on paper. A well-designed process which works: the steps, the requirements, the hand offs, the information needed is a thing of beauty.
2. The project isn’t user -focused. Every project will say they are user-driven. But often times, the user isn’t really involved. Why? Because users automatically hate everything you are doing because when has anyone ever welcomed a new process?  But eventually, once they try it, they will tell you what’s wrong with it. And then you’ll try to fix it. But most importantly, they will tell you by using it. If they don’t like it enough that they would get up in front of their peers and say “It is better!  I like it!” …..it’s not ready. And there’s nothing worse than forcing someone to use a new process they do not see as better than the old one.
3. The project has problems. No project goes perfectly. However, there are some big problems which are like huge flashing “Danger Will Robinson!” headlines.
   1. Missed dates. So frequently no one reacts to a new date.
   2. Negative client impacts: pretty much nothing will justify creating problems with a client. Nothing.
   3. System availability issues: you know how you feel when you can’t get a signal? Multiply it 100x.
   4. Lack of transparency on what’s happening and why. It’s impossible to make people happy with a problematic project. The best you can do is to let them in on how hard it really is. But at the same time, you need to show there’s a light at the end of the tunnel because who wants to be re-arranging the deck chairs on the Titanic?
   5. Skipping critical activities to make up for lost time. Every project I’ve ever seen always stints on testing. They either don’t have the right test cases, enough test cases, or aren’t running enough tests when they drop code to fix defects (the “it used to work but isn’t anymore” conundrum). You are better off giving the real date rather than giving dates you won’t make, but are sooner.

What works to turn this around? Next post……