I often rant express poor customer service experiences in this blog, so thought it was only fair to put on record a very positive customer service experience. I hold two domains with two separate providers (in case one provider is down), and one of those domains is hosted by Servers Australia. One of their support staff, Jared Hirst, takes most of my support calls and he is consistently courteous, polite and helpful – and an asset to his company.

Peter Baker and Donna Benjamin (with only a little bit of help from me I have to admit) have been hard at work putting the finishing touches on the preparations for Software Freedom Day in Melbourne. We have a great venue this year – The Hub at Docklands – and have an array (no pun intended) of great speakers lined up, including;

• Tyson Clugg – Melbourne Wireless
• Dale Clapperton – Electronic Frontiers Australia
• Kat Clancy  – Deakin University
• Brianna Laugher – Wikimedia Australia
• Gerry White – Internet Society of Australia

I’m actually quite excited by what is in store on Saturday – with most of the Pub Standards / Linux Users of Victoria people in attendance. There is just so much value in FOSS that non profits, community organisations and educational institutions can benefit from.

I recently bought a cheap USB Bluetooth dongle because my older Acer TravelMate 4070 came without Bluetooth support. Big mistake. The dongle (a Laser N1968) ships with BlueSoleil – a suite of Bluetooth drivers for windows. My Nokia 6110 Navigator and PC Suite simply hate BlueSoleil – after umpteen pairings and unpairings of the devices, driver installations and re-installations and checking all congifurations, I simply cannot get BlueSoleil to work properly with PC Suite. What a piece of rubbish! C’mon people, Bluetooth is all about interoperability!

• PC Suite version : 7.0.8.2
• BlueSoleil version: 2.1.2.1

Will try the Widcomm drivers as an alternative to BlueSoleil and see how they go…

I’ve recently been joined by a new colleague, who will be taken over Problem Management duties while I’m seconded to something else (improving video conferencing). In chatting with him, he mentioned that Kepner Tregoe is quite a dated model, and that it isn’t all that useful. Ever since doing my KT training in 2007, I’ve tried to find ways to apply it – to the ITIL Problem Management process itself, or to everyday rational decision making. Personally I find it quite a useful tool, and so am always interested to explore further when someone quite passionately takes the opposite stance.

One of the key tenets of Kepner Tregoe is that changes cause problems. Alterations in supplier, materials, personnel, work practices, equipment, raw materials etc can lead to a defect (or in KT terms, a ‘deviation‘). This is particularly applicable in the IT world – as configuration changes, hardware changes, script changes etc can all lead to a deviation. Although we have quite a mature Change Management process, and in most cases a clear audit trail of all Changes made to a Configuration Item, there are times when the ‘changes cause problems’ mantra, while valid, is of limited value. For instance, let’s take the principle where a problem caused by a change can first occur at any point after that change. What if the change occurred a while ago and in the interim there have been several other changes? It then becomes more difficult to try and identify how a change has contributed to a problem.

This is a downside of KT problem analysis – so the question becomes how then to avoid being unable to determine which change caused a problem. ITIL Change Management can contribute partially to this – by helping to bundle changes into change windows, and eventually reduce the rate of change. If the dependencies of a Change and the Configuration Items involved are adequately identified, this can also provide better information to link a change with a problem.

Another downside we have seen with KT in recent weeks is that it is still very dependent on specialist (subject matter expert – SME) knowledge to identify the most probable cause. Even after comparing similar objects to identify distinctions, and reviewing changes to see how these could account for the defect or deviation, in many cases there is still a great deal of technical knowledge required to formulate a probable cause. One wonders if this is a true downside – as it would be fair to assume that in a specialist technical field, it will be the specialist who undertakes root cause analysis. After all, would it be appropriate to have a dentist find out why you have a pain in the stomach?

I suspect I will have many more interesting Kepner Tregoe conversations in the coming months…