Business @ The Speed of IT—Three Theories

My previous post discussed how IT continually struggles to deliver in exactly the two areas the business most needs it to: (1) timely solutions that boost business innovation, when and as they’re needed; and (2) the ability to quickly adapt existing solutions as business needs change.

Whether it’s appropriate to call these “IT failures” or not, they’re certainly not glaring successes. And more importantly, they pose very real business concerns, so it behooves us as IT leaders to understand their root causes, and consider how to overcome them to maximize the return on the business’s investment in IT.

The Three Theories

There are roughly three categories of explanations for these issues:

1. Management failures—the view held by many in the project management community.

2. Inadequate business analysis, requirements, or funding—the root cause favored by the IT governance crowd.

3. Solution complexity—the preferred explanation of many technical folks.

And, the obvious 4^th hypothesis: all of the above.

Clearly, bad management can kill any project, including those in IT. Similarly, shortcomings in analysis, requirements, and funding have caused no end of problems for IT, just as they do for all types of projects. But these causes can’t account for the unusually high “failure” rates we see in IT, nor for the consistency of these data over so many decades of IT history.

The complexity argument seems to better withstand scrutiny. Where IT differs from so much of the business world is in its inherent and extraordinary complexity, and this, I think, is the best place to look for root causes—and for enduring solutions.

Changing Course

For starters, though, let’s note that to a large extent IT’s two core issues are merely two different but related symptoms of the same underlying causes. There’s no real mystery here. At its most basic, these issues are due to natural forces—it simply takes less time to ask for a change than it takes to deliver it.

The captain of an aircraft carrier may order a course correction, but it will take some time to make it so. This is neither a management issue, nor a funding issue. While those can exacerbate the difficulties, this is primarily a function of the design of the ship, coupled with its inertia.

And, notably, it has almost nothing to do with how the ship was manufactured. (I’ll have more to say about this in a future post.)

This seems obvious when discussing ships, but the lesson sometimes gets lost when talking about IT’s systems.

But it’s not quite so simple. Of course, when changes are required, it takes some time to build the required changes. The scope of the changes must be understood and managed (and both can be hard). In addition, a given change may impact any facet of the overall systems landscape. Whether inserting a new capability or changing an existing capability in substantive ways, changes can break any number of things that worked before—existing functions, old (and often hardcoded) business assumptions, process assumptions, integration strategies, legacy technologies, or <your favorite problem here>. So IT must also ensure that everything else still works as it should, and this can take a fair bit of added effort.

And this gets still more problematic when the end result must be robust and reliable—in other words, more or less every time.

In a series of future posts I’ll discuss how complexity causes IT’s struggles, what specific types of complexity are to blame, and how these complexities can be managed to prevent these issues in the future.