Wednesday, June 9, 2010

Blocking and tackling

The more I read, and the older I get, the more focused I become on results. At the end of the day, people care about outcomes, and are less picky about the path we take to achieve them.

Many of the success stories about ITIL are really success stories about the culture of CSI. You'll see a common thread among them.

Establish clarity around goals and objectives tools later (perhaps MUCH later)
Get quick wins to build momentum
Focus as much on the organizational change as on the tools
Be willing to win a little at a time to win a lot in the long run.
Get better every day...not every 6-month review

As I counsel my clients, resist the temptation for large-scale CMMI Level 1 - 3 moonshots and focus on establish real commitment to CSI.

Do you have established processes, including written policies, procedures, and process owners?
If not, what are the 2-3 most important things to get started?

- Clear goals and objectives
- Accountable, empowered owners
- Reliable Metrics

Don't try to implement all the processes at once. Focus on processes and services that will optimize the value and help you achieve quick wins...Incident, Change, and Request Fulfillment come to mind as great places to start.

BTW, RF is consistently underrated (maybe because it doesn't make any vendors rich)...spending time making "routine service requests" really routine, for you and your users, is enormously beneficial.

Start small to win big!

Tuesday, June 1, 2010

More on PM and ITIL

Ok, so I have been thinking about Carol's and IT Skeptic's comments about PM (and have read the thread he pointed me to, and an awful lot more) and I still think this comes down to a simpler notion. We have a yawning, enormous gap in most IT organizations between Design and Operations, in many cases cast in stone through outsourcing deals to different entities with no aligned targets or shared accountability. This creates the hot potato issue with which so many of us are familiar, and which really drives my interest in service transition, and particularly in placing Early Life Support (ELS) firmly in the hands of Release and Deployment Management. It is in fact the job of PM to manage the SUCCESSFUL transition of their project deliverables (which we'll assume to be a new or changed service) into the live environment, and to support it until

1) The service is accepted by the customer AND
2) The service is meeting its designated service levels (this implies successful event mgmt, operational monitoring and reporting, and other operational readiness capabilities that really should be flushed out more as part of testing and validation activities).

Project Management (and Software Development Lifecycle Mgmt, but that's another article) need to be able to coordinate service design and transition activities, and I would liken it to the approach ITIL takes with functions. PM necessarily coordinates across all the activities in service design and transition...based on the scope of their project. Process team leads perform activities across multiple projects in support of process goals and objectives (which should map to project goals around, for example, functional and non-functional (or warranty!) requirements).

The actual ITIL books don't in fact describe exactly how to run projects (and rightfully leave this for the complementary guidance), but like a similar discussion currently on one of the LinkedIn threads about how ITIL leaves appropriate space for governance models (can anyone say CObIT), it really does so for PM as well, leaving flexibility needed to encompass large programs and small projects alike, while still providing a core set of building blocks needed to build a good service.

I'd like to hear from all of you...where do you see the big gaps, and what are your recommendations for addressing them? If you were writing ITIL 4.0, what would you add/remove/change to improve the efficacy of the guidance?