Friday, 11 September 2015

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

Sunday, 6 September 2015

Being Agile...

Fashion is everywhere. Fashion introduces new things to us - and recycles the old! Fashion creates product and demand; it generates sales and profit; it breeds need. Even in Information Technology, we love fashion. It gives us the opportunity to create new notions and processes; it is a natural bedfellow with the rapid changes in technology that we are now seeing, inventing new ways to use those technologies and creating new ‘products’ from them.
Yet what we actually do in IT is the same as ever: we teach machines (computers, now of various favours including mobile phones) to take the data we give them and then manipulate and store that data for future processing (more manipulation) or reporting. Occasionally the data is used to control other things, like traffic lights or machinery - or even spaceships and cars! 
Ensuring that we do a good job in building the systems that make those manipulations effective, IT professionals have always invented rules and processes around the development cycle in order to try and make the end product as good as it can be. As technology moves on and the pace with which development can be carried out quickens, the volume of changes and the speed with which results are needed both increase, and hence new models of development are needed.
And so we have seen a progression of methodologies like ‘waterfall’ through ‘rapid application development (RAD)’ and on to ‘Agile’, the current IT panacea for this decade it seems.
Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. (Wikipedia)
Like many ‘next great things’, Agile will only be as good as the people and organisations that adopt it However, we might be missing a trick here. Should ‘Agile’ not be a state of mind, a philosophy, rather than a methodology or series of formal IT processes? For one thing, if a development team is working in ‘an agile way’ but the rest of IT is not, or the culture of the business as a whole is slow and ponderous, will ‘Agile’ not inevitably fail to deliver as much as it might promise to?
Take the Wikipedia definition above. The “collaboration between self-organizing, cross-functional teams” requires everyone involved to be able to work in the same way. “Rapid and flexible response to change” needs to be in the DNA or culture of the whole organisation; what’s the point in producing IT systems quickly if their prospective users do not readily embrace change?
If we think of being ‘Agile’ as being “the answer” and that it relates just to IT software development, then we are deluding ourselves. ‘Agile’ needs to be part of the corporate culture.
Agile is a cultural philosophy as a result of which decisionsactions and business solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary and incremental progress, early delivery, continuous improvement and the elimination of waste (in all its forms), effective and prompt decision-making, and encourages a rapid and flexible response to change.
OK, I know this version isn’t perfect - but doesn’t it sound much more like the kind of business we would all like to work in?! Isn’t it more inclusive and relevant to all our staff, rather than that minor percentage employed in the rarified world of IT application development? Yes, it might increase risk a little; and yes, it will demand better delegation, more accountability and so forth. But in the end, those are probably good things - and any negatives should be outweighed by overall commercial benefits.
And I expect each of us can think of real, every-day examples of where being ‘Agile’ can bring true improvement - in bottom-line, morale, responsiveness etc.
Why not change the format and content of that monthly departmental meeting so that we can focus on just the critical points and get through it in an hour instead of the four hours it currently takes?
Why not reduce the number of people needed to take a decision to those who are really affected by it so that the decision is made more quickly? And why not make decisions when a) you have 80% of the data needed rather than search for the 100%, or b) when everyone knows what the ‘right’ answer is anyway?!
Why not redesign our organisations to facilitate teams whose sole purpose is rapid response or firefighting?
Why not cull the hundreds of documents and reports we produce and focus on the very few we actually need?
Why not, why not…
Agile as a software development methodology is all well and good, but until we broaden our thinking to embrace more than just IT, we will never get the full potential benefit of taking such a pragmatic approach.
*
About the author / copyright
This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.