Latest Blog Posts

itSMF International IT Service Management survey 2013

In conjunction with the National University of Singapore itSMF International have put together a global survey on IT Service Management. All itSMF members from across the world are being invited to take this opportunity to contribute to a very significant global survey on IT Service Management on a global scale. 

This survey will bring together some key headline information around how organisations are using IT Service Management across the world.

All members who take the chance to contribute to this survey will automatically qualify to receive the report on the results of the survey and you will also be placed into a draw for an iPad 4.

The survey is available in English and to complete the survey please follow the link below –  

Many thank in advance for contributing.


New Year Resolution – LLSA

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 & Doubt); how to create or destroy it.

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.


Workshops, requirements & services

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

Let's DO CSI



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.


Please help the itSMF BYOD survey #itSMF #BYOD

Please help the itSMF with their global BYOD (Bring Your own Device) survey:

With this survey, itSMF Publishing announces the first in a series of research surveys on topics of current interest to the ITSM community.

With each issue of the itSMF Publishing's magazine, At Your Service, a new survey will be announced. The results of each survey will be analyzed and reported in the following issue of At Your Service.

Please communicate this information to all your colleagues and members of itSMF via web sites, mailings, newsletters, blogs, tweets, etc.

The current issue of At Your Service may be viewed at
For more information about itSMF Publishing, please visit:


The monster that ate all their effort

The Monster:

Let’s start with a story of an unhappy CEO. At the end of a good year while the leaders from service supplier were busy preparing the new contract with customer, one day, the CEO from the customer organization asked a very awkward question. The project was doing well in terms of SLA and KPI, operational managers were moderately happy and yet the CEO stated “I am happy about the way you deal with incidents or problems and yet I am not very clear what value you are adding to my operation; help me to understand”.


It took the leaders into a state of shock because they went there very well prepared; at least they thought they were. A moment of silence spread over the board room, some were wondering how to answer this, some even thought the CEO was just playing one of his games usually he plays to take over the vendor with surprise.


The following week I have my friend coming out completely broke from his appraisal session with the CIO. He is a good performer and does almost everything in time and yet the CIO asked him the same question, despite of the fact that he has been working long hours every now and then but what value he was really adding to the business.


Will you not agree with me by now if I call value, the five letter monster that can eat everything and anything?


We all understand that what matters to business at the end of the day is VALUE; yet it is not very uncommon that leaders find it difficult to relate seemingly irrelevant day-to-day activities with the value proposition, as a result, even though staffs are overworked, the project end up with an unhappy customer and frustrated employee.



Why do we do it to ourselves?

In IT we are faced with tons of standards, guidelines and best (or good) practices. Making sense of them is hard work and in no way straightforward. These documents are cluttered with definitions and nuances that experienced practitioners might see, but which newcomers miss. Yet, even the experts sometimes (uhm... regularly) differ...

Is this a bad thing? Not necessarily, as it might prompt some thinking, some reflection, some learning - of course from my academic viewpoint that sounds like a good thing, hopefully you agree. That happens, of course, only if we apply our minds. But alas, often we don't; often we fall into a checklist mentality.

Not that checklists are always bad either. It is a well-used management tool since our heads can only hold so much. Even in personal productivity work, think David Allen's GTD, lists are the primary way of freeing our minds from the burden of 'remembering'. But, of course, the intention is that we can use our brain capacity in more productive ways... If we free our minds from the mundane we should be able to use that capacity to better effect.

What is the problem with checklists then? 

The departure point for checklists is WHAT. According to Simon Sinek in his book "Start With Why" humans are biologically not wired to be inspired by WHAT, but by WHY. (Watch Simon explain it in a TED video if you don't want to read the book). In Sinek's model he sees WHAT as the outer layer, followed by HOW in the middle and WHY in the center. To inspire, to change behavior we need to communicate from the inside out, i.e. WHY, then HOW, then WHAT. 

Standards, guidelines and best (or good) practices of course makes this mistake in communication as well.  Lots of WHAT, some HOW, and only a little WHY... If you are not convinced think of many of the questions going around online (LinkedIn, Facebook, Twitter and other forums). Is this in process A or B? Which tool is best?  What's the industry standard? Do you have SLAs? What do you use for your CMDB? All those questions deals with WHAT and HOW.  And the answer can be a stock standard variation of "It depends. WHY are you (...fill in the blanks...)?". If the answer is because the auditors told us to, or management said we must, chances are that the answer will not matter that much anyway...

This brings me to the post's title. Why do we do it to ourselves? Why do we fall into a checklist mentality? 

I believe the IT community needs to start rethinking WHY we are doing WHAT we are doing. What do you think?

[Note: In future I will use this blog as a bit of a soapbox to share my insights, experiences, observations and random thoughts around ITSM.]


Few questions and a request

Let's start with the questions:

1. Why only two Bloggers? !!!!

2. Does writing here requires being an expert or certified on something?

3. Can the user or professioal not write about the expereinces (IT experiences & challenges) they go through everyday in the industry?

I must confess first that I am a very newcomer to this society, as a matter of fact, before having the chance to join the conference at Sunninghill, I wasnt aware of this community at all. My apology if I am asking questions that have already been discussed or addressed long ago. I am also not a native english speaker, if any part of this sounds rude, please forgive me, I didn't mean to be, its just becuase of my limited knowledge about the language.

 I need to tell that the conference was a great experience for me, seeing so many experts with experiences and thoughts from so many dimensions was really a great opportunity; looking forward to many more exciting events in future.

I need some help as well with something. I am planning to develop a report for Capacity monitoring/Reporting on capacity control points.

Would anyone be kind enough to share some experiences or sample template that has successful case record? Please be sure I am not looking for texts from ITIL books or anything of that sort; i need a real case sutdy.

I would really appreciate if someone can share some info or guidance on that.