IT on Steroids: The Benefits (and Risks) of Accelerating Technology

August 12, 2013 Editor 0

In 1998, RIM launched the BlackBerry. A year later, the second version got a full keyboard. Apparently, that was the feature users had been waiting for. Demand for the BlackBerry 850 soared. By 2004, RIM had acquired 1 million subscribers and only three years later surpassed the 10 million mark. In 2007, RIM celebrated its 12 millionth subscriber and generated $1.67 billion in revenues. The same year, Apple launched its iPhone, featuring a touch screen and better web browsing. In 2008, RIM tried to match the new competitor. However, the new handset, its software, and the available applications all failed to excite critics and customers.

When it comes to innovation in industries with strategically narrow windows of opportunities, speed is everything. RIM is just the latest company to learn this lesson. Before it, Motorola and Palm suffered similar fates.

This quickening pace — what academics and journalists have called innovation on steroids — is beginning to reach IT departments.

The first big change in the speed of IT delivery was the proliferation of “as a service” offerings. To date, the trend has been associated with fairly standard products, such as customer relationship management software, web servers, or SQL databases, but the theory of the innovator’s dilemma suggests that it will most likely move up the stack in the future. Disruptive innovations begin at the low-margin, high commodity end of the stack and move upward over time, and IT is most likely not going to be an exception.

Most CIOs will benefit from this trend through increased competition, better prices, and quicker provisioning. At the same time, the trend also heightens the expectations of CIOs’ internal customers to deliver better solutions at greater speed.

A second accelerant of IT delivery is the iterative software development philosophy known as “agile development.” While the definition of agile is still very broad, at the core are values of flexibility, individual interaction, focus on outputs, and collaboration over more rigid planning-driven approaches. While not as old and not yet as mature as cloud systems, it warrants a closer look. Agile projects have focused on standard, non-critical systems. The crucial question is whether the method can be successfully scaled. To the extent that agile becomes the default method to build large-scale IT projects, demands to speed up the delivery of IT projects will increase. In turn, the corporate IT project portfolio needs to adapt.

These pressures to speed up IT delivery come not a moment too soon. Research has shown that the longer an IT project, the higher the risk of cost overruns and further schedule delays. It showed that the longer the project, the higher the requirements volatility and in turn the higher the project risk. One implication is that any project management method that is based on the assumption that requirements can be frozen has set itself up for failure — another good reason why agile might be here to stay.

Our own research has further looked at the problem. The preliminary results of a survey of nearly 4,300 IT projects revealed that long project schedules increase risks across all project types, not only in software development projects. Furthermore, we found that the longer a project, the higher the risk of the project turning into a Black Swan. A Black Swan is a project that runs out of control and incurs massive cost overruns and schedule delays. Every year of additional project duration increases the odds of a project turning into a Black Swan by 27%.

The speed of IT project delivery is increasing, and it should improve project performance and reduce risks. Yet, the trend is not free from potential downsides as the case of a large multinational telecommunications company illustrates. The newly minted CIO implemented a simple policy to curb the ever-growing cost overruns and schedule delays that plagued the company’s IT project portfolio: no projects longer than 12 months. Other decision-makers have gone even further: the state government of South Australia recently declared it would only start IT projects estimated to take less than 90 days.

This simple tactic is seemingly backed up by the research. However, the policy, in the telecom’s case, had unintended consequences. The announcement that only short projects would be approved led to a preference for small, piecemeal innovations. Most focused on cutting IT costs. Unintentionally, this selection bias added complexity to an already complex IT architecture. After four years, systems had been tinkered with so much that new product launches became not only prohibitively expensive but also needed a very long time to market. Innovations were virtually prevented by stifling complexity. It took another very large IT project with all the risks that come with it to clean up the IT architecture, reduce complexities, and regain the capabilities needed to compete in the future.

The case shows that a successful strategy requires a CIO to know when the IT organization can and ought to go fast to reduce risks and when the organization needs to go slow, even if that implies higher risks.

One might argue that viewing IT projects solely as budget items on a calendar is too much of an abstraction to capture the intricacies of decision-making and delivering IT projects. Yet, we observed that IT projects are planned and supervised with very scant information. Basic budget and scheduling data are important signposts to steer the IT project organization. A CIO must know when the IT organization can and ought to go fast and when it is better to push back against the powerful forces that demand IT to deliver faster and faster. In short, strategic IT leadership in a high-speed world is about mixing fast and slow.

Go to Source

Categories: HBR, Insights

Tags: agile development, Black Swan, disruptive innovations, iterative software development