Is that late already for a New Year resolution!!! Well, I hope not, it’s still January; besides, if we are willing to push own self for continuous improvement, new year is just as important as any new morning. They say you eat an elephant only bit by bit; for the pillars are the important element of a temple as they hold the whole construction together, so, I guess a daily/weekly plan is more important than an overall yearly plan. I think, we can actually have a monthly resolution for every month.

Okay, if you are still reading this, it means we were able to draw your attention. No, we are not going to tell what this acronym, LLSA, stands for, not yet.

FUD (Fear, Uncertainty and Doubt). This came to mind from Jeffrey Brooks' post on organisational maturity in Back2ITSM..

Machiavelli didn't use the acronym 'FUD', but much of his advice on being a prince relied upon it. Managers who take ‘The Art of War’ or ‘The Prince’ too literally as their guide see it as a tool to manage. It certainly can help an ambitious and ruthless individual climb to the top of an organisational greasy pole. Unfortunately it leaves a dysfunctional organisation in its wake. From the point of view of the individual Machiavellian, this is a good thing too – a disunited organisation, full of internal strife, isn’t going to be in a state to mount an effective coup against its leadership.

I'm running a workshop today, one of a set of three before the end of the year. I'm looking forward to it - there are only a dozen people, so not the pressure of the Sao Paulo event, but it has more of an urgent goal to be achieved.

Workshops are, by their nature, a lot less predictable than training courses. That makes them fun, but means that you've got to do your preparation properly.

I'm wondering if it would make sense to write a small pamphlet on running workshops (or more specifically on running them on metrics or, as in this case, business analysis). It's the sort of thing that I'd have found handy.

I'm interested in how my view of business analysis has changed so much as a result of writing the book on the integrated requirements process. This is undergoing its second cycle of critical review so should be published in the not too distant future - by the itSMF global publishing organisation (with, by the way, a handsome percentage of the royalties for the South African chapter!!).

I now cannot see a sensible way in which it can be divorced from service management and it becomes clearer, almost by the day, that requirements are the true IP, not the more obvious solutions, which are only instantiations of a subset of the actual requirements according to current constraints (including the invisible constraints on imagination and design skill).

I haven't, by the way, forgotten that I've got postings on the Stockholm event to catch up with - I hope to have these up in the next few days..

Let's DO CSI

Warnings:

a. Majority of the content of this case was taken from the original ITIL CSI book

b. On different points customized notes are added to clarify the limitation

c. In reality CSI is critical to an organization and can be complicated as well; here we kept it very simple and straight

c. Read at your own risk

Let’s start with the common trends:

1.Somewhere something is broken, suddenly a improvement activity starts

2.A new leader came onboard and made a noise big enough to make everyone move, thus, improvement plans and actions

3.Things are stable, people forget there was an improvement plans that were started once

Well, all are wrong, ITIL says, Improvement must be a continuous activity. To ensure that the technical operation is completely aligned with the business requirements and being measured, monitored and operated in a controlled manner, CSI is a must.

Question is how can we do that?

Okay, let’s see how we can do that and if we can relate this to a practical example. But before we get down to how, we need to recall our knowledge on two concepts from ITIL – Deming cycle and CSI model.