Operational Readiness

Submitted by skeptic on Thu, 2011-05-05 23:26
Share this post with

There is a whole activity or function or ITIL-would-say process that gets neglected: Operational Readiness.

Without Operational Readiness we get Dead Cat Syndrome: dead cats chucked over the wall from Solutions to Operations.

I disagree with my friend Troy Du Moulin on this. Dealing with Operational readiness as a sub-practice of Release means we only look at one aspect: operational assurance. OR must be proactive and helpful. Relegating OR to release planning turns Operations into the gatekeeper, "the Department of No" (or Mordac the Preventer, for Dilbert fans). Operational Readiness operates from Architecture to Design to Build to Test to Release to Evaluation, a holistic approach to making sure the systems are alive and healthy when we in Operations get them (No Dead Cats). The "ITIL Manager Blog" took a similar view.

Operational Readiness is not a big job, but it benefits from some conscious attention and formalisation. I've done an assessment checklist and a framework or specification of the function. I spoke on this at this year's Pink Elephant conference in Las Vegas.


Comments

Submitted by David T. in Boise (not verified) on Mon, 2011-05-16 22:32.

ITIL?

Isn't what you describe one of the basic goals of ITIL in its entirety?

DT

Submitted by skeptic on Tue, 2011-05-17 10:54.

no practice = no focus

Is Operational Readiness one of the goals of ITIL in its entirety? Well yes but you could say that about other things like availability or change and we still have a practice focused on those. No focus = doesn't get done or gets done in a patchy manner or has redundancies and inconsistencies. Who makes sure that the architectural NFRs line up with Operational acceptance? Who proactively goes and engages with projects instead of setting them up to fail?

OR is too important to leave it to passing mentions in other bits of the books. Same as risk, or CRM, or project management, or training.

Submitted by Vikram Ranna (not verified) on Wed, 2012-03-14 09:51.

Within the organisation that

Within the organisation that I work we have called this the Operational Readiness Confirmation and Acceptance (ORCA) Process. Readiness gets initated when a project is at the initiation stage so that operational acceptance requirements are captured right at the beginning and the projects understand what their operational deliverable requirements are. Operational Acceptance comes into play post implementation ensuing that project has delivered against the requirements that were presented to them during the readiness engagement.

Submitted by Joe Jeffcoat (not verified) on Fri, 2011-05-06 21:18.

I agree...

Currently in my organization, Operational Readiness (we call it OAT or Operational Acceptance Testing) is a component of release. However, the problem we have is it is ony invoked from the project lifecycle, and not from the change lifecycle for products and services in production. There are several problems with this approach:
1) It's seen as a bottleneck between project build-out and delivery, and Project Managers feel it impacts their delivery schedules, even though they are told to plan for it
2) Because project schedules slip, but due dates do not, OAT always takes the hit
3) Cooperation from build and architects is limited because you're publicizing their "flaws"
4) Once a service is in production, changes are made that are not necessarily tested for operational readiness (a flaw in our change process).

I've always wondered how other companies deal with this. It's good to see it get some mention. Definitely interested in reading more from you on the subject sometime.

Submitted by skeptic on Sat, 2011-05-07 10:11.

Thanks Joe for feedback from

Thanks Joe for feedback from the frontlines! Yeah OAT is just shutting the gate. OR must be integral to the entire service lifecycle.

Want more? See Dead Cat Syndrome and my checklists

Submitted by David Zaucha (not verified) on Tue, 2011-05-10 16:18.

This is an interesting

This is an interesting topic... We call it Production Readiness in our organization, and have spent a lot of time over the last couple years to standardize it and bake it into the entire Development Lifecycle. It begins during project planning with a set of checklists that are iteratively revisited throughout the project to produce a set of standard artifacts designed to make the final production environment supportable.

Great point about the change process though... In our case, I would hate to see the same formal process being invoked through numerous changes, but certainly some sort of update or referential integrity to the original readiness documentation is necessary.

Syndicate content