Why Technology Projects Fail

 

Introduction by Andrew Berger 

I am pleased to host a guest blog post by Robert Kotch. Bob is an experienced management consultant and business executive with extensive background in business strategy development and deployment, financial management and technology leadership. His experiences include integrating diverse IT organizations, serving as CIO and financial head of a division of a Fortune 50 company, and many technology focused successes including CIO and executive team coaching, web strategy development, IT process deployment, business process improvement, management of major programs and evaluation of acquisition targets.

His post below focuses on tech project failure and he sets forth a prescription for failure you may wish to avoid. Here is his post:

 

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

There are many reasons why projects get into trouble. So instead of focusing on a particular project, I outline a composite picture of some of the activities that help assure project failure as a warning to help you avoid similar disasters. I will miss some prime failure opportunities. Please add them in the comments section below.

Prescription for Tech Failure

With that as a backdrop, here’s a laundry list for failure:

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 or a 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 contract 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 only 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 re-engineering 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 go live 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 Project Management Office 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!

 Real Life Illustrations

Let’s look at a couple of real life situations to illustrate these points.

First, here’s what happens when you have no contract requirements – The client spent a lot of energy surveying applications in the marketplace and created a weighted decision matrix based on vendor documentation, extensive discussion with the vendor and its priorities. As a result of that process, a vendor was chosen. All agreed to honor the choice, although there was a firmly held belief by some that the wrong choice was made.

At project initiation, in depth meetings were held with the vendor to review desired business process operation. This led to agreement to make certain enhancements to the core system, and a working consensus was achieved between the vendor representatives and the client. The vendor documented these at a high level and received client approval to proceed.

Then staff was deployed by the vendor to implement the system. There were several changes in staffing for a variety of reasons, and the agreed changes did not get implemented as desired in some instances. This set of issues delayed testing, resulted in added cost to change the changes in some cases, led to gaps in performance desired in other cases and delayed the project while increasing cost. And there was no recourse…

In the end the project deployed, with some flaws (some known in advance and some not). Requirements would have helped!

A second case – here are the consequences of a predestined timeline. A client was centralizing a function nationally. There were several instances of an old vendor system deployed in the various offices. The stated desire was to centralize the function using that system. This required moving to one instance of the deployed system.

There was no movement allowed in the end date. What to do?

In this case, two overlapping teams were formed to serially convert each office to a single instance of the system and centralize the function. Vendor personnel and contractors were heavily involved, and while it was exhausting, the team engaged got the job done well – at least they got the job as defined done well.

What got missed was consideration of a significantly reengineered business process. Yes there were changes to accommodate the needs of a single instance, but the opportunity to significantly reengineer the function and create the necessary buy-in across the organization was missed. The price was significant missed opportunity to materially improve the business as this change was made, and dissatisfaction among the participating organizations.

The point is clear – creative teams will work around any flaw and do as good a job as can be done under the circumstances. But opportunities to improve the business and manage cost get put aside – to the business’ detriment.

Any one of the above factors can cause project failure. Taken together, they virtually guarantee it. There is a better way.

Thanks Bob. If you have any questions or need more information, please contact Robert at rak@simassoc.biz or visit his web site at http://www.simassoc.biz.