Change: Business as Unusual?

Like many other professions, enterprise IT has its own language, jargon, and acronyms. One of them is "BAU", standing for Business as Usual. Wikipedia has a relatively short entry, which nevertheless provides us with an important insight: the normal execution of standard functional operations [...] - forms a possible contrast to project or programs which might introduce change.

As we find out, there's a base assumption behind this seemingly innocent term: "business as usual" means not changing. I guess that leaves us with change as "business as unusual". As always, it pays to have a closer look at what's behind this play of words.

Projects

If change is unusual, the natural reaction is to control it as much as possible. That is usually achieved by packaging change into a project, which undergoes a series of approval and review steps, such as budget approval, business case review, steering meetings, etc. These mechanisms are in place to minimize the project risk as change is seen as something unusual and risky. When the project is finished, the software is launched ("go live") and things return to business as usual. Plotted on a timeline, this way of working looks roughly like this:

Products

Most "digital" organizations have a different view: they see change as normal and are rightly afraid of not changing because they know that the world around them keeps moving. It's like sitting on a standing train when the train on the other side of the platform leaves - you feel like you are going backwards.

Based on that realization, these organizations don't try to package change into compartments (aka "projects"), but rather build products that evolve, i.e. change, continuously, as depicted below:

Some important differences

Now some people would say, this is a nice play on words, let's move on. Other organizations simply declare "we work on products, not projects" without changing much of the underlying structure. Both would be missing the important point behind the distinction between products and projects - the two are fundamentally different.

The Target

Projects generally assume that there is a defined target state. This target state promises a certain level of improvement (increased revenue, better customer satisfaction, lower cost, etc.), which justifies the business case for the project. If the targeted improvement is delivered, the project is considered a success.

As we learned in my previous post ("There is no target picture"), though, this base assumption may no longer hold in the fast-moving digital world. Products don't assume a specific target state but are based on the assumption that you are in a state of constant change, so they are more suited to the fast-moving digital world.

The Launch

Another critical difference lies in how the release is viewed. In the project mind set, the release is the "launch", which is the beginning of putting the software into production. Usually, there's a party as this means the organization safely leaves the abnormal state of change and returns to the comfort of business as usual.

In the product mindset, the final launch has a very different connotation: in a continuously changing world, no longer releasing means sunsetting the product. It may live on for a little bit, but it is essentially left to slowly die. So the final release isn't a launch party but rather a eulogy. When does Gmail end? Hopefully never. Google Wave did end...

Absolutes vs. Rates

A common concern when talking about products comes from the finance side of the house: how can you possibly budget for a product if you don't even know how long it's going to run? That's where a critical difference in mindset surfaces: a product-oriented organization thinks and speaks in rates (values over time) as opposed to absolutes. While a traditional project has a total budget, a product has a burn rate, i.e. spend over time. Instead of a business case based on fixed end state, they talk about run rate improvement.

When rate of change is your critical measure, as it should be in the digital world, then it make sense to look at the rate of things, not absolutes. This means, however, that calling your efforts "products" doesn't mean much if you don't fundamentally change your way of thinking and budgeting.

The platform underneath

At a recent workshop in Perth, a very smart gentleman asked how the product model works with an IT infrastructure that follows a cycle of heavy up-front invest followed by 3 to 5 years of depreciation? The straight answer is: it doesn't work very well. This is one of the reasons that folks following the product mindset, which includes most startups and fast-moving companies, favor a cloud model. A cloud model is consumption-based, so it's based on a rate, as opposed to investment-based. This is another example how cloud isn't just about infrastructure, but a different mentality.

Does it work in IT?

A lot of IT folks may posit that the product mindset coupled with the thinking in rates of change wouldn't work for them, common arguments being the lack of spend control. I'd say that once you embrace the model you have actually have better control as you control the burn rate at any time whereas a project that's funded tends to run until the money is spent before it starts creating value.

The major hurdle for companies aiming to adopt the product model lies in the fact that it isn't a simple change of terms, but requires a fundamental shift in thinking. Organizations that don't make that shift won't be happy with this model - the lipstick on the pig is going to wear off rather soon. One key impediment is that classic IT has an aversion to run cost and has been told to keep the run cost down. More on that in the next post.

Don't miss a post!

If you like what you read, please share with your network and follow me on LinkedIn or Twitter. You can also find more thoughts and anecdotes from the trenches of IT Transformation in my book:

• DRM-free e-Book (Kindle, iPad, Android, PDF): architectelevator.com
• Print-on demand via Amazon US, Amazon UK, Amazon Europe

Lastly, the market with a train running through is the Rom Hoop Market in Thailand, less than a 2 hour drive south of Bangkok.