What is the leading cause of death among IT projects?

Not applicable

In this post, Five Ways to Help IT Respond to Business, I jokingly stated that analysis paralysis is the second leading cause of death among enterprise IT projects.

This raises the question: what would be the leading cause of death for these projects? Lack of funding? Security concerns? Culture? People getting yanked off the project?

2 8 950
8 REPLIES 8

Not applicable

Failure to overcome barriers imposed by departments' boundaries could be other leading cause. Many companies don't even realize that not only these invisible lines exist, these are so much stronger that sometime it's easier to contract outside service provider than collaborating across departments. Lack of shared goals and mutual trust could be reasons why these barriers are so strong.

Apigee has been leading workshops with customers to share our learnings from hundreds of implementations and also hear customer challenges. Getting started is absolutely a sure killer to API programs, but we hear that once started the quick reaction and ongoing iterations necessary to deliver quickly can also lead to failure if teams aren't delivering at the pace needed by the business. This is a combination of structural changes and cultural changes needed to delivery more quickly. Structurally, companies need to relook at how they are organized and how to empower smaller teams to do more with full control of their area to think, react and deliver. Culturally, companies need to get rid of antiquated processes that add zero value and empower people to make decisions.

Not applicable

@ssubbiah - Experience from a non IT person - multiple systems without proper integration or communication within them - it causes uses to see what other alternatives I have.

Not applicable

Voltaire nailed it: Perfection is the enemy of good. The tendency to prematurely optimize leads to an amazing amount of angst, anger, and adversity. Architects want to optimize performance, business is looking for the perfect use case, management needs the immediate hit. In the end, recognize that digital transformation (and the IT projects that mark progress) are a journey.

In my experience, there's a lot of lazy decision making that goes on with technology platforms - very often the decision is made out of convenience (e.g. leverage an existing vendor relationship and/or acquisition of bolt-on capability to a primary solution), rather than an informed decision as to the suitability of a tool/set of tools to solve a given set of use cases. This leads to compromises in solution design/ability of a given vendor to support the tools selected. All of this is very often characterised by RFX type selection processes, where decisions on key solutions are made off a paper based exam exercise - a bit like buying a car off a brochure..

Path of least resistance with some biased exercise to justify a decision. In the end, it doesn't move a company forward quickly and with the right solution. I agree 100%. Thanks for the comments.

Not applicable

To add to David's answer, the key message to promote is that APIs are forever evolving and are meant to be iterative. This allows you to keep up with the changing market and demand. We often see projects that spent a large amount of time solely on design fail since in the months it takes to design an API that is "perfect", the market has either moved on, the budget has run dry, or the demand is no longer there. Learn by doing and as long as you design your APIs from the perspective that they will constantly be changing over time, you'll have the flexibility needed to succeed

Not applicable

For me, it's about commitment, and it's not so much about individual projects, but more about programs and strategies.

If a company shows commitment to a wider program or strategy, individual projects can fail and the business can still succeed because "the whole is greater than the sum of the parts".

I'd even expand that out further and dare say you could have individual programs fail within a wider strategy and a business could still succeed.

If you choose the wrong strategy for your business, it could be catastrophic.

Being Agile is just as much about failing fast and learning quickly, as it is about speed to market. I think that applies to project, programs and strategies.