Monthly Archives: September 2010

Innovation [22-09-2010]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

Business models for the old rules of IT

The old rules for enterprise IT{{1}} — the rules that have determined the nature of the enterprise IT market — has shaped the people and companies involved. The roles we took on fall into a few regular patterns, patterns which I’ve always thought of in terms of analogies. Outsourcers (AM, BPO …), for example, are similar to trucking companies. Software and hardware vendors can be likened to mining companies. Consultancies are the dating agencies of the IT world. While software integrators and services firms have something of the sandwich shop about them. These analogies do have their limitations, but I’ve found that pondering these stereotypes can help you uncover a few simple truths which are useful in your day-to-day interactions.

[[1]]The rule of enterprise IT[[1]]

I’ve always had a penchant for a simple analogy. Yes, reasoning by analogy can be problematic (just ask any witch from the middle ages{{2}}), but it can provide a new perspective which helps you to uncover some aspect of the subject which had previously eluded you. All too often a failed project or outsourced service can be traced back to a misunderstanding of the nature of the engagement — a misunderstanding of the roles both client and supplier play in the IT industry. The type of simple truths an analogy highlights can go a long way to understanding these roles.

[[2]]She’s a witch! from The life of Brian[[2]]

The roles organisations currently play in the IT industry are driven by the need to deliver large IT assets into the business. What started as a simple tools to manage tabulated data — calculating payrolls, inventory levels and the like — soon grew to the point where developing them was beyond the scope of what many companies could undertake on their own. The pyramid of skills required just became too large, with too many technical skills involved that most companies couldn’t afford to own. The systems we were building had outgrown the men in sheds at the bottom of the garden, and we need to become a bit more organised.

System Integrators emerged as as way for organisations to share these skills. Technologists banded together and travelled from client to client developing applications as they went. This was good. Clients won as they could hire a group who had the skills and tacit knowledge — the did it, done it stories — required to deliver these solutions on time and to budget. The travelling System Integrator won as there was now a big enough stream of work for which they were highly valued, allowing them to be paid what they were worth rather than what any one company could afford.

As the industry grew, the System Integrators rapidly became the sandwich shops of our IT world. When we don’t have the time or money to maintain our own kitchen or make our own sandwiches, it’s more efficient to simply head over to the local sandwich shop to pick up what we need. Their margins are thin and revenue is largely tied to the size of the sandwich you bought, so they’d really like you to buy a larger and more expensive sandwich. (Notice how sandwiches have grown so much bigger over the years, and everything is now gourmet?) And, of course, pre-made sandwiches are always a lot cheaper than special orders.

A ham sandwich
A ham sandwich

With the technology industry rapidly maturing, SIs soon found that most clients had all the sandwiches they needed (I don’t know about you, but I don’t eat more than one a day), so they started to focus on convincing you to upgrade your existing sandwich, replacing it before you had actually finished eating it. If you want some of those pickles they’ve just found at the bottom of a jar then you have to buy an entirely new sandwich, and not just the pickles. Don’t mind the fact that you’ve only half finished your last sandwich.

Consultancies, on the other hand, are the technological dating agencies of the IT industry. Where SIs focus on providing sandwiches, consultancies try and set you up with a skilled subject matter expert who can help you sort out what type of sandwich you’d like to eat. Procurement, supply chain, knowledge management, IT strategy … They take a fee for each date arranged, giving them a strong focus on generating repeat business.

Some organisations — of course — try and blend a dating agency with a sandwich shop. They hope that their SMEs can steer you toward the types of sandwiches that their sandwich shop makes.

Back in application land we have the software vendors: mining companies that spend vast sums of money spelunking for new solutions and technologies, which they then package up in a box and sell for a tidy profit. (In theory, the tidy profit is reinvested back into spelunking for more technology.) Maintenance fees can be considered the delivery charges.

Software vendors allow companies to pool their exploration resources, sharing both the cost and risk of finding new applications in the technological landscape, and extracting them. Be warned though, the more unique demands you make of the vendor, the less chance they have to pool your needs with those of other companies. If you have to many unique requirements, if you move from configuration to customisation, then you start to force the vendor to go exploring for you alone, accepting all the cost and risk yourself.

And finally we have the outsources (as I’ve already mentioned). Like trucking companies, they’re focused on sweating an asset. In the case of trucking companies it’s trucks: keep the trucks moving and don’t spend money on tires. For outsources its an application: make sure they’re running at near capacity, and try and avoid changes (either patches or change requests) as they all involve disruption which goes directly into the bottom line. To make the most of outsources, you need to pass them assets which you can afford to ignore — and not upgrade or change — for a long time.

Of course these analogies break down at some point, and we need to be cognisant of this. Regardless, I think that they could form a useful, shorthand way of understanding the goals and restrictions, the business drivers, for each role in the IT industry.

Short blog posts are cheese burgers

There’s some commonly accepted wisdom that good blog posts should be short and give you something to think about. The theory is that people are time poor, and we need to pass out wisdom in handy bite-sized chunks so that it’s easy consume. (This is the same attitude that puts bullet point take-aways at the top of an article, presumably so that you don’t need to read it.)

I’m increasingly having problems with this approach, as it seems more likely to create the McDonald’s Cheese Burger of wisdom than the insight we were actually hoping for. Rather than sharing insight, they’re more like a low cost product of predictable quality that producers find easy to churn out at great volume.

Super-size me?
Super-size me?

Take this post for example (I’ll quote the entire post, as it’s only a few lines).

(And don’t imagine I’m calling out Seth here, as there’s nothing particularly special about the post other than being a good example of the sort of short thing that seems to be becoming endemic across the blog sphere.)

Why jazz is more interesting than bowling by Seth Godin

Bowling is all about one number: the final score. And great bowlers come whisker-close to hitting the perfect score regularly. Not enough dimensions for me to be fascinated by, and few people pay money to attend bowling matches.

Jazz is practiced over a thousand or perhaps a million dimensions. It’s non-linear and non-predictable, and most of all, it’s never perfect.

And yet…

when we get to work, most of us choose to bowl.

A bit like Gary Numan in the 70s, this seems wise at first glance, but when you take a second look you discover that there’s not much under the surface.

So what if Jazz is more interesting than bowling? The reality of business is that most of us are paid to bowl (with our KPIs tied to our bowling score), and Jazz is reserved for senior management. Or, out another way, most of use in business are road crew, and only a few lucky people are the Jazz musicians. And let’s not get started on the hedgehog and fox debate, which has already been done to death. (Jim Collins is obviously a bowling man.)

Many short blog posts are like that McDonald’s Cheese Burger: it can satisfy an immediate craving, but you’re left with a greasy feeling the following day. You might think it tastes good, but too many of them and you’ll need to loosen your pants to accommodate that intellectual waistline.

I say bring on the longer, thoughtful posts and give those rich and interesting ideas room to breath. A slow food movement for interesting ideas. There is a role for the short, to the point, blog post, but let’s not pretend that rich and valuable ideas can be crammed into this format. And remember what happened to Morgan Spurlock on that all hamburger diet.

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