The Rubic’s cube is 40 this year, a puzzle that to many people seems to be the play thing of maths geniuses and the friendless. I can solve a cube in about 2 to 3 minutes and I’m certainly no maths genius (and I have a couple of friends at least). If you don’t believe me check out the video below, those are my hands. So how do I do it, what makes me so clever?
Simple, I learned a process…
How to solve it (this isn’t the actual solution, just how to get there)
People who don’t know how to solve a cube think that solving it means being able to see and understand from the very beginning how to move every square colour about so that it will all fall into place. In fact all you need to do to get all the same colours on the same face is follow a set of progressive steps:
For each of those 7 steps there are a couple of standard moves to learn for each step to get the colour in the right place. Easy.
The point I want to make is that a seemingly highly complex task is solved by just breaking it down into simple steps and following a process. So how many other impossibly difficult tasks in life can be understood and resolved by just understanding how to get from start to finish in simple, manageable steps?
Something to think about.Read More
The inevitable delays start arriving in the form of too many other things to do and risk losing momentum on this project. Two issues are in my mind that need to be made aware of in order to avoid the risk of a significant loss of time due to inertia and “oh yeah, I didn’t really get back to that”. Firstly, the project end point doesn’t have a critical “it must be completed by xyz date or dire consequences will ensue” so slippage is not perceived as a problem (or at least not until very late in the day). The second problem is (and this is just a hunch) that while management at a corporate level are keen to see ISO 20000 accreditation (through implementation of ITIL) my managers don’t share the same level of ITSM evangelism as I do. It’s not that they don’t support what’s being done but the pressing issues on their radar have priorities that sit above me generating lots of nice documents with pretty flow charts in them. Last week I was told my job now included being Product Manager for a couple of our clients following a reshuffle of staff and roles. This is fine other than it gives me less time to devote to ITIL work.
It’s a chicken/egg problem to my mind in that getting effective and controlled ITSM processes in place would go some way to reducing some of the headaches currently being experienced with the workload, service delivery, SLAs and so on. All in all it needs to be about being able to continue to maintain the business case for implementing ITIL – demonstrating that to management and colleagues (and myself) and ensuring the balance of time set aside for ITIL work is correct should see that while it might take a little longer that expected the end point will still be reached. The take-home message being, accept that changes have occurred that mean the project will take longer but don’t allow the impetus to keep things moving from being lost. Less time needn’t mean no time.Read More
The inevitable happens and other duties get in the way of The Plan. Despite setting aside 50% of my time to ITIL work somehow this amount of time never quite fully materialises. Of course there are days where more than 50% is available but in a single week the full 37.5/2 hours is not achieved. The nature of this project is that there isn’t an absolute finish date. While that might be a good thing insofar as a day or two dropped here or there would cause a major business road crash, a woolly completion date runs the risk of the project drifting and getting “forgotten” during times when there’s a lot of other things to do (i.e. the priority slips to easily down the ladder) and the next thing you realise is that you’ve lost weeks or months from your schedule – the momentum’s lost and it takes even longer to get it all back up and rolling again. Have target dates and stick to them, even if notional (all of a sudden someone in senior management might decide the date isn’t notional but quite real, even if only in their head cf ISO 20000 below).
So some days have been lost and dates in the project plan have had to be re-adjusted but on the plus side, some original time estimates for grade 1 to 2 items have been too generous (2 days given where 1 was enough) and this has helped keep delays to a minimum.
To add some pressure, there have been questions about ISO 20000 and when can they do a “mock audit”. Any ISO 20k implementation really does need some ITIL processes to be in place first but having finally managed to get hold of literature that describes what’s needed to have ISO 20k in place I get a sense that there’s a huge amount of work to do this and be in a position where there are even documents and metric evidence of ITSM even being practised and importantly, actively being subject to CSI.
More days please.Read More
Creating documentation for grade 1 processes (the ones where if we are doing it I know nothing about it and here’s where we start) has been instructive. For each item (such as Service Level Management) it mostly entails going through the ITIL books and then writing a summary of what the process is about, what we should be doing, and likely people to be involved (either to question them later about what’s what or to give them process owner role). We’re not a very big organisation so not a big job generally.
This week I started on the grade 1 to 2 processes where it occurred to me that the summary paragraph written in the grade 1 description documents will make a good starting point for grade 2 process descriptions (during phase 2). Meantime I effectively having to write this type of paragraph for the grade 2 doc and then also put together the RACI chart, any Visio diagrams, role descriptions, objectives, outputs, associated documents etc…
Even after all of this, I’m still just generating dozens of documents. What will really, really, make a difference is when people actually start doing things according to ITIL guidelines generated here, and importantly, we start to generate measures to allow us to make meaningful improvements to services.Read More
Great plans never quite work out they way you expect. Having devised a brilliant and perfectly formed plan to get ITIL processes gradually up to speed I immediately fell behind on day 1 by forgetting that I was taking day 1 (Monday) off on holiday. Oh well, lesson learned #1: check your holiday schedule when planning.
Yesterday and today got through 3 processes, albeit rather tricky Service Strategy processes that are more concern to the senior management than me. Nonetheless, I put together some nice background descriptors for them to help them help me to devise the finalised ITIL process description document.
Next up are the difficult ones (to get to grade 1) of Service Level Management and Service Catalogue Management (given we don’t have a service catalogue as such – not formally at least). Both of these will need input from our admin and product manager, respectively.
Onwards and upwards.
So following the maturity assessment I now have about 20 processes that are to be made into fully functioning ITIL processes, some are level 2 (see my previous post), more are level 1, many are level 0. And none are 3. My next activity has been planning how to convert these into level 3 so I’ve decided to take a 3 phase approach (there’s too much to do at once and it’s better to learn along the way). Each phase concerns the “lifting” of processes up 1 level; level 0 to level , level 1 to level 2, and level 2 to level 3. Phase 2 has now 0 to 1 to do. I’m expecting 2 to 3 to be the hardest as this is the one that involves people: getting them to actually do stuff.
My first estimate is that phase 1 is going to take 18 working days (effectively 36 days if 50% of my time available for this – factor in the weekends and that’s about 7 weeks). Oh, and thinking about running this roll out as a PRINCE2 project. Probably.