Category Archives: Strategy

Three questions you need to ask

There's three questions you need to ask yourself before you invest a large chunk of cash in some enterprise application:

  • Can I use something, rather than configuring something, rather than customising something?
  • How will the solution support the (social) community who will use it?
  • Is there a reason why I can't buy the solution ‘on-demand’ via SaaS?

Continue reading Three questions you need to ask

Is Salesforce.com already legacy IT?

The more I think about it, the more I feel that we need to rethink what “application” means.

The IT industry – and therefore “application” – has been defined by businesses’ need to acquire IT assets. The roles companies play in the industry have accreted around this need, as I’ve pointed out before{{1}}.

[[1]]Business models for the old rules of IT @ PEG[[1]]

The big shift we’re seeing in the market at the moment is a move from companies wanting to acquire IT, to a need to engage services enabled by IT. I know, for example, one airline that has externalised flight planning and pays per flight plan, rather than worrying about the tools need to support a team of flight planners. It’s a capability and process centric view, rather than a technology centric view.

If we follow this line of thought through then we quickly realise that the future of IT in business will be determined by the need to knit together a fabric of IT enabled services, many of which will be obtained externally. I don’t need a project portfolio management solution, I need a portfolio management capability backed by the tools and skills required to make it work. I don’t need a CRM solution (SaaS or not), I need a sales management and reporting methodology (Holden? Miller Heiman?) supported by technology to enable it to scale. It’s outside in thinking, rather than inside out.

What will the industry that accretes around this new need look like? If we look at many of the current on-demand / SaaS vendors, then they could best be described as enterprise software, but in the cloud!. Take the old model and make it multi-tennanted. We should probably call this Cloud 1.0 (where MySpace was social media 1.0). Cloud 2.0, however, will be something different and might be just over the horizon, rendering the current incumbents obsolete, legacy while they’re still young.

The myth of the inevitability of social organisations

In the rush for the new-new thing we’re confusing the means with the end. Business – as currently practiced – has been built around the need to own and manage a central asset. This might be a factory, some IP or even a skilled team. The tools, technologies, and methods we deploy in business are used as they cause the business (the asset) to perform better: bottom line down or top line up, simple stuff. This seems to have been forgotten. Some of the newer tools – such as social business design – can add value in this content, but they are only tools. If they make sense and add value, then they will be adopted. If not, then they will wither and die. For many companies, it looks like they will only provide marginal utility.

Martin Linssen{{1}} seems to have started something of a storm on the Internet by pointing out that the emperor has no clothes{{2}}. He was responding to the noise around “social business design” and “enterprise 2.0”. Dennis Howlett{{3}} then published a nice missive{{4}} that builds on Martin’s observation.

[[1]]Martin Linssen[[1]]
[[2]]the emperor has no clothes[[2]]
[[3]]Dennis Howlett[[3]]
[[4]]Enterprise 2.0 is beyond a crock. It’s dead.[[4]]

The clarity Dennis brought was to highlight that, in the quest for the new-new thing, many marketing machines and practitioners have forgotten that for these tools to be adopted they need to add value, and that it’s hard for them to add value in the command-and-control structures that exist in most companies.

As Dennis astutely said:

When you get down to the nuts and bolts of the problems that prof McAfee correctly identifies but for which no amount of technology will solve it is really simple: the kinds of management and structures you need in order to make these ideas work in a sustainable manner is almost non-existent. Command, control, power and status have a huge part in this. And no amount of putting lipstick on those organisational pigs will change the fundamentals. In one well known case I still see individuals being taken to one side and asked: “Did you really have to say that? It’s not what we expect from people in your position.” Insidious isn’t it?

Today’s business are built around the concept of managing a central asset. This asset might be a factory, it might be a fleet of trucks, the deposits from a community of investors, it might be the methodology and tools a skilled team use, or it might be a brand. Regardless, structures are defined and people hired to support and drive this central asset, and not for any other reason.

Some companies, such as Zappos, have successfully used tools like social media to drive value by improving customer service and reaching customers earlier in the buying process. The problem is that companies Zappos and its ilk only represent a small proportion of the business community.

Think of the contract manufacturers who make the clothing that Zappos sells, or the outsourcers who run the supply chains to and from Zappos’ warehouse. These companies are trying to sweat an asset – the factory or a fleet of trucks and planes – and are usually chasing costs, often by moving to second or third world countries where wages are lower, or by automating first world jobs.

It’s the need to manage a central asset that has driven them to create these vertical command-and-control structures. Sometime the nature of this asset is compatible with the trendy new method – as with Zappos, social business design and enterprise 2.0 – but often it’s not. Yes, these companies could be better run (strangely enough, most companies are average), however, telling these companies to up-end their business models just doesn’t make sense. They’re focused on managing that central asset and there is currently no proof that these new techniques can do that any better than existing practices. As Dennis pointed out, the kinds of management structures to use these new tool in this context don’t currently exist.

Unfortunately the pundits are assuming that a few exceptional companies and individuals represent something the general business community should adopt as is. They are also mistakenly assuming that the claimed benefits – such as “improved communication and customer engagement” – requires us to deploy their favourite technology, tool or methodology.

Quest for the new-new thing
Quest for the new-new thing

Being better at the basics is more important. I know one executive that I had enough trouble convincing to get out of the office to say “Hi!” to his team who were only ten minutes away: he didn’t see the need to communicate with them. There wasn’t any point in even trying to convince him to use any sort of social media tool.

So we need to get a few things out in the open here.

First, social media, enterprise 2.0, and social business design do have the potential to provide value to a business. The case studies are out in the open, so there’s no arguing about this.

