Checklist ITIL project proposal

From the book Owning ITIL®...

14 questions to ask about an ITIL project proposal

1. What is the vision? What is the strategy to achieve that vision?
2. What is the driving need or requirement?
3. How will success be measured? Relative to what benchmark measured now? Are we measuring with something other than ITIL? (See p36) Do the metrics measure the benefits stated in the business case?
4. What process maturity level(s) is the objective? (see p36)
5. Where is the value? Will it reduce costs, increase customer satisfaction, reduce risk, increase competitiveness or what? What dollar value can you put on that? Based on what metrics and where do they come from? Where is the real money?
6. Why do we need this? What is broken? (See p36) Do we really need best practice? Can we go for something simpler? (See p36) In particular is there a CMDB proposed? Why do we need it? (See p36) What does it give us over how it is done now? What pain or risk does it address? Weighed against that, what proportion of the costs is it? Does that include ongoing maintenance and audit of the data?
7. What resistance to this is there? Sometimes there is a good reason for resistance. Go ask the objectors.
8. What proportion of the budget is allocated to people-related activity: cultural change, training…? (See p36)
9. Where are the people resources coming from? People cannot do ITIL in their “spare time”. And the people doing this should not all be learning how as they go: make sure some external expertise is being brought in.
10. Who did the estimates (risk, time and cost)? What is their practical experience of doing this same thing before? Does that translate to this situation? Process change and cultural change are even more chronically underestimated than projects are in general, especially when estimated by technical people.
11. What ongoing activities will ensure the implemented changes stick, and that improvement continues over time? Who will own that? How will it be funded? See p36)
12. How does this integrate with other methodologies in use in our organisation? (See p36) …and other processes currently in place (e.g. procurement, project management, security, hires and fires, facilities)?
13. Have you chosen the tools yet? If so, throw it back. Tools come much later after process requirements are well understood. Technology driven projects usually fail.
14. Do the CEO and CIO support this strongly? If not what makes you think you can change that? No solid executive support = no hope.


Other checklists

Comments

15

15: Why are we doing this as a project and not as part of the day job

James Finister
Wolston Limited
www.wolston.net
www.coreITSM.com
http://coreitsm.blogspot.com/

tongue in cheek

Please tell me your tongue was in your cheek

Sorry to dissapoint

Not entirely*. It has become accepted wisdom that you have to do ITIL/ISM as a project. I've stood up and said it countless times myself in front of classes and conferences. Bur does the evidence back that up? It is certainly the main way people try and implement ITSM, but (And here I'll thank you for introducing me to "First, Break all the Rules") but since a high proportion of ITSM projects fail to achieve what they set out to do doesn't that suggests that a project based approach isn't the key to success? Sure you need project elements for some parts of the transformation, particularly if it involves a tool implementation. There is the rub, the IT department's idea of a project is always technology led, so the project ends up being about delivering things (process guides, tools) not about outcomes. Not only that but the IT project management expertise lies in the management of technology not in cultural change., which demands leadership and vision not a six feet long MS project Gantt chart.

There is a political dimension to this as well: Creating a project is a good way of attracting resources that are in the gift of key stakeholders, but removing those resources is a good way to kill a project, and killing a project is a good way of removing the resources. When an ITIL project is killed it takes a long tome to regroup

Finally deep down inside of me yes, I do think that IT is the day job, that is why CSI is so important in the ITSM world.

So actually I'm hardly at all tongue in cheek.

James Finister
Wolston Limited
www.wolston.net
www.coreITSM.com
http://coreitsm.blogspot.com/

the start of an ITIL transformation will always be a project

There's a whole chapter on this in the book Owning ITIL® where I say it is important that the transformation is not approached as a discrete piece of work that will end and everyone go home, ITIL done. When we say “You don’t ‘do’ ITIL”, we mean don’t do it as one lump of expenditure followed by none. In theory you could introduce an ITIL transformation as a constant regular spend to infinity, BAU. i.e. start a Continual Service Improvement Program and work steadily at transforming things at a constant rate of expenditure.
But:
• All ITIL initiatives need initial planning, analysis, design, organisation and promotion in order to overcome organisational inertia and establish momentum.
• In order to show return there need to be some initial quick wins and visible progress.
• And most organisations use a project structure to gate funding.
So the start of an ITIL transformation will always be a project, as should other smaller pieces of work.

Focusing the effort on cultural change instead of technology - as we should - means the project will be bigger, need more resources and even more desperately need to be a project in order to succeed.

One reason so many ITIL projects fail is because we dabble around with piss-fart efforts without giving them the grunt they need to make a real difference. If we really properly budgeted for the cultural change efforts and the process change and the ongoing efforts after the project is "over" then many projects would never get started and a damn good thing too. Then the percentage of successs would go up.

Evidence based management

Rob,

Ten years ago, even four years ago, I would have agreed with everything you say, and oddly it is some of your own thinking that now makes me think differently!

• All ITIL initiatives need initial planning, analysis, design, organisation and promotion in order to overcome organisational inertia and establish momentum.

