Delivery by Crisis – taking pragmatism to extremes

Risk management conditions us to feel it’s vital to be cautious. We must plan properly, test thoroughly, document clearly and deliver with control. And these are principles that have stood innumerous projects in good stead.

But could there be another way?

Is there a devil’s advocate that appears in the form of a service crippling crisis?

When the lights go out a dust-covered candle stub shines as a bright beacon…

Because when nothing is working, you have nothing to loose!

I have witnessed occasions when technical solutions have been crash-delivered before they were properly ready in order to fix operational issues, when it has been worth cutting corners and dealing afterwards with the minimal amount of clean-up required. These urgencies have actually been to to mutual benefit – saving the project’s time and the operational team’s bacon 🙂

Read the rest of this entry »


Will rightsourcing allow you to balance strategic service with tactical delivery?

Towards the end of a project to outsource a large section of a company’s infrastructure I learned that a previous IT Director was very proud of her decision a few years beforehand to insource much of what we were putting back out. Looking into the reasons for both of these transitions you could conclude that there is a right time to have stable operations run at a low fixed cost, and there is a right time to increase the cost, and the risk of cost escalation, in order to allow rapid change by removing barriers and pooling knowledge tightly within a highly skilled team.

Well if both are valid at times, could they not both be valid at the same time? Is there not a case for “rightsourcing”?

Read the rest of this entry »

If you wait patiently enough the future will arrive

So is 2008 the year we’ve been waiting for? Well, according to Enterprise Management Associates (EMA), many of the hot topics this year has in store for us are exactly those I’ve been striving to achieve in various organisations over the past ten years.

IT Management Trends to Watch for in 2008 lists such fantastic, yet common sense items as:

  • data centre automation (DCA)
  • virtualisation
  • configuration management database (CMDB)
  • automated IT service management (ITSM)
  • governance and risk management

So my question is … “if IT infrastructure managers have been able to ignore the massive cost savings they could have accrued during the past few years by capitalising on these techniques, why are they going to suddenly turn around in 2008, see the light, and start doing it all?”

Perhaps EMA’s various research tracks for 2008 will help shed light on golden opportunities for us all

Thanks to Uttam at Locuz for pointing out the press release

Releasing the nightmares

So once you finally get the green light for your programme, you begin to let loose the dogs (that had been snarling and growling in early design stages) and you suddenly find that you’re in a project versus operations, us-against-them situation.

What you need to grease the wheels is a decent bit of Release Management (RM).

But what exactly is it?
Read the rest of this entry »

Choosing the best party – the 1st or the 3rd?

I’ve heard people boil outsourcing decisions down to “we’re not in the business of X” and this is indeed a reasonable principal, whether you are talking IT operations, software development or even payroll and other HR functions. But how would you actually define what business you’re in?

I recently read a discussion in the Tyner Blain blog that helps put the decision into a more detailed context. In Outsourcing Debate – Two Guys Talk it Out Bill Miller clearly spells out two fundamental criteria:

  • Is it a profit centre or a cost centre?
  • Is it a core competency or a necessary chore?

Clearly if it’s something that is a speciality of your company, and you can make money out of it, then you are best off handling it in-house. If on the other hand you’ve just got to get it done, and pay for it on top, then you are likely to get a better, cheaper and more innovative service if you get someone else to do it – someone for whom it is a speciality, and whose business it is to make money in that way.

Although the article mainly talks about offshoring development, I think you’ll agree that these criteria can readily be applied to any aspect of your business operations.

Potholes in your CMDB roadmap

Implementing a Configuration Management DataBase (CMDB) is not a single action, but a gradual process that may take months or years to establish. Even after that, it is subject to change and improve like any area of your IT operations, especially as your business changes around you.

In many organisations there can be similar pitfalls when tying to create an effective CMDB, and the best way to avoid them is to be aware of them, and plan around them. Here are my top three:

1) Ownership and dispersed authority – the information that must be captured and held within a CMDB typically extends into the domains of many teams. Although one of these teams has overall responsibility for the “whole”, there are people in other teams who truly hold the knowledge and are aware when fundamentals change – it can be difficult to pin the responsibility on those other people for keeping their part of the database up to date.

2) Inequality of investment and return – by its nature, a CMDB is unfair to its various clients. The people who get the most out of the system do not have to put much effort in. Yet the people who have to spend most time putting the information in are rarely interested in getting anything out of it.

3) The value is in relationships, not data – many people see “automatic data feeds” as the nirvana for maintaining a good CMDB. Yes, it’s true that you can get rafts of detailed configuration information automatically imported in the blink of an LED, but that is only half the story. What SMS, Insight Manager and CiscoWorks can’t give you on a drip-feed is the richer knowledge about how systems interconnect and inter-depend. That’s stuff that IT folks typically carry around in their heads (or store on complex and un-referenced Visio diagrams that are never collated into a single repository). These system relationships are what let you analyse your ability to resist points of failure, to predict the likely impact of planned change, and to ensure that you really understand exactly how your customers make money using the iron you manage. If you manage Change, Configuration and Release, you are at the best point to keep track of such interdependencies over time, but don’t expect the machines to do all the hard work for you just yet.