However, and second, is that these case studies represent the special case, and not the general case. YMMV{{5}}.

[[5]]Your Mileage May Vary[[5]]

Thirdly, we also know that social media, enterprise 2.0, and social business design require a different approach to command-and-control. Let’s avoid the value judgements as to whether this is good or bad, it just is.

So finally, and fourth, for mass adoption across the entire business community we must acknowledge that the foundation of many companies’ business models needs to change if these new tools are to add value. Zappos makes these tools work, as Zappos’ central asset is their brand, and brand (as an asset) benefits from these tools. Other companies – and this is probably the majority of companies in the business community – are not so lucky. They’ll see more benefit by focusing on the basics.

My view is that there is big shift that is currently building around the need to move away from the idea of a centrally managed asset as the foundation for a company. This is a big deal, as government regulation and accounting rules are built around the idea of a company owning a central asset. All the rules and regulation needs to be rewritten for this to happen. (Note to self: buy shares in accounting firms.)

The most likely new foundation for business is the ability to mobilise stakeholders – from employees, through partners to customers and the market in general. Your value will be defined by your ability to make things happen, rather than the assets you own. This would be world where all costs are operationalized, and our businesses look more like World of Warcraft than the hierarchal command-and-control structures of old. You, as an organisation, will be measured on the strength of your organisation’s social graph. Social business design will be the first port of call when designing your new business, rather than the last.

Until this shift happens it looks like social business design, social media, and enterprise 2.0 will be of marginal utility for many firms. Not useless, just less than revolutionary. However, I do think this (or something like it) will happen in the mid term. Someone will make it work in a private company, and then it will be copied. It will become increasing difficult for old school companies to compete with the new breed, eventually reaching the point where the old school pressures the government into changing the regulations and rules to suit.

Me, until the revolution comes I’m focused on getting out in the field and using all these tools in a new and interesting ways to create as much value as I possibly can, for both employees and the companies they work for.

How to cope with an IT transformation

Once started, an IT transformation is hard to stop. Such huge efforts – often involving investments of hundreds of millions, or even billions of dollars – take on a life of their own. Once the requirements have been scoped and IT has started the hard work of development, business’s thoughts often turn from anticipation to dread. How do we understand what we’re getting? How do we cope with business change between when we signed off the requirements to the solution entering production? Will the solution actually be able support an operating and constantly evolving business?

Transformations take a lot of time and huge amount of resources, giving them a life of their own within the business. It’s not uncommon for the team responsible for the transformation to absorb a significant proportion of the people and capital from the main business, often into the double-digit percentages. It’s also not uncommon for the the time between kicking off the project and delivery of the first components in to the business to be five years or more.

The world can change a lot in five years. Take Apple for example: sixty percent of the products they sell did not exist three years ago{{1}}. It’s not rare for the business to have a little buyers remorse once the requirements have been sign-off and we sit waiting for the solution to arrive. Did we ask for the right thing? Will the platforms and infrastructure perform as expected? Are our requirements good enough for IT to deliver what we need? Will what we asked for be relevant when it’s delivered?

[[1]]60 percent of Apple’s sales are from products that did not exist three years ago @ asumco.com[[1]]

Apple quarterly sales by product
Apple quarterly sales by product

The business has placed a large bet – often putting the entire company’s life on the line – so it’s understandable to be a little worried, and the investment is usually large enough that the business is committed: there’s no backing out now. However, the decision to undertake the transformation has been made, our bets have been placed, and there’s no point regretting carefully considered decisions made in the past with the best evidence and information we could gather at the time. We should be looking forward, focusing on how we can best leverage this investment once it is delivered.

We can break our concerns into a few distinct groups: completeness, suitability, relevance and adaptability.

First, we tend to worry that our requirements were complete. Did we give IT the information they need to do their job? Or were there holes and oversights in the requirements which will require interpretation by IT, interpretation which may or may-not align with how the business conceived the requirement when we wrote down the bullet points.

Next, we are concerned that we asked for the right thing. I don’t know about you, but I find it hard to imagine a finished solution from tables, bullet points and process diagrams. And I know that if I’m having trouble, then you’re probably imagining a slightly different finished solution than I’m thinking of. And IT probably has a different picture in their heads again. Someone is bound to be disappointed when the final solution is rolled out.

Thirdly, we have relevance. Five years is a long time. Even three years is long, as Apple has shown us. Our requirements were conceived in a very different business environment to the one that the solution will be deployed into. We probably did our best to guess what will change during the delivery journey, we can also be sure that some of our predictions will be wrong. How accurate our predictions are (which is largely a question of how lucky we were) will determine how relevant the solution will be. If our predictions were off the mark, then we might have a lot of work to do after the final release to bring the solution up to scratch.

Finally, we have adaptability. A business is not a fixed target, as it constantly evolves and adapts in response to the business environment it is situated in. Hopefully we specified the right flex-points – areas in the solution which will need to change rapidly in response to changing business need – back at the start of the journey. We don’t want our transformed IT estate to become instant legacy.

A lot of these concerns have already been address with ideas like rapid-productionisation{{2}} and (gasp!) agile methodologies, but they’re solving a different problem. Once you have a transformation underway, advice that you should hire lots of Scrum masters will fall on dead ears. While there’s a lot of good advice in these methodologies, our concern is coping with the transformation we have, not to throw away all effort to-date and try something different.

[[2]]Rapid productionising @ Shermo[[2]]

So what can we do to help IT ensure that the transformed IT estate is the best that it can be?