Except a traditional planning analysis design cycle so often doesn't work for ITSM, because at the start of an ITIL transformation the organisation has no idea of what it needs to plan and design and does the wrong analysis. I've done many, many ITIL maturity assessments, and to be honest they hardly ever look at the root causes of why things go wrong. Assessment view: Do you check a change has worked after implementation? No. Recommendation: Start checking changes after implementation. Insightful? Reality : Your project teams think Ops are stupid. Your CIO spouts management speak that none of his reports understand, and your technical guys have zero empathy with the users.

What all ITIL initiatives need at the beginning are vision, commitment and a willingness to change.

• In order to show return there need to be some initial quick wins and visible progress.

Again I spent years coming out with the conventional wisdom about low hanging fruit. Quick returns kill the project because senior management turn round and say "Thank you, that will do, you can go away now." Reduced call answering time to 40 seconds? Fine, why bother doing anything else? It weakens the message that ITSM is about long term returns and long term investment. The trouble with the low hanging fruit is that they normally remove dissatisfaction, rather than adding long term value. Hence they have no perceived value after year 1. Nobody cares you grabbed the low hanging fruit once you've got it, in fact they just wonder why it took you so long in the first place.

• And most organisations use a project structure to gate funding.

See earlier post, making it a project also provides a way for the office politicians to kill your ideas dead. Your friendly major consultant of course loves it, because then you'll sign a contract for consultancy support for the entire duration of the project. And then you'll need us to set up a programme office for you, and a project office, and a work stream manager and... trust me, consultancies love ITIL as a project because of the money it rakes in.

So no, I don't think the start should be a a project. I think the start should often be done by stealth. See what we achieved at zero net cost? Ages ago we had a thread about what you could achieve by looking at a data centre from within the circle. How many of those suggestions would need a project to implement them? Save the project approach for when it adds most value.

"Focusing the effort on cultural change instead of technology - as we should - means the project will be bigger, need more resources and even more desperately need to be a project in order to succeed."

No, no, no! It is very rare Skep, but for once I totally disagree. It means the implications will be wider reaching and it means it will need to be different from how IT normally does things and need different resources. Make it a project and as I've said it becomes just another Gantt chart. Weeks 22 to 45 - change departmental culture. Making it a project, in the context of an IT organisation, just means those different things won't happen.

"One reason so many ITIL projects fail is because we dabble around with piss-fart efforts without giving them the grunt they need to make a real difference. If we really properly budgeted for the cultural change efforts and the process change and the ongoing efforts after the project is "over" then many projects would never get started and a damn good thing too. Then the percentage of successs would go up."

Or they fail because nobody really wanted to face up to the needed changes in the first place. Having worked for big consultancies I can't believe just how many millions some organisations are prepared to put in to a project that goes nowhere. The budget that matters for cultural change is not a cash budget, it is a social budget. Why do so many ITIL projects fail? Because senior management were never committed to them in the first place.

James Finister
Wolston Limited
www.wolston.net
www.coreITSM.com
http://coreitsm.blogspot.com/

shooting the messenger

You're right - we seldom disagree. I agree that this time we disagree. Your argument sounds like "We do projects badly because we don't actually do any cultural change in them especially at the start, so let's drop project management". I think you are shooting the messenger. Projects need real commitment and executive support, and they need people to face up to change. We don't fail at those things because it was a project. We fail because we did bad cultural change. We failed because we did it wrong not because we managed it wrong.

The messenger is the medium

I've designed two winning entries in the itSMF Service Management Project of the Year, and was heavily involved in a third winner. So yes projects can work, and yes all three of those projects had large elements of cultural change in them. On reflection though they succeeded despite being projects rather than because they were projects. In two of them the cultural issues were addressed because they were international organisations who had to address cultural issues as part of any project, but they both came very close to being canned as a result of politics. In the other one we were blessed with an excellent project manager who knew when to intervene, when to take the advice of the experts around him and who understood and cared about people. We we were also blessed with that great aid to successful ITSM - a burning bridge behind us.

We've slipped into a model where we think: Start with a project, then set CSI up at the end to keep things going. Result: Everyone relaxes at the end of the project, CSI never happens and three years later you have to do it all over again. In the UK, where we have a longer history of ITIL, some organisations are on their third or even fourth ITIL implementation project.

We should think: Establish sound basic ITSM, develop a CSI culture and then conduct targeted projects that can leverage the CSI culture to ensure benefits are delivered over the long term.

granular

I think we're on the same page, near enough. My book also goes on to say that projects should be ongoing and staged. So the firstb step is "Establish sound basic ITSM, develop a CSI culture " which should be well managed ;) followed by a anumber of small steps, equally well managed.

You are right to try to break the mindset of the mega ITIL project but lets not abandon PM altogether, just get a more granular approach to the whole thing, with cultural change up front to embed the ITSM mindset.

Fractal

Don't forget we need portfolio based programme management somewhere int he mix as well, and we need the right sort of project approach for individual processes. Waterfall works for rolling out a service desk in country A, country B, Country C, but bot for introducing problem management for the first time.

I'm working on the concept of fractal service management at the moment the idea that good and bad ITSM patterns of behaviour are replicated at different levels of granualrity within the organisation. what goes wrong in a user's interaction with a service desk agent gives you a clue about what is wrong with the service strategy.

Syndicate content