Monday, March 5, 2012

How Projects Fail

How Projects Fail

I speak to many IT professionals, and each has a story about a project that went terribly awry. One of the most frequent project related questions we all get is some form of “tell me what you learned from your last project, and what you would do differently.”

There are many reasons that projects get into trouble. So instead of focusing on a particular project, I thought in this Blog that I would outline a high level but composite picture of some of the activities that can help assure project failure – “What can I do to be certain that my project will fail?” Certainly in my zeal to describe failure modes as a primer to help practitioners avoid disasters, I will miss some prime failure opportunities. Help us all by adding the failure modes I may have missed.

With that as a backdrop, let’s start at the beginning.

1.       No need for a vision! If there is a need for a project, we all know it. So let’s not waste time with a vision, definition of what we are trying to accomplish, project charter, success metrics or any of that overhead. It takes time away from doing the project.

2.       Forget requirements documents – look at software available in the marketplace and decide if it is ‘good enough’ to meet your needs. Don’t waste time with a detailed and comprehensive requirements document. It detracts from getting started on the project!

3.       Select a vendor based on demos. We will know if the product meets our needs – we just will!

4.       Negotiate the vendor contract as early and as quickly as possible. Don’t bother appending requirements, performance metrics, delivery commitments and consequences of non-delivery. Let the vendor manage their end of the project and don’t worry about it. After all, you know this is the right vendor for you! They do this all the time!

5.       Think of this as a system deployment. Don’t get distracted by the business needs or by process reengineering or modification. It will distract you from the real goal – get the new system in and working.

6.       Don’t be overly concerned about resources. The business wants the project done – they will find a way to participate and get their part done. Where there is a will, there is a way.

7.       Don’t spend time defining the decision making, review and communication processes for the project. These administrative distractions will only slow you down.

8.       Set the golive date, build a plan and relentlessly track it. The plan is the plan – take no prisoners. Get it done, no matter what. Meet the plan and timeline – that is the goal!

9.       Take shortcuts where you can. Detailed documentation of use cases, process change and the like takes time and will detract from meeting the sacred system deployment goal.

10.   Go light on user training. They will get it…after all, this is the right system and it will work just fine. Be willing to make compromises here to get it done.

11.   Don’t worry about scope creep – if new understandings emerge, they can be accommodated in the project. Don’t let that slow you down.

12.   Conversely, if your team identifies some needs that cannot be accommodated, don’t let them get away with it! There is no phase 2 – this is it.

13.   During the project, let your team focus solely on getting it done. Don’t engage in periodic review by an unengaged expert body such as a PMO review. Wastes time, distracts from the goal – get it done.

14.   Don’t engage numerous committees to oversee the project. Executive steering committees, project teams, tech teams and the like are a waste of time. Focus instead on getting it done; speaking with whomever you can find to be engaged to help. Don’t get process bound.

15.   Don’t worry about politics. The project lead can make all necessary decisions.

16.   Defer thinking about support of the system after the project is in production. It will emerge naturally and take care of itself. The same goes for setting a transition support period between deployment and normal ongoing operation. Overhead – shun it!

Any one of these factors can cause project failure. Taken together, they virtually guarantee it. Proceed wisely!

For more information, see

Bob Kotch – -@Bob_Kotch

No comments:

Post a Comment