We could try to test to success, making IT jump through even more hoops by create more and increasing strenuous tests to add to the acceptance criteria, but while faster and more intense might work for George Lucas{{3}}, it doesn’t add a lot of value in this instance. Our concerns are understanding the requirements we have and safeguarding the relevance of our IT estate in a rapidly evolving business environment. We’re less concerned that existing requirements are implemented correctly (we should have already done that work).

[[3]]Fan criticism of George Lucas: Ability as a film director @ Wookieepedia[[3]]

I can see two clear strategies for coping with the IT transformation we have. First, is to create a better shared understanding of what the final solution might look like (shared between business and IT, as well as between business stakeholders). Second is to start understanding how the future IT estate might need to evolve and adapt in the future. Learnings from both of these activities can be feed back into the transformation to help improve the outcomes, as well as providing the business with a platform to communicate the potential scale and impact of the change with the broader user population.

There are a number of light-weight approaches to building and testing new user interfaces and workflows, putting the to-be requirements in the hands of the users in a very real and tactic way which enables them to understand what the world will look like post transformation. This needs to be more than UI wireframes or user storyboards. We need to trial new work practice, process improvements and decisioning logic. The team members at the coalface of the business also need to use these new tools in anger before we really under their impact. Above all, they need time with these solutions, time to form an opinion, as I’ve written about before{{4}}.

[[4]]I’ve already told you 125% of what I know @ PEG[[4]]

Much like the retail industry, with their trial stores, we can create a trial solution to explore how the final solution should move and act. We’re less worried about the plumbing and infrastructure, as we’re focused on the layout and how the trial store is used. This trial solution can be integrated with existing operations and provided to a small user population -– perhaps a branch in a bank, an single operations centre for back-office processing, or a one factory operated by a manufacturer – where we can realise, measure, test and update our understanding of what the to-be solution should look like, bringing our business and technology stakeholders to a single shared understanding of what we’re trying to achieve.

Our trial solution need not be on the production platform, as we’re trying to understand how the final solution should work and be used, not how it should be implemented. Startups are already providing enterprise mash-up platforms{{5}} which let you integrate UI, process and decisioning elements into one coherent user interface, often in weeks rather than months or years. Larger vendors – such as IBM and Oracle – are already integrating these technologies into their platforms. New vendors are also emerging which offer BPM on demand via a SaaS model.

[[5]]Enterprise Mash-Ups defined at Wikipedia[[5]]

Concerns about the scaleability and maintainability of these new technologies can be balanced with the limited scale and lifetime of our trial deployment. A trial operations centre in one city often need not require 24×7 support, perfectly capable of limping along with a nine-to-five phone number of someone from the development team. We can also always fail back to the older solution if the trial solution isn’t up to scratch.

Our second strategy might be to experiment with new ideas and wholly new models of operation, collecting data and insight on how the transformed IT estate might need to evolve once it becomes operational. This is the disruptive sibling of the incremental improvements in the trial solution. (Indeed, some of the insights from these experiments might even be tested in a trial solution, if feasible.)

In the spirit of experimental scenario planning, a bank might look to Mint{{6}} or Kiva{{7}}, while a retailer might look to Zara{{8}}. Or, even more interesting, you might look across industries, with a bank looking to Zara for inspiration, for example. The scenarios we identify might range from tactical plays, through major disruptions. What would happen if you took a different approach to planning{{9}}, as Tesco did{{10}} or if we, like Zara, focused on time to market rather than cost, and inverted how we think about our supply chain in the process{{11}}.

[[6]]Mint[[6]]
[[7]]Kiva[[7]]
[[8]]Zara[[8]]
[[9]]Inside vs. Outside @ PEG[[9]]
[[10]]Tesco is looking outside the building to predict customer needs @ PEG[[10]]
[[11]]Accelerate along the road to happiness @ PEG[[11]]

We can frame what we learn from these experiments in terms of the business drivers and activities they impact, allowing us to understand how the transformed IT estate would need to change in response. The data we obtain can be compiled and weighted to create a heat map which highlights potential change hotspots in the to-be IT estate, valuable information which can be feed back into the transformation effort, while the (measured, evaluated and updated) scenarios can be compiled into a playbook to prepare use when the new IT estate goes live.

Whatever we do, we can can’t sit by passively waiting for our new, transformed IT estate to be handed to us. Five years is a very long time in business, and if we want an IT estate that will support us into the future, then we need to start thinking about it now.

Planning should not require a Gantt chart

There’s a standard slide in my bag of tricks which finds it’s way into a surprising number of presentations. It’s a simple slide, one allowing me to explore the idea of planning as a spectrum of possible methodologies rather than treating planning as an either-or choice: either be bottom-up reactive, or requiring us to engage is a major top-down planning processes. By combining elements of both top-down and bottom-up approaches we can modulate how reactive, or how proactive and predetermined, our execution is. The idea is to set the slider where we want it, at the position that best suits what we are trying to achieve, instead of being forced to one end of the spectrum or the other in a purely reactive or purely deliberative mode.

A slide for our times
A slide for our times

Planning has a bad name. How many projects get stuck in that endless spiral of planning (and re-planning) as they try to find their way to the middle of the project hedge maze? It doesn’t seem to matter if we’re planning the expansion of our business into a new geography or a major IT transformation, the process drives us all nuts; wasted days and nights spent constructing (and then deconstructing and reconstructing) elaborate Gantt charts which we’re all sure will never be used.

All of this runs counter to what could be called the first rule of management:

Make a timely decision, and then make it work.

Most organisations’ first thought is to focus on being reactive and deal with the problems of here and now. Unfortunately this too has its own challenges. The Agile software movement can be seen as one well documented reactive methodology which has seen mixed success. Where time, scope and cost are negotiable, taking a reactive approach is the same as choosing to put scope up for grabs. The result of the project will be whatever the project manages to deliver, unsurprisingly. This might be enough to realise the original business case, or it might not.

