StixCampNewstead is go for 14th-15th March – call for sponsors

You’ve probably heard of the BarCamp phenomenom which brings together technically minded folks in a forum to share, innovate, learn and collaborate. Victoria has now had two BarCamps, both organised by Ben Balbo. The first, in rural Victoria was held in 2007 with a very successful city based event in 2008.

This year, a rural based BarCamp event, StixCamp, will be hosted in Newstead, central Victoria.

We’re now putting out the call for sponsors – whether it be $$$, products for prizes, in kind sponsorship such as catering or anything else you can think of. So if you or a business you know of is keen about technology and wants to assist in growing and nurturing the bright young sparks of Victoria, then please get in contact. In return, we can offer the following;

Sponsors will have their logo on the website and the web site, linked to a URL of their choosing. These logos will be on the main page until the nextBarCampMelbourne or Victorian StixCamp are announced, at which time they will be available in archives within those two sites.

Sponsors will also receive verbal thanks and recognition during the opening and closing speeches, and in any communication with reporters. Press releases will also name all confirmed sponsors at the time of release.

Seven things

The Seven Things is starting to take off in the blogosphere so thought I would do my bit…

So, here’s seven weird and wonderful things about yours truly;

  1. My first computer program was in BASIC on a ZX Spectrum, stored to secondary memory on cassette tape (yikes!). It was basically a menu selection program which invoked different subroutines based on menu choice. Yep, essentially a case() statement…
  2. My first job out of high school was as a copy typist, a skill which comes in handy as a programmer / IT person
  3. I had no hair until I was two years old (true!!!) and my nickname was Hare Krishna…
  4. My favourite food is spaghetti bolognese
  5. I can swim 3kms without stopping
  6. My favourite authors are Paulo Coelho and Jostein Gaarder, oh and William Gibson and Neal Stephenson too!
  7. I hold two degrees – a BSc majoring in Information Systems and a BA with majors in Indonesian language and security studies.

The duly tagged:

Donna Benjamin: For being open, creative, collaborative and all of the other things that makes Open Source a great field to work in.

Pia Waugh: For rejecting societal norms, stating that the world can be a better place, and then making it happen.

Lorna Jane Mitchell: A fellow knitter, and inventor of the PHPWomen-branded elePHPant.

Elizabeth Naramore: Because she rocks 🙂 And also for her work on

KaityGB: For showing us that no matter what we’re faced with, there’s always a way to create, dream and achieve

Meg Sawyer: For being herself

Ainslee Hooper: For correctly identifying bullshit.

The rules:

And here are the rules:

  • Link your original tagger(s), and list these rules on your blog.
  • Share seven facts about yourself in the post—some random, some weird.
  • Tag seven people at the end of your post by leaving their names and the links to their blogs.
  • Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.

Kepner Tregoe: Is it useful for ITIL Problem Management?

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…