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;
- 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…
- My first job out of high school was as a copy typist, a skill which comes in handy as a programmer / IT person
- I had no hair until I was two years old (true!!!) and my nickname was Hare Krishna…
- My favourite food is spaghetti bolognese
- I can swim 3kms without stopping
- My favourite authors are Paulo Coelho and Jostein Gaarder, oh and William Gibson and Neal Stephenson too!
- 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 PHPWomen.org
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.
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.
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…
I have some Paton’s Inca in a beige blend (the same colour that the One Piece Jacket was done in) but I can’t find exactly the sort of pattern that I want to knit, so it’s time to design my first jumper. I’m an information systems major rather than a textiles major, so I decided to apply software engineering principles to designing my jumper.
So, first of all, requirements elicitation. The business requirements of the jumper are;
- The jumper must accentuate my “assets” while downplaying any not-so-desirable attributes
- The jumper must fit, and should have plenty of stretch
- The jumper should be easy to maintain
- The jumper’s cost should be less than $150
Translating the business requirements into functional requirements;
- The jumper will have a v-neck that is 2o cms deeper than the top of my shoulder and shaping will begin 8 cms in from the shoulder. The v-neck accentuates the bust while drawing attention away from the hips and gives room for movement
- The jumper will be knitted in 1 x 1 rib to give shaping and stretch
- The jumper will have slight increase to allow for large bust and decreases for waist, possible increase for hips
- The jumper will have sleeves that finish 10 cm below the elbow (my preferred sleeve length)
- Paton’s Inca is $6 at Lincraft or $5.40 at K-mart (unless I can twist Damo‘s arm to get ACS to offer bulk packs cheaper). Therefore, the pattern must take less than 26 balls of yarn if I buy them at K-mart.
Next: knitting pattern design using functional decomposition