Find the blurb below, and to can grab the complete text from the iBookstore or Lulu (epub) (Amazon is in the pipeline).

Outsourcing in an increasingly complex world

by Peter Evans-Greenwood

Pressure on margins is driving organizations to increasingly rationalize and externalize supporting functions as they search for more efficient and flexible delivery approaches.

Most common approaches to outsourcing center on establishing target service levels and a unit cost, treating the negotiation of an outsourcing engagement in a similar fashion to the procurement of other materials that the business needs.

Outsourcing, however, is becoming more complicated as we move functions closer to the heart of the business into the hands of partners and suppliers. This represents a shift from an approach based on paying invoices for the raw materials we need to run the business, to one based on delegating core, business-critical functions to suppliers, and then requiring them to deliver the outcomes that we need.

Crafting a successful outsourcing engagement in this environment requires us to align the supplier’s incentives, and therefore their objectives, with the client’s business drivers. It’s not enough to take a piecemeal approach, imposing additional requirements and constraints in the hope that these will shape supplier behaviour.

It’s a truism that what gets measured is what gets done; outsourcing is no different. Existing approaches to crafting outsourcing agreements attempt to shape supplier behavior by imposing large and inconsistent sets of requirements, with the result that both parties search for loopholes in an attempt to optimize their position.

A successful contract will be based on the customer’s business drivers, aligning supplier incentives with them to ensure that the agreement drives the right behaviors

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].

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.

References

1. Business models for the old rules of IT @ PEG↑

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.

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

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].

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.

References

1. Martin Linssen↑
2. the emperor has no clothes↑
3. Dennis Howlett↑
4. Enterprise 2.0 is beyond a crock. It’s dead.↑
5. Your Mileage May Vary↑

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?

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.

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).

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].

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.

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].

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.

References

1. 60 percent of Apple’s sales are from products that did not exist three years ago @ asumco.com↑
2. Rapid productionising @ Shermo↑
3. Fan criticism of George Lucas: Ability as a film director @ Wookieepedia↑
4. I’ve already told you 125% of what I know @ PEG↑
5. Enterprise Mash-Ups defined at Wikipedia↑
6. Mint↑
7. Kiva↑
8. Zara↑
9. Inside vs. Outside @ PEG↑
10. Tesco is looking outside the building to predict customer needs @ PEG↑
11. Accelerate along the road to happiness @ PEG↑

I heard a fascinating distinction the other day at breakfast. It’s the difference between “Architects” and “architects”. (That’s one with a little “a”, and the other with a large one.) It seems that some organisations have two flavours of architect. Those with the big “A” do the big thinking and the long meetings, they worry about the Enterprise, Application and Technology Architectures, and are skilled in the use of whiteboards. And those with the little “a” do the documenting and some implementation work, with Microsoft Visio and Word their tool of choice.

When did we starting trying to define an “Architect” as someone who doesn’t have some responsibility for execution? That’s a new idea for me. I thought that this Architect-architect split was a nice nutshell definition of what seems to be wrong with IT architecture at the moment.

We know that the best architects engage directly with the business and take accountability in providing solutions and outcomes the business cares about. However, splitting accountability between “Architects” and “architects” creates a structure and operation we know is potentially inefficient and disconnected from what’s really important. If the business sees architects (with either a big or little “a”) as not being responsible for delivering an outcome, then why does the business need them?

There’s a lot of hand wringing around the IT architecture community as proponents try to explain the benefits of architecture, and then communicate these benefits to the business. More often than not these efforts fall flat, with abstract arguments about governance, efficiency and business-technology alignment failing to resonate with the business.

“Better communication” might be pragmatic advice, but it ignores the fact that you need to be communicating something the audience cares about. And the business doesn’t care about governance, efficiency of the IT estate or business-technology alignment. You might: they don’t.

In my experience there are only three things that business does care about (and I generally work for the business these days).

• Create a new product, service or market
• Change the cost of operations or production
• Create new interactions between customers and the company

And this seems to be the root of the problem. Neither IT efficiency, nor or governance or business-technology alignment are on that list. Gartner even highlighted this in a recent survey when they queried more than 1,500 business and technology executives to find out their priorities going forward.