A top-down, deliberative, approach is planning as a chess game (the untimed1)Types of chess games defined at Chess.net rather than the timed variety). We assume that we have complete information and can take as long as we want to formulate our next few moves. The more we know about our opponent — the more tacit knowledge we have about what might go wrong (and right) on a project — the better and more accurate our plans will be and the further into the future we can plan. We can measure and evaluate our current situation, use tools like scenario planning2)Martin Börjesson has put together some nice resources on Scenario planning to anticipate the future, or even hire an innovation consultancy to identify our next, disruptive move. In a perfect world the only limitation to our planning ability is our own ability to comprehend the problem at hand (or the number of tasks we can cram into a Gantt chart, whichever comes first).

The problem is the unexpected — the unpredicted (and possibly unpredictable) event — which makes our plans unravel. It’s the event that we didn’t manage to anticipate, invalidating our assumptions and converting a carefully crafted plan into wasted effort. The faster the environment changes the more likely it is that something unexpected will happen between the plan’s conception and the delivery of its final outcome. Even worse, we might not even finish planning before something unexpected pops up which invalidates our work to date, causing us to restart the planning process.

Take your average major IT transformation: a multiyear project involving a massive investment in both time and money. To kick-start the project we need to predict what the business will need when the transformation is finally delivered (and as I’ve said elsewhere, this is a challenge in itself3)I’ve already told you 125% of what I know @ PEG). If we’re lucky, then assumptions we’ve made about the business’s requirements will still hold true all the way through to the end. However, what’s more likely to happen is that the change orders will start arriving well before we’ve finished, possibly even we’ve completed requirements gathering. The team then struggles to divide their time between scheduled work and change orders before re-planning (and often re-planning again and again) to try and regain control of the project. Try as we may though, the end result is often more like coughing up a fur ball than the slick solution we originally imagined.

A reactive approach, on the other hand, doesn’t worry having about complete information. The focus is on reacting to events as they are encountered, with little thought to long term goals or strategy. A shotgun approach, as it were. We craft our strategy by creating a set of rules covering what we should do in all the circumstances we care about. See a stop sign? Stop. And so on. The challenge is to craft a set of rules which cover most eventualities, and this is a major focus of the “agile” methodologies. They try and craft their manifestos and playbooks to document the tactics — the rules — which they think will drive their projects in the right direction.

playbook [ˈpleɪˌbʊk]
n

  1. (Team Sports / American Football) a book containing a range of possible set plays
  2. a notional range of possible tactics in any sphere of activity

The American Heritage Dictionary of the English Language, Fourth Edition.

The unexpected is not a problem for a reactive approach: you simply deal with problems as they arrive. If you’re not expecting anything in particular, then whatever turns up must have been what your were expecting. (There is logic in there.) However, this puts you at the mercy of what does turn up; as you’re focused on reacting to events, the events which arrive (and the order they arrive in) determine where you end up. While cost and time (i.e. effort) might be fixed, scope (and therefor the final result) is up for grabs, making it hard to drive a reactive approach to planning to deliver a well defined outcome.

With it’s focus on incremental delivery and improvement, a reactive approach is not an obvious bedfellow for your major IT transformation. It’s modus operandi is to focus on shot term demands, understand what the business needs next, build that, and then iterate. The IT estate evolves (somewhat) organically as we add things here, patch things there, and generally muddle our way through. Yes, we are reacting to short term business needs, but at what cost? Its a bit like taking our hands off the tiller to leave ourselves to the mercy of the wind; our boat will probably stay afloat, as long as the weather isn’t too bad, but we have little control over where we end up. Without the ability to drive toward a clear, long term goal, we soon find that all the well meaning tactical decisions we’ve made have resulted in a giant fur ball, just like those occasions where we tried to drive the project forward with a giant Gantt chart.

Neither of these two approaches to planning are necessarily wrong; they’re just not suited to solve the sort of problems we’re dealing with in the new normal4)The new normal @ McKinsey Quarterly. They represent two extremes — proactive and reactive planning — but we need to balance proactive and reactive, and find a middle path.

First we need to admit that we’re resource constrained. This might be in terms of time, the funds we have available, or even simply the number of people we can usefully bring to bear on a problem. (As Frederick Brooks5)Frederick Brooks on the Mythical Man Month pointed, it might take one woman nine months to produce a baby, but we can’t expect nine woman to deliver a baby in one month.) And this is in an environment where meaningful business change is measured in months, if not weeks. The effort required to develop our plan needs to fit into the time available, and our approach needs to provide opportunities to regularly revisit our assumptions and allow us to react to changes within and without the project. We need need to be reactive, but not too reactive, as we need to work within an overarching framework so that we can have some confidence that we are working toward our long term goals.

People — that’s you and I — take a more pragmatic approach to planning. If we didn’t, then I couldn’t imagine that we would manage to make it through the day with everything we need to get done and the disruptions that we all deal with. Think about how you went to work this morning. (Or how you went to the local café for a coffee, if it’s the weekend.) You weren’t purely reactive. If you were then I expect you would still be lying in bed trying to sort out you manifesto and playbook, hoping for something to happen which will prod you in the right direction. Nor do you take an exclusively top-down, deliberative approach, popping open the laptop on your knee whilst in bed and firing up your favourite planning tool. You’d probably still be stuck in bed, working at the never-ending ending task of plotting exceptions and eventualities. (What should I do if the case of divine intervention?).

People take a middle road. We establish a clear goal, usually something quite prosaic, like:

Get to work (on time)

We have a clear understanding — a set of beliefs, things we expect to be true — of the context we need to do this in.

  • I’m lying in bed
  • it’s a weekday
  • the alarm has just gone off
  • the weather forecast was for a clear sky and sun
  • I’m feeling a bit pudgy today

We also have a library of plans — short patterns of behaviour — which we know that, either from experience or by design, will drive us toward our goal. For example, to get to work we might usually follow the pattern:

  1. get up
  2. shower
  3. get dressed
  4. eat
  5. commute to the office

where each of the steps in this pattern can also be goals themselves.

We might, for example, have a few different plans for commuting: one each for by car, by bike, via public transport, and so on. When it comes time to commute, we consider our beliefs (it’s sunny and I need the exercise) and choose what we think is the most suitable option (I’ll ride). If the option turns out to be a bad choice (one tyre on my bike is unexpectedly flat) or unsuitable due to some change in the environment (it starts raining when I’m less than a block from home), then you discard the plan and pick another (heading back to the garage to take the car). After all, we hadn’t invested much in developing or executing the plan so we’re not losing a lot by throwing it away.

The twisty path between us and our goal
The twisty path between us and our goal

The gap after each step provides us with time to pause and reflect, consider our goal, and respond to the environment by selecting how best to execute the next step. This ability to revisit our decisions frequently — at each step on the journey between the office and home — allows us to be reactive, but not too reactive, while the knowledge that each step is part of a large plan provides us with the confidence that we’re working toward our longer term goals. The more granular we make our plans the more opportunities we provide to react to changes in our environment, but at the cost of being less deliberative and proactive, and potentially less efficient. The more coarse grained we make our plans, the fewer opportunities we create for being reactive, by it allows us to be more deliberative and efficient in delivery.

By modulating the size of our plans — the size of the effort we commit to — we can set the slider where we want it on that planning scale, with reactive on one end, and top down deliberative. This lets us align our planning with the degree of uncertainty and change we’re seeing in the environment around us.

I’ve been using this approach to plan and manage business and IT strategies for some time, with a great deal of success. Most of the tooling required already exists in the business business world, tools such as strategy maps6)Strategy map defined @ Value Based Mangement by Kaplan & Norton, mission statements7)Mission statement defined @ The Centre for Business Planning, and project portfolio management tools. Using these tools we can clearly identify our goals, articulate the tactics we want to use to drive ourselves toward them, and then create a portfolio of work which realises the tactics.

For example, the mission of being a low cost service provider might result in a goal of having efficient operations (which we can measure via a benchmark), and the tactics we can use to deliver more efficient operations might include consolidation (reducing the number of offices, data centres, or event tools). We can realise this need for consolidation by identifying a set of small projects (such as shutting down a small data centre, and consolidating its servers into a major one), each of which delivers one step on the journey. These projects then become part of a larger portfolio of work, with the resources available and business priorities determining which projects are executed next.

Just like the example above of each one of us finding our way to work in the morning, this approach enables us to balance how reactive or proactive we are at any time. We can easily re-proritise in response to business change by updating the mix of projects to be executed, rather than through a major re-planning effort. At the same time, we can be sure that the portfolio of work is driving us toward our long term goals, as each project aligns with an organisational goal. Planning without a major Gantt chart.

References   [ + ]

1. Types of chess games defined at Chess.net
2. Martin Börjesson has put together some nice resources on Scenario planning
3. I’ve already told you 125% of what I know @ PEG
4. The new normal @ McKinsey Quarterly
5. Frederick Brooks on the Mythical Man Month
6. Strategy map defined @ Value Based Mangement by Kaplan & Norton
7. Mission statement defined @ The Centre for Business Planning

Some new rules for IT

The other week I had a go at capturing the rules of enterprise IT{{1}}. The starting point was a few of those beery discussions we all have after work, where we came to wonder how the game of enterprise IT was changing. It’s the common refrain of big-to-small, the Sieble to Saleforce.com transition which sees the need for IT services (internal or external) change dramatically. The rules of IT are definitely changing. Now that I’ve had a go at old rules, I thought I’d have a go at seeing what the new rules might be.

As I mentioned before, enterprise IT has historically been seen as an asset management function, a production line for delivering large IT assets into the IT estate and then maintaining them. The rules are the therefore rules of business operations. My attempt at capturing 4 ± 2 rules (with friends) produced the following (in no particular order):

[[1]]The rules of Enterprise IT @ PEG[[1]]

  • Keep the lights on. Much like being a trucker, the trick is to keep the truck rolling (and avoid spending money on tyres). Otherwise known as smooth running applications are the ticket to the strategy table.
  • Save money. Business IT was born as a cost saving exercise (out with the rooms full of people, in with the punch card machines), and most IT business cases are little different.
  • Build what you need. I wouldn’t be surprised if the team building LEO{{2}} blew their own valve tubes. You couldn’t buy parts of the shelf so you had to make everything. This is still with us in some organisations’ strong desire to build – or at least heavily customise – solutions.
  • Keep the outside outside. We trust whatever’s inside our four walls, while deploying security measures to keep the evil outside. This creates an us (employees) and them (customers, partners, and everyone else) mentality.

[[2]]LEO: Lyons Electronic Office. The first business computer. @ Wikipedia[[2]]

Things have changed since these rules were first laid down. From another post of mine on a similar topic{{3}} (somewhat trimmed and edited):

[[3]]The IT department we have today is not the IT department we’ll need tomorrow @ PEG[[3]]

The recent global financial criss has fundamentally changed the business landscape, with many are even talking about the emergence of a new normal{{4}}. We’ve also seen the emergence of outsource, offshore, cloud computing, SaaS, Enterprise 2.0 and so much more.

Companies are becoming more focused, while leaning more heavily on partners and services companies (BPO, out-sourcers, consultants, and so on) to cover those areas of the business they don’t want to focus on. We can see this from the global companies who have effectively moved to a franchise model, though to the small end of town where startups are using on-line services such as Amazon S3, rather than building their own internal capabilities.

We’re also seeing more rapid business change: what used to take years now takes months, or even weeks. The constant value-chain optimisation we’ve been working on since the 70s has finally cumulated in product and regulatory life-cycles that change faster than we can keep up.

Money is also becoming (or has become) more expensive, causing companies and deals to operate with less leverage. This means that there is less capital available for major projects, pushing companies to favour renting over buying, as well as creating a preference for smaller, incremental change over the major business transformation of the past.

And finally, companies are starting to take a truly global outlook and operate as one cohesive business across the globe, rather than as a family of cloned business who operate more-or-less independently in each region.

[[4]]The new normal @ McKinsey Quarterly[[4]]

So what are the new 4 ± 2 rules? They’re not the old rules of asset management. We could argue that they’re the rules of modern manoeuvre warfare{{5}} (which would allow me to sneak in one of my regular John Boyd references{{6}}), but that would be have the tail wagging the dog as it’s business, and not IT that has that responsibility.

[[5]]Maneuver warfare @ Wikipedia[[5]]
[[6]]John Boyd @ Wikipedia[[6]]

I think that the new rules cast IT as something like that of a pit crew. IT doesn’t make the parts (though we might lash together something when in a pinch), nor do we steer the car. Our job is to swap the tyres, pump the fuel, and straighten the fender, all in that sliver of time available to us, so that the driver can focus on their race strategy and get back out on track as quickly as possible.

With that in mind, the following seems to be a fair (4 ± 2) minimum set to start with.

  • Timeliness. A late solution is often worse than no solution at all, as you’ve spent the money without realising any benefit. Or, as a wise sage once told me, management is the art of making a timely decision, and then making it work. Where before we could take the time to get it right (after all, the solution will be in the field for a long time and needs to support a lot of people, so better to discover problems early rather than later), now we just need to make sure the solution is good enough in the time available, and has the potential to grow to meet future demand. The large “productionisation” efforts of the past need to be broken into a series of incremental improvements (à la Gmail and the land of perpeputal beta), aligning investment with both opportunity and realised value.
  • Availability. Not just up time, but ensuring that all stakeholders (both in and outside the company, including partners and clients) can get access to the solutions and data they need. There’s little value in a sophisticated knowledge base solution if the sales team can’t use it in the field to answer customer questions in real time. Once they’ve had to fire up the laptop, and the 3G card, and the VPN, the moment has passed and the sale lost. Or worse, forcing them to head back to the bricks and mortar office. As I pointed out the other week, decisions are more important than data{{7}}, and success in this environment means empowering stakeholders to make the best possible decisions by ensuring that the have the data and functions they need, where they need, when they need it, and in a format that make it easy to consume.
  • Agility. Agility means creating an IT estate that meet the challenges we can see coming down the road. It doesn’t mean creating an infinitely flexible IT estate. Every bit of flexibility we create, every flex point we add, comes at a cost. Too much flexibility is a bad thing{{8}}, as it weighs us down. Think of formula one cars: they’re fast and they’re agile (which is why driving them tends to be a young mans game), and they’re very stiff. Agility comes from keeping the weight down and being prepared to act quickly. This means keeping things simple, ensuring that we have minimum set of moving parts required. The F1 crowd might have an eye for detail, such as putting nitrogen{{9}} in the tyres, but unnecessary moving parts that might reduce reliability or performance are eliminated. Agility is the cross product of weight, speed, reliability and flexibility, and we need to work to get them all into balance.
  • Sustainability. Business is not a sprint (ideally), and this means that cost and reliability remain important factors, but not the only factors. While timeliness, availability and agility might be what drive us forward, we need still need to ensure that IT is still a smooth running operation. The old rules saw cost and reliability as absolutes, and we strived to keep costs as low, and reliability as high, as possible. The new rules see us balancing sustainability with need, accepting (slightly) higher costs or lower reliability to provide a more timely, available or agile solution while still meeting business requirements. (I wonder if I should have called this one “balance”.)

[[7]]Decisions are more important than data @ PEG[[7]]
[[8]]Having too much SOA is a bad thing (and what we might do about it) @ PEG[[8]]
[[9]]Understanding the sport: Tyres @ formula1.com[[9]]

While by no mean complete or definitive, I think that’s a fair set of rules to start the discussion.

The rules of enterprise IT

As I’ve pointed out before (possibly as I’m quite fond of games{{1}}) the game of enterprise IT has a long an proud history. I’ve also pointed out that the rules of this game need to change if enterprise IT — as we know it — is to remain relevant in the future{{2}}. This is triggered a few interesting conversations at the pub on just what are the old rules of IT.

[[1]]Capitalise: A game for the whole company to play![[1]]
[[2]]People don’t like change. (Or do they?)[[2]]

Enterprise IT, as we know it today, is an asset management business, the bastard son of Henry Ford’s moving production line. Enterprise IT takes the raw material of business processes and technology and turns them into automated solutions. From those first card tabulators through to today’s enterprise applications, the focus has been on delivering large IT solutions into the business.

The rules of enterprise IT are the therefore rules of business operations. After a fair amount of coffee and beer with friends, the following 4 ± 2 rules seems to be a fair minimum set (in no particular order).

Keep the lights on. Or, put more gently, the ticket to the strategy table is a smooth running business. Business has become totally reliant on IT, while at the same time IT is still seen as something of a black art run by a collection of unapproachable high priests. The board might complain about the cost and pain of an ERP upgrade, but they know they have to find the money if they want to successfully close the books at the end of the financial year. While this means that the money will usually be found, it also means that the number one rule of being a CIO is to keep the transactions flowing. Orders must be taken, products shipped (or services provided), invoices sent and cash collected. IT is an operational essential, and any CIO who can’t be trusted to keep the lights on won’t even have time to warm up their seat.

Save money. IT started as a cost saving exercise: automatic tabulation machines to replace rooms full of people shuffling papers, networks to eliminate the need to truck paper from one place to another. From those first few systems through to today’s modern enterprise solutions, applications have been seen as a tool to save time and money. Understand what the business processes or problem is, and then support the heavy information lifting with technology to drive cost savings and reduce cycle time. Business cases are driven by ideas like ROI, capturing these savings over time. Keep pushing the bottom line down. These incremental savings can add up to significant changes, such as Dell’s make-to-order solution{{3}} which enabled the company to operate with negative working capital (ie. they took your cash before they needed to pay their suppliers), but the overall approach is still based on using IT to drive cost savings through the automation of predefined business processes.

[[3]]Dell’s make to order solution leaves competitors in the dust.[[3]]

Build what you need. When applications are rare, then building them is an engineering challenge. You can’t just go to the store and by the parts you need, you need to create a lot of the parts yourself in your own machine shop. I remember the large teams (compared to today) from the start of my career. A CORBA project didn’t just need a team to implement the business logic, it needed a large infrastructure team (security guy, transaction guy …) as well. Many organisations (and their strong desire to build – or at least heavily customise – solutions) still work under this assumption. IT was the department to marshal large engineering teams who deliver the industrial grade solutions which can form the backbone of a business.

Ferrero Rocher
Crunch on the outside, soft and chewy in the middle.

Keep the outside outside. It’s common to have what is called a Ferrero Rocher{{4}} approach to IT: crunchy on the outside while soft and chewy in the middle. This applies to both security and data management. We visualise a strong distinction between inside and outside the enterprise. Inside we have our data, processes and people. Outside is everyone else (including our customers and partners). We harvest data from our operations and inject it into business intelligence solutions to create insight (and drive operational savings). We trust whatever’s inside our four walls, while deploying significant security measures to keep the evil outside.

[[4]]Ferrero[[4]]

It’s a separate question of whether or not these rules are still relevant in an age when business cycles are measured in weeks rather than years, and SaaS and cloud computing are emerging as the dominate modes of software delivery.

Danger Will Robinson!

Ack! The scorecard's gone red!
Ack! The scorecard's gone red!

Andy Mulholland has a nice post over at the Capgemini CTO blog, which points out that we have a strange aversion to the colour red. Having red on your balanced scorecard is not necessarily a bad thing, as it tells you something that you didn’t know before. Insisting on managers delivering completely green scorecard is just throwing good information away.

Unfortunately something’s wrong with Capgemini’s blogging platform, and it won’t let me post a comment. Go and read the post, and then you can find my comment below.

Economists have a (rather old) saying: “if you don’t fail occasionally, then you’re not optimising (enough)”. We need to consider red squares on the board to be opportunities, just as much as they might be problems. Red just represents “something happened that we didn’t expect”. This might be bad (something broke), or it might be good (an opportunity).

Given the rapid pace of change today, and the high incidence of the unexpected, managing all the red out of your business instantly turns you into a dinosaur.

Decisions are more important than data

Names and categories are important. Just look at the challenges faced by the archeology community as DNA evidence forces history to be rewritten when it breaks old understandings, changing how we think and feel in the process. Just who invaded who? Or was related to who?

We have the same problem with (enterprise) technology; how we think about the building blocks of the IT estate has a strong influence on how approach the problems we need to solve. Unfortunately our current taxonomy has a very functional basis, rooted as it is in the original challenge of creating the major IT assets we have today. This is a problem, as it’s preventing us to taking full advantage of the technologies available to us. If we want to move forward, creating solutions that will thrive in a post GFC world, then we need to think about enterprise IT in a different way.

Enterprise applications – the applications we often know and love (or hate) – fall into a few distinct types. A taxonomy, if you will. This taxonomy has a very functional basis, founded as it is on the challenge of delivering high performance and stable solutions into difficult operational environments. Categories tend to be focused on the technical role a group of assets have in the overall IT estate. We might quibble over the precise number of categories and their makeup, but for the purposes of this argument I’m going to go with three distinct categories (plus another one).

SABER
SABER @ American Airlines

First, there’s the applications responsible for data storage and coherence: the electronic filing cabinets that replaced rooms full of clerks and accountants back in the day. From the first computerised general ledger through to CRM, their business case is a simple one of automating paper shuffling. Put the data in on place and making access quick and easy; like SABER did, which I’ve mentioned before.

Next, are the data transformation tools. Applications which take a bunch of inputs and generate an answer. This might be a plan (production plan, staffing roster, transport planning or supply chain movements …) or a figure (price, tax, overnight interest calculation). State might be stored somewhere else, but these solutions still need some some serious computing power to cope with hugh bursts in demand.

Third is data presentation: taking corporate information and presenting in some form that humans can consume (though looking at my latest phone bill, there’s no attempt to make the data easy to consume). This might be billing or invoicing engines, application specific GUIs, or even portals.

We can also typically add one more category – data integration – though this is mainly the domain of data warehouses. Solutions that pull together data from multiple sources to create a summary view. This category of solutions wouldn’t exist aside from the fact that our operational, data management solutions, can’t cope with an additional reporting load. This is also the category for all those XLS spreadsheets that spread through business like a virus, as high integration costs or more important projects prevent us from supporting user requests.

A long time ago we’d bake all these layers into the one solution. SABER, I’m sure, did a bit of everything, though its main focus was data management. Client-server changed things a bit by breaking user interface from back-end data management, and then portals took this a step further. Planning tools (and other data transformation tools) started as modules in larger applications, eventually popping out as stand alone solutions when they grew large enough (and complex enough) to justify their own delivery effort. Now we have separate solutions in each of these categories, and a major integration problem.

This categorisation creates a number of problems for me. First and foremost is the disconnection between what business has become, and what technology is trying to be. Back in the day when “computer” referred to someone sitting at a desk computing ballistics tables, we organised data processing in much the same way that Henry Ford organised his production line. Our current approach to technology is simply the latest step in the automation of this production line.

Computers in the past
Computers in the past

Quite a bit has changed since then. We’ve reconfigured out businesses, we’re reconfiguring our IT departments, and we need to reconfigure our approach to IT. Business today is really a network of actors who collaborate to make decisions, with most (if not all) of the heavy data lifting done by technology. Retail chains are trying to reduce the transaction load on their team working the tills so that they can focus on customer relationships. The focus in supply chains to on ensuring that your network of exception managers can work together to effectively manage disruptions in the supply chain. Even head office focused on understanding and responding to market changes, rather than trying to optimise the business in an unchanging market.

The moving parts of business have changed. Henry Ford focused on mass: the challenge of scaling manufacturing processes to get cost down. We’re moved well beyond mass, through velocity, to focus on agility. A modern business is a collection of actors collaborating and making decisions, not a set of statically defined processes backed by technology assets. Trying to force modern business practices into yesterdays IT taxonomy is the source of one of the disconnects between business and IT that we complain so much about.

There’s no finer example of this than Sales and Operations Planning (S&OP). What should be a collaborative and fluid process – forward planning among a network of stakeholders – has been shoehorned into a traditional n-tier, database driven, enterprise solution. While an S&OP solution can provided significant cost saving, many companies find it too hard to fit themselves into the solution. It’s not surprising that S&OP has a reputation for being difficult to deploy and use, with many planners preferring to work around the system than with it.

I’ve been toying with a new taxonomy for a little while now, one that tries to reflect the decision, actor and collaboration centric nature of modern business. Rather than fit the people to the factory, which was the approach during the industrial revolution, the idea is to fit the factory to the people, which is the approach we use today post LEAN and flexible manufacturing. While it’s a work in progress, it still provides a good starting point for discussions on how we might use technology to support business in the new normal.

In no particular order…

Fusion solutions blend data and process to create a clear and coherent environment to support specific roles and decisions. The idea is to provide the right data and process, at the right time, in a format that is easy to consume and use, to drive the best possible decisions. This might involve blending internal data with externally sourced data (potentially scraped from a competitor’s web site); whatever data required. Providing a clear and consistent knowledge work environment, rather than the siloed and portaled environment we have today, will improve productivity (more time on work that matters, and less time on busy work) and efficiency (fewer mistakes).

Next, decisioning solutions automate key decisions in the enterprise. These decisions might range from mortgage approvals through office work, such as logistics exception management, to supporting knowledge workers workers in the field. We also need to acknowledge that decisions are often decision making processes which require logic (roles) applied over a number of discrete steps (processes). This should not be seen as replacing knowledge workers, as a more productive approach is to view decision automation as a way of amplifying our users talents.

While we have a lot of information, some information will need to be manufactured ourselves. This might range from simple charts generated from tabular data, through to logistics plans or maintenance scheduling, or even payroll.

Information and process access provide stakeholders (both people and organisations) with access to our corporate services. This is not your traditional portal to web based GUI, as the focus will be on providing stakeholders with access wherever and whenever they need, on whatever device they happen to be using. This would mean embedding your content into a Facebook app, rather than investing in a strategic portal infrastructure project. Or it might involve developing a payment gateway.

Finally we have asset management, responsible for managing your data as a corporate asset. This looks beyond the traditional storage and consistency requires for existing enterprise applications to include the political dimension, accessibility (I can get at my data whenever and wherever I want to) and stability (earthquakes, disaster recovery and the like).

It’s interesting to consider the sort of strategy a company might use around each of these categories. Manufacturing solutions – such as crew scheduling – are very transactional. Old data out, new data in. This makes them easily outsourced, or run as a bureau service. Asset management solutions map very well to SaaS: commoditized, simple and cost effective. Access solutions are similar to asset management.

Fusion and decisioning solutions are interesting. The complete solution is difficult to outsource. For many fusion solutions, the data and process set presented to knowledge workers will be unique and will change frequently, while decisioning solutions contain decisions which can represent our competitive advantage. On the other hand, it’s the intellectual content in these solutions, and not the platform, which makes them special. We could sell our platform to our competitors, or even use a commonly available SaaS platform, and still retain our competitive advantage, as the advantage is in the content, while our barrier to competition is the effort required to recreate the content.

This set of categories seems to map better to where we’re going with enterprise IT at the moment. Consider the S&OP solution I mention before. Rather than construct a large, traditional, data-centric enterprise application and change our work practices to suit, we break the problem into a number of mid-sized components and focus on driving the right decisions: fusion, decisioning, manufacturing, access, and asset management. Our solution strategy becomes more nuanced, as our goal is to blend components from each category to provide planners with the right information at the right time to enable them to make the best possible decision.

After all, when the focus is on business agility, and when we’re drowning in a see of information, decisions are more important than data.