Complexity vs. goodness in IT failure

Stories about failed IT projects often describe convoluted and confusing situations that are difficult to sort out and understand. This confusion and lack of clarity arises from two primary causes: unclear strategic goals or inability to bring together the moving parts that comprise project execution.

It's surprising that many teams start projects without a clear understanding of the end game and goals they are trying to achieve. A family-friendly blog such as this won't be mean-spirited and say these folks have their head up you know where.

Successful strategy brings clarity (and relevance) of purpose, while solid project execution means managing people, teams, and stakeholder groups each with its own unique definition of success. For example, IT may seek high project throughput while the accounting department demands more software features. These goals are in conflict.

This simple diagram illustrates the point mapped to a scale of complexity and goodness:

On one level these points are simplistic and obvious. However, there's a large gap between our ability to understand these simple concepts and then apply them to real world situations. That's why so many projects fail.

[Inspired by The Simplicity Cycle by Don Ward. For more of this logic, also see Choices = Headaches by Joel Spolsky. Thanks to Dermot Casey on Twitter for pointing me to the Ward book. Diagram by Michael Krigsman.]