Thinking about change

All projects involve change, an outcome of some sort that can be measured as a difference between the initial state and the end state of something.

All change involves risk. At a level of abstraction, project management may be seen as the means by which something is progressed from initial state to end state while mitigating the risks and while staying within given parameters of time, quality, cost.

For many years I worked in the banking sector, sometimes indirectly, sometimes directly. When I was at Dresdner Kleinwort, we “froze” the systems estate in the lead-up to the euro and to the Year 2000.

Nothing moved.

And nothing broke.

And no progress was made.

It used to be said that nothing is certain but death and taxes.

For some time now, there has been a third.

Change is now a constant. It may sound trite and soundbitey, but that does not alter the fact.

IT departments the world over have grappled with change all their lives, even when they masqueraded under names like MIS and DP. The quantum of change may have varied; the ratio of investment in change (as compared to investment in improving the status quo) may have varied; but change happened nevertheless.

Some changes are cultural, transformational, real shifts. Some changes are global, some sectoral, some geographical, some restricted to a given company or even department. Much has been written about change and the management of change. Much has been written about the agents of change. Much has been written about the toxins that emerge when complex systems are placed under the severe stress of change, and how to handle those toxins.

Over the years, people have learnt a lot about IT systems and change. How the change has to involve people, process and systems. How the change process needs to be designed with the right communications and training plans, so that the change is actually sustainable, and sustained.

This post is not about any of this. Or perhaps it’s about all of this.

The IT industry has always been about change. About progress. Quite often, the material value of the progress was intercepted by intermediaries rather than made available to end-customers. But there was always change. And value created by the change.

And resistance to change. Particularly in the enterprise.

Direct dial phones in the early 1980s. PCs in the mid 1980s. Nonproprietary “open” systems in the late 1980s, along with outsourcing. Internet connections in the early 1990s. The web a couple of years later, along with offshoring. Mobile phones around the same time, the mid 1990s. Web mail a few years later. Java, Linux, opensource software in the late 1990s; push mail around the same time. The cloud in the early 21st century. Social software a few years later. Tablets and touch more recently. Every one of these changes were vehemently opposed by the immune system of the enterprise, playing out the same cards in the same sequence: it’s not secure; it’s not robust; it’s too expensive to change; it breaks regulations. The same objections, in the same order.

Technology adoption tends to happen in three phases: substitution, increased use, embedded and differentiated use. So there is usually a problem to solve, something that is currently being done some other way, something that will be substituted and come to an end of its life. So there is usually an “incumbent”, a way of doing something, either as a formal function or as a workaround. And people are invested emotionally in that incumbent. [Especially those whose livelihoods rely on that incumbent].

Over a decade ago, Clayton Christensen set out the reasons for this incumbent reaction in The Innovator’s Dilemma, and continued with the theme in the rest of the series.

More recently, as I’ve seen the misinformation and disinformation thrown around about the cloud, I’ve been thinking harder about the decision process within organisations, and how incumbents mangle and mutate those processes. Much of what I saw reminded me of the core thesis in Pip Coburn’s excellent The Change Function, which broadly states that technology change projects succeed if and only if two conditions are met: there is a clear problem to solve; and the cost of the project is less than the perceived cost of changing from the status quo.

It’s now almost a year since I joined Salesforce.com, an incredibly exhilarating time, frenetic yet ultimately very fulfilling. Because I now see the possibility that end-customers will actually see the benefits of technology advances affect their wallets, actually put money in their hands, much like Skype did for long-distance telephony. We’re seeing the price of commodity infrastructure, both hardware as well as software, drop precipitously; and, unlike the past, we’re seeing those price changes benefit the customer.

More precisely, those customers who take advantage of the progress; for there are always some who buy the incumbent argument on security or performance or robustness.

The effect of this is to buy time for the incumbent; often, this time is used to influence regulators in order to buy more time. And the customer loses out.

Which is why, for the last three months or so, I’ve been spending time thinking about all this.

And I’ve come to realise something, something I thought I’d already learnt and internalised, but obviously something I have to keep learning.

The cloud is not just about flexibility of access to compute power and storage and bandwidth, or about avoiding the thankless tasks of software installations, maintenance and upgrades; mobile is not just about ubiquity of access; cloud and mobile, together, are not just about the ability to “shift time” and “shift space”; social is not just about getting closer to the customer, about valuing relationships and capabilities; open is not just about the transformation of innovation, about partnering, about collaboration across boundaries.

The cloud paradigm is about all of this.

And about one more thing.

The capacity to change. Designed as an integral function. Native.

Changing capacity, scale, coverage, product set, devices, whatever. The cloud is about launching products, scaling them up, scaling them down, discontinuing them. The cloud is about entering …. and exiting … markets. The cloud is about delivering services to the device of choice; even if it didn’t exist when the original design was made.

The cloud is about change. Not about the steady state.

IT before the cloud was all about preserving and maintaining the steady state. And that’s why so many projects failed, and will continue to fail. A conflict of philosophy, as the agents of change try to batter down the walls of the mechanisms implemented to protect against change.

The monolithic systems of the past, largely concentrated on the back office, were built to achieve entirely different objectives: stable, repeatable processes executed at the lowest cost possible, designed to rebuff change.

The cloud is about change.

If you don’t value the ability to change, if you feel you don’t need to change, and change rapidly, then you’re not going to value the cloud. Because your perceived cost of changing will exceed the perceived benefit.

Soon, TCO calculations will include the change premium, the cost of responding to change in market conditions and needs.

Soon.

But before that, a number of firms will die. Because of their inability to change in time.