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 »


Making durable decisions easy

Making decisions always seemed simple and satisfying, and easy to change to suit circumstances.

But that was back in the days when they were design decisions, and I had developed a number of tools and techniques to help me shake the pieces into place. Things like evaluating requirements, identifying options, noting constraints, and twisting and turning the results until clear winners start to emerge. And of course – number one rule – note it ALL down. You need to know how you got where – and most importantly why, because then, once you plug in the newly changed circumstances, the design could flex and easily produce new results.

But now it all seems to revolve around money – the cost of doing something versus the cost of not doing it. Early attempts to record decisions were far from perfect. Scoping the decision was not a problem – describing what we need to decide and giving weightings to the factors that would help us decide. Nor was it difficult to list out costs, benefits and risks of the different options. The biggest issue turned out to be the inter-relation between the different options – the benefits of one option were to avoid the risks of another, or the risks involved not achieving the benefits. Tedious, repetitive and confusing!

So the solution I am using for now is to assume that the benefits (positive outcomes) and risks (negative outcomes) are all “theoretically possible” across all options, marked on a scale of 0% to 100% probability of maturing. This means the difference between the options is expressed as a combination of negative versus positive probabilities. I have stopped short of allotting a price to the benefit or risk, because these are so often subjective – in the eye of the beholder. Still, seeing the balance of plus and minus percentages should help people do their own calculations from their point of view. After all, many would-be decision-makers work from preconceptions, and massage the statistics to make the formula give the result they want, so no point in putting them through the unnecessary effort, is there?

In some ways commercial decisions are less complex than technology design, because there are fewer dimensions to consider. Money, however, can cause rather emotive reactions in people, and hard cash can boil things down to black and white results that might not have been obvious when you first asked a technological question.

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.