Top 10 Business and Technology Priorities in 2010

Business need their applications — and are willing to admit this — but do they need better technical infrastructure or SOA (whatever that is)? How does that relate to workforce effectiveness? Will it help sell more product? Eventually the business will reach a point where doing nothing with IT seems like the most pragmatic option.

There’s a few classic examples of companies who get by while completely ignoring the IT estate. They happily continue using decades old applications, tweaking operational costs or worrying about M&A, and making healthy profits all the while. Their IT systems were good enough and fully depreciated, so why bother doing anything?

So what is the cost of doing nothing? Will the business suffer if the EA team just up and left? Or if the business let the entire architecture team go? The business will only invest in an architecture function if having one provides a better outcome than doing nothing. The challenge is that architecture has become largely detached from the businesses they are supposed to support. Architecture have forgotten that they work in logistics company, a bank or a government department, and not for “IT”. The tail is trying to wag the dog.

Defining Architecture (that’s the one with a big “A”) as a group who think the big technological thoughts, and who attend the long and very senior IT vendor meetings just compounds the problem. It sends a strong message to the business that architecture is not interested in the helping the business with the problems that it is facing. Technology and transformation are seen as more important.

It also seems that the business is starting to hear this message, which means that action can’t be far behind. Unless architecture community wakes up and reorganises around to what’s really important — the things that business care about — then we shouldn’t be surprised if business starts shedding these IT architecture functions that the business sees as adding no value. I give it six to eighteen months.

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 untimed[1] 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 planning[2] 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 itself[3]). 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 normal[5]. 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 Brooks[6] 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 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 maps[8], mission statements[9], 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↑
5. The new normal @ McKinsey Quarterly↑
6. Frederick Brooks on the Mythical Man Month↑
8. Strategy map defined @ Value Based Mangement by Kaplan & Norton↑
9. Mission statement defined @ The Centre for Business Planning↑

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):

• 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.

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

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.

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.

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”.)

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

References

1. The rules of Enterprise IT @ PEG↑
2. LEO: Lyons Electronic Office. The first business computer. @ Wikipedia↑
3. The IT department we have today is not the IT department we’ll need tomorrow @ PEG↑
4. The new normal @ McKinsey Quarterly↑
5. Maneuver warfare @ Wikipedia↑
6. John Boyd @ Wikipedia↑
7. Decisions are more important than data @ PEG↑
8. Having too much SOA is a bad thing (and what we might do about it) @ PEG↑
9. Understanding the sport: Tyres @ formula1.com↑

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.

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.

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.

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.

References

1. Capitalise: A game for the whole company to play!↑
2. People don’t like change. (Or do they?)↑
3. Dell’s make to order solution leaves competitors in the dust.↑
4. Ferrero↑

Running a business is a bit like being the Fat Controller, running his vast train network. We spend our time trying to get the trains to run on time with the all too often distraction of digging the Troublesome Trucks out of trouble.

Improvement often means upgrading the tracks to create smoother, straighter lines. After years of doing this, any improvement to the tracks can only provide a minor, incremental benefit.

What we really need is a new signalling system. We need to better utilise the tracks we already have, and this means making better decisions about which trains to run where, and better coordination between the trains. Our tracks are fine (as long as we keep up the scheduled maintenance), but we do need to better manage transit across and between them.

Swap processes for tracks, and I think that this paints quite a nice visual picture.

Years of processes improvement (via LEAN, Six Sigma and, more recently, BPM) had straightened and smoothed our processes to the point that any additional investment has hit the law of diminishing returns. Rather than continue to try and improve the processes on my own, I’d outsource process maintenance to a collection of SaaS and BPO providers.

The greater scale of these providers allows them to invest in improvements which I don’t have the time or money for. Handing over responsibility also creates the time and space for me to focus on improving the decisions on which process to run where, and when: my signalling system.

This is especially important in a world where it is becoming rare to even own the processes these days.

We forget just how important a good signalling system is. Get it right and you get the German or Japanese train networks. Get it wrong and you rapidly descend into the second or third world, regardless of the quality of your tracks.

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.