Why large systems integrators sometimes fail to deliver government projects

In 1957 Joe Bohlen and and George Beal, both at Iowa State Collage, began to look at how technology was adopted in farming communities, how markets are created around new technologies and how that leads to broad adoption of that technology as people start to understand the role it will play in improving their work or play.

What they came up with can be easily summed up in a graphic that many of you will recognize as the technology adoption curve, essentially breaking up the cycle of innovation adoption into five distinct segments.

The Wikipedia entry on the TAC shows how the breakdown of these segments applied to the farming communities that Bohlen and Beal studied.

• innovators – had larger farms, were more educated, more prosperous and more risk-oriented
• early adopters – younger, more educated, tended to be community leaders
• early majority – more conservative but open to new ideas, active in community and influence to neighbours
• late majority – older, less educated, fairly conservative and less socially active
• laggards – very conservative, had small farms and capital, oldest and least educated

The technology adoption curve has been used in many texts and studies since then, you may be familiar with Everett Roger’s Diffusion of Innovations, or Geoffrey Moore’s Crossing the Chasm.

Moore in particular does a great job of mapping each of these segments to the issues that we face in marketing modern day computing technology, how we kick start markets then prepare ourselves to “cross the chasm” that exists between each of the segments, addressing the different ways that innovators think compared to the early or late majority for example.

Over the years I have used the ideas that Moore puts forward to construct organizations that take Microsoft into new markets, while preparing us for the inevitable pressures that we face in terms of scale as we move from early adopters to that early majority stage, ensuring that we have the right materials and organizational structures in place to address the needs of those segments.

I’ll use adoption of our own products as an example, after watching various product cycles over the last fifteen years it is something I have become pretty familiar with.

The enterprise side of Microsoft’s business model is predominately partner led, and it is quite easy to work out how to apply this model to the way that we bring new products to market alongside those partners.

You will generally find the product development groups working directly with enterprise customers in the innovator stage, carefully looking at the role the new product will play in their data-centre environment and applying development and support resource directly to ensure that the product meets the customers need and works in their environment.

For the early adopters we have Microsoft Consulting Services, our own consulting group who specialize in developing skills around the use of new products alongside these early adopters, building understanding around scaleable deployment, interoperability with other products in their data centre and how to architect solutions that make best use of the new product. It is still pretty rare that you see many of our partners involved at this stage, some obviously do include themselves but risks are high at this stage and services profitability is generally pretty low.

In the early majority stage you will find our Microsoft Consulting Services group, or often just the materials that were delivered through the work with the early adopters, working more with partners rather than directly with end users. The goal here is to begin to see capacity build up in the 1.2m partners that we have so that they can carry the product forwards into the wider base of end users in the general market.

From there Microsoft’s work is generally done, market forces do their thing from that point. Through the late majority segment you will see partners continue to build skills and customers increase the pace of adoption. Much of what Microsoft has learned at that point is documented in the public knowledge base, or fully understood by our Premier and Product support groups.

Throughout the lifecycle you see the growth in understanding and capability that is vitally important for delivery on the scale that will be needed as a technology hits the peak of the curve.

These are basic market dynamics.

However, the government market is different and in many cases because of the expectations upon government and the size of the systems involved has to begin with the dynamics we find in the late majority segment of the curve.

For obvious reasons the experimentation that is needed in the earlier part of the curve can be frowned upon when it comes to complex government systems. Innovators are out there, but they are hard to find in many geographies, the risk can be just too high. When you do find innovators they are rarely working with the same multi-national systems integrators who will eventually deliver the  technology on a scale that meets the needs of the whole of government.

The smaller companies work with the scarce number of innovators and build the skills needed to understand the technology, but do not have the manpower to deliver broadly across government. The larger systems integrators have the manpower, and while often winning the contract to deliver against a large government requirement often do not have the skills that they need to do so, nor do they have any market led way of building those skills.

It is often much easier to spot this broken dynamic in markets where large scale system integrators dedicate their capability to broad delivery in just one or two segments of government, such as healthcare or military systems. In essence these providers are forced to jump into the middle of the technology adoption curve, missing out on the natural growth in capacity that would have occurred in the innovator, early adopter and early majority segments of the TAC.

It is hard to see where some of the large systems integrators will build the skills they need to deploy some of the new technology that government is looking for without waiting for those skills to be generally available in the marketplace and then hiring in new people. While this reduces the level of risk for everybody involved, it also means that government will rarely get to take advantage of recent innovations.

When thinking in those terms it becomes pretty easy to work out why a systems integrator, deploying a technology that has yet to pass the centre of the curve, will often fail to do so.