Editor’s note: Oliver Olsen is an independent seeking election to the Vermont House for the Windham-Bennington-Windsor district, a seat he previously held from 2010-2013, as the Democratic, Republican, and Progressive nominee. He lives in South Londonderry from where he manages a global consulting practice for a leading provider of cloud software applications for large enterprises.
If there was ever any question that Vermont’s health care exchange website (known as Vermont Health Connect) was in trouble, recent events have removed all doubt. In case you missed it, the governor’s administration temporarily suspended the Vermont Health Connect website, for several weeks, so that improvements can be made to the site.
Someone recently asked me why Vermont has had so much difficulty implementing major information technology (IT) projects (the exchange is but one recent failure), considering that equally ambitious road and bridge construction projects seem to come together without the same challenges. As someone who has spent nearly all of my professional career in the technology industry, I have seen my fair share of successful and not-so-successful IT projects, large and small, in the public and private sector.
The sad reality is that the failed roll-out of Vermont Health Connect is hardly an anomaly in the world of IT projects. In fact, a recent report from an analyst in the IT industry concluded that 28 percent of all large IT projects end in failure.
What makes IT projects so challenging and why do so many end in failure?
At the core, there are three issues:
• the IT industry is relatively immature;
• software technologies, tools, and techniques evolve rapidly; and
• software is inherently abstract and deals with intangible objects that are hard to grasp.
Starting with the first issue, think about how long the IT industry has been around vs. the civil engineering and construction industry. The first digital computer was only developed during World War II, while humans have been building roads and bridges for millennia. With experience, we learn from past mistakes and avoid repeating them. Think of the historical monuments that still remind us of what not to do — e.g. the Leaning Tower of Pisa (don’t build on unstable ground).
Not only is the IT industry new, but the technologies, tools, and techniques evolve rapidly. Fifty years ago, computer programs were developed on punch cards and ran on computers that filled entire buildings. Ten years ago, enterprise software ran on desktop PCs and servers. Today, enterprise software is moving into the cloud.
Without knowing all the details of what is going on behind the scenes at Vermont Health Connect, it is hard to say with any certainty how big the problems really are, but shutting down the website is certainly a drastic measure that speaks volumes.
In the construction trades, many things are generally predictable and can be estimated with relative accuracy, since we have thousands of years of experience using the same basic tools and technologies. For example, we know the mixing proportions for concrete, the time it takes for concrete to cure, and how much load a concrete structure can handle at different thicknesses. While there have been improvements over time, the fundamentals of concrete are not much different than they were a thousand years ago. But in the IT industry, the experiences from a project 10 years ago may no longer be relevant on a project using a completely new set of technologies and tools today.
One thing has not changed since the dawn of the computing age — the reality that software is abstract and deals with intangible objects. Unlike physical structures, it is hard for humans to visualize the complex data schemas, calculations, control structures, and processes that collect, transform, organize, and move large volumes of information in the world of software.
When dealing with abstract concepts, it is much more difficult to identify missed requirements and functional gaps until it is too late. In the physical world, a missing feature sticks on on a blueprint or scale model, but in the abstract world of software, if the feature is not explicitly described in the design, its absence can easily go unnoticed. Here lies the source of many — if not most — IT project failures: the project requirements are not fully understood at the start of the project; they only become apparent once the system is in the latter stages of testing or in production. The cost of “fixing” the production system to accommodate these missed requirements is on an order of magnitude greater than if they had been fully understood during initial design.
To illustrate this point, consider what might happen if you tried to construct a bridge over a river with some of the same challenges that exist in the software world.
In the normal course of events, you would start by hiring an engineer and conduct a site visit, where you and the engineer would discuss your requirements. The engineer would probably develop a rough sketch of what the bridge might look like. After reviewing the sketch, you might suggest a few changes, and the engineer would proceed to developing a more comprehensive set of blueprints and possibly a scale model.
Standing on the edge of the river, you and the engineer would review the blueprints against the backdrop of where the bridge will actually be constructed, and get a real sense for what it might look like. With the design work complete, a construction firm would begin construction, and you could watch the bridge take shape from start to finish.
But imagine trying to build that same bridge without actually being able to visualize the blueprints or see the bridge take shape while under construction. What if you were miles away from the river and had to provide your requirements to the engineer over the telephone, and could not see the blueprints or a scale model of what the new bridge might look like?
You call the engineer, who is standing at the edge of the river, and tell him to design a bridge that can carry traffic in both directions across the river. The engineer goes away and designs a two-lane bridge that can support passenger vehicle traffic. While he is drafting the blueprints, he realizes that there had been no discussion of whether the bridge needs to accommodate pedestrian traffic or large trucks. Seeing no evidence of pedestrian activity near the bridge, he assumes that this is not a requirement and does not include a sidewalk in the design. Similarly, he assumes that since you did not specify a requirement for the bridge to handle large truck traffic, he does not have to worry about vertical clearances. For the final design, the engineer decides on a small truss bridge.
With the blueprints complete, the engineer calls you back. He describes, as best he can, what the bridge will look like, and confirms that it will accommodate traffic in both directions. You give him the order to start construction. Several months later, construction comes to an end and the bridge is ready for traffic. The engineer and his coworkers drive across the bridge and declare the project a success. You drive down to the bridge to see for yourself, and that’s when you start to find problems.
You immediately notice that there is no sidewalk. While there is no pedestrian traffic in the area today, you know that pedestrians were expecting to cross the bridge on foot once it opens. While you are inspecting the new bridge, a large tractor trailer tries to cross the bridge, but cannot due to a low hanging truss. There is no easy fix for either problem — the bridge is not wide enough to accommodate sidewalks and the truss over the bridge is integral to the superstructure. While these two requirements could have been addressed with minimal incremental cost to the project if they were identified in the design phase, the cost of addressing these requirements post-construction is actually greater than the entire original project, since much of the bridge would have to be rebuilt.
This is obviously an exaggerated example, but it illustrates some of the most frequent challenges that lead to project failure in the IT world.
Without knowing all the details of what is going on behind the scenes at Vermont Health Connect, it is hard to say with any certainty how big the problems really are, but shutting down the website is certainly a drastic measure that speaks volumes. The effort required to fix problems will not be trivial, particularly if the underlying system architecture is flawed, but expectations management may prove to be an equally daunting task.
