Plan ahead, yes - but how far can you actually see?!

I once drove across Indiana. At one point the land was so flat and the weather so clear, I swear I could see the curvature of the Earth on the horizon. I have also driven in less clement weather in the Alps. The way the roads turned then, you were lucky to see 100m in front of you!

In terms of mapping out the road ahead, business can be a bit like that - though more often closer to the Alps than Indiana in terms of visibility! Yet why is it, when faced with such a variety of commercial terrain, we persist in planning for the mid-term under almost any circumstance?

Using the visible horizon as the extent of what I could reasonably foresee, my US drive would have allowed me to plan for the next several hours with a high degree of confidence; but in the Alps, I didn’t even know what was around the next corner!

Businesses  - and especially ‘projects’ - spend an awful lot of time planning. Some plans at the strategic level are of necessity longer-term, aspirational, more vague; a bit like saying that once we’d made it through the Alps our goal is to eventually get to Milano. But the vast majority are focussed on specific outcomes or deliverables; quite naturally, they attempt to define the who/what/when of those outcomes. However, often these plans are created without any reference to how far we can actually see. They attempt to predict activities and results miles into the future, and we kid ourselves that because the plan ‘looks right’, then it is a fair representation of the future and one accurate enough to navigate and be measured by.

All too often, however, we need to re-plan because we haven’t hit the dates in our original schedule. Sometimes this will be down to forces outside of our control, but often it will be because the plan was never achievable in the first place. We’ve planned as if we were driving across Indiana and not about to tackle another twisting mountain road in Europe. Claims that a project has ‘failed’ often misrepresent the truth; the planning may have failed, not the project. I’m sorry, but a constant 65 mph just isn’t possible heading south on the SS33 towards Italy…

Where we have a choice, what should we do? Obviously you need to apply valid context and goals to this. Some objectives will lend themselves to supremely low-levels of planning detail - but most will not. The key is to try and make as much of your plan about the achievement of real and tangible things; things you can see or touch. Time frames will vary too; many of us will have seen the 30-, 60-, 100-days type plan from a new Exec. Whichever approach you take has to be appropriate and work for you, but the scenarios will in most cases by broadly the same: 

Define what you can see ahead of you now - and focus on the key deliverables at the edge of your horizon, mapping out all the tangible and relevant steps in between. If these become increasingly subject to assumptions, risks, constraints and such like, then are they truly on your immediate horizon?

Define what you expect to see next - and concentrate on what the next large deliverables should subsequently be (clue: these will be just over the edge of your current horizon; those things about which you cannot be certain, where risks, assumptions etc. are playing a major role). Spend less time mapping out the individual steps here. As this time frame shifts from what you can expect to see to what you can actually see, then you can build the detail i.e. when the horizon shifts sufficiently to clearly include them.

Define what you think you will see after that - and outline only the major things you expect to deliver at that point (perhaps the 100-day goals in the 30-60-100 example). There is little point putting too much detail in at this stage; as the horizon shifts, the deliverables will gain greater focus as they come towards you.

Define what you hope to see in the end - and in many cases this may end up being the ‘single big thing’ that you need to achieve: cost saving, greater efficiency, a new product, double-digit growth etc. Here there is almost no truly detailed planning needed.

By taking this horizon-based, tree-like planning approach, you can align your plan in accordance with what you can ‘see’, ensuring that you make the most of your precious planning time and deliver a plan that is suitably realistic. And as time shifts, so does your horizon; this makes the plan a constantly moving, living thing - and not just in terms of tracking progress against a fixed set of tasks. It can never be a one-off. Risks change; assumptions are proven true or false; constraints fall away or new ones arise. You plan should reflect all of that.

At the end of the day, planning is like budgeting (which is essentially a plan for cash); it’s just a snapshot in time, and something, when produced, that is almost immediately wrong. 

*

About the author / copyright

Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1

Management blog: http://cioscrapbook.blogspot.co.uk

This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

“Think-Build-Run” - and Insource or Outsource?

For some people the concept of splitting an IT function into logical components of “Think” (or “Plan”), “Build” and “Run” will be nothing more than a fashion statement. There will also be those who are, for personal or philosophical reasons, totally opposed to the concept. For many, especially where the IT function is small, achieving such a delineation may be impossible given an absence of critical mass in one or all areas. 

Yet for others, “Think - Build - Run” will be a logical move, allowing a sharper degree of focus for them, their people, and their business; giving them the chance to drive up quality and drive down cost. It will be, more or less, the IT equivalent of an efficient production line paralleled with some kind of interpretation of ‘Lean’. For these people, likely to be in larger organisations with larger IT functions, it might simply be ‘the right thing to do’.

For those that adopt T-B-R, there is often a follow-on question when looking at the organisational shift to the new model: Insource or Outsource? Whilst this question is, for CEOs and CIOs always there in the background anyway, T-B-R can throw it further into the spotlight, especially if there is a working assumption that the “Run” part is more or less akin to commoditised computing services. And make no mistake, much of it is. But there is a danger in falling for a too simplistic view of the world. Many people might draw an equation between T-B-R and Insource/Outsource in the following way:

But not only is this a lazy interpretation, it is also flawed. The true line of transformation we should be looking at is something like this:

And why is that?

1 - Because you should never outsource very much of your “Think” activity. This is the area where you are closer to the business, where the relationships between IT and its Customers are most critical, and where in-house expertise can add the most value. If you can truly add differentiating competitive advantage to your organisation as an IT function, then in “Think” is where you will do so.

2 - Because, whether we like it or not, a large proportion of the ‘systems’ IT functions “Build” is likely to be unique to that organisation. Either they are bespoke, one-off solutions, or they are customised versions of commercial software offerings - and sometimes very customised! (And don’t forget all the Excel Warriors..!) It is only when you start to get to homogenous, non-differentiating, more ‘vanilla’ kinds of solution that a greater degree of outsourcing begins to make more sense (and Software as a Service [SaaS] can play a role here).

3 - Because you should never outsource all of “Run”. Even if it is only the management layer that you retain, responsibility for the service still resides in-house, and CIOs need people on their teams who hold that passion and accountability. Again the question of the service being truly commoditised comes to the fore, as do things like scale, practicality etc. There are some elements of “Run” that you simply will not be able to do as well as a third party provider (or at all, come to that: think of networks…), but there may be others where there is enough local differentiation to suggest that keeping it in-house just makes sense.

Of course, other factors come into the equation such as cost differentials and arbitrage, the overall size and philosophy of the company as a whole, appetite, previous experience, in-house expertise and talent, and so on. And the feast is a moving one too, with ‘Cloud’ becoming ever more mature, and the whole notion of Bimodal ’Mode 1’ / ‘Mode 2’ projects adding another new dimension to the mix.

Inevitably the equation is a very complex one, and to which the solution is rarely simple.