Syndicated

Taking the Proverbial

What is the point of an ‘IT Project’?

Is it to deliver infrastructure?

Is it to deliver applications?

Or is it to deliver a service to the business?

Actually, most ‘IT projects’ shouldn’t be called ‘IT projects’; perhaps they should simply be called ‘Service Delivery Projects’. Let’s forget about the delivery of applications and infrastructure; we should simply focus on the delivery of service to the Business in a sustainable, cost-effective model as quickly as possible. Then let’s look at how we deliver such services.

This requires IT to work as single department not as warring factions under the titular head of the CIO; without applications to run, infrastructure has no value and without infrastructure to run on, applications are useless.

Some services should be simply be categorised as ‘Oxygen’; these are the services that almost every Business needs to survive; email, desktop services, collaboration tools, backup, archiving; all of these can be delivered in an off-the-shelf manner. These are the services which may most easily lend themselves to an outsourced or cloud delivery model.

Some services are those which require a certain amount of development, probably customisation of off-the-shelf applications; in many cases these are such things as CRM, Workflow management tools, web services etc. Every company probably needs them but every company will use them in different ways and have different requirements. The delivery model of such services is often the most contentious; in-house, out-sourced, cloud? All of these have potential.

And then there are those services which make your Business special; you might have a lot of these, you potentially have none. You might not actually need IT to produce your core product, an Artisan Baker probably doesn’t need a lot of specialised IT to bake bread; whereas a Satellite broadcaster needs a lot of specialised IT kit to put television programmes out. These could be bespoke applications required to deliver your service which for whatever reason need a non-standard stack. These are the services which you will most likely decide to keep in house; these are your core.

Then you need to review these services and what has the most impact of the speed of delivery? Is it the provision of IT infrastructure? Is it the development of applications to deliver the service? Is it the process of building business models to support the decision to progress with a project? Does it take longer to develop the ROI model for a service than to deliver the service? Is it the procurement process? What is actually the biggest cost in delivering the new service?

I’m not actually convinced that the delivery of IT Infrastructure is either the biggest implementation cost for many services or has the most impact on delivery timescales. I think often it can be perceived as the largest cost and the biggest impact on delivery timescales. The former is often because we tend to buy IT infrastructure in large chunks, storage has been especially vulnerable to this process.

(I suspect the costs of storage get focussed on so much simply because the CIO and the CEO often have to sign off on these large purchases; buying a server here and server there hides the costs. Utilisation of most storage arrays is certainly better than the utilisation of most non-virtualised servers and often better than that of virtualised servers. This might be key to the reason that many storage vendors are trying to push a ‘pay as you use’ model. It might well help to hide storage costs)

And delivery of Infrastructure is often the last thing to be done on a project, often any delay further up the chain means that delivery of Infrastructure is often rushed and gets blamed for all of the other woes of a project. Often in a well-run and defined delivery, the development of application and the delivery of Infrastructure are carried out in parallel and almost without exception, the Infrastructure sits idle waiting for the deployment of the new application.

But still we focus on speeding up the delivery of infrastructure because actually it is one of easiest things to speed-up. It should be a ‘crank the handle’ process and we do need to get better at this but I am not sure at the end of the day that speeding up the delivery of infrastructure is going to speed up service delivery dramatically.

Of course as an Infrastructure guy, I would say that but I have run a development team in the past and very rarely was I held up by the delivery of Infrastructure. And if I was, it was often due to us being unclear as to what we required from the Infrastructure.

Now what might dramatically change the cost-base of ongoing service is a more dynamic infrastructure which is easier to manage which can scale up and down easily. And building applications which can dynamically request and release resource as required. But will it change the speed of delivery of service?

The most significant change to the speed of delivery of most services would actually be the five P’s!

Planning Prevents Piss Poor Performance.

Nothing I have written above actually says that the various block delivery models are without merit but don’t expect miracles from them either. Examine the whole service delivery model, not just that of Infrastructure; Infrastructure is a tiny piece of the delivery model, let’s not forget this.

About the author

Martin Glassborow

Leave a Comment