When is a project ready for production hand-over? In some organisations this is when it has passed testing. Testing addresses what ITIL v3 calls Utility and Warranty: it does what it should, and it does so reliably/dependably (see Service Strategy (the “leaf book”), p 33).

But there is more to consider. Without these further considerations, many projects are as welcome in production as a dead cat, and those in IT feel they have as much say in receiving the system as a neighbour does in receiving the cat over the wall.

Some organisations accept a project after it has been in production for a Warranty period (not the same meaning of “warranty” as ITIL Version 3). That is, the project team operates and supports the system and resolves all incidents and problems for a defined period after go-live. This is an excellent idea, but on its own it only means we are deferring the cat-toss for a month.

ITIL v3 talks about operational readiness: testing that the system can be deployed and deployment can be verified, the service can be monitored and measured, it can be operated, users and service providers can access it, and it meets service levels (see Service Transition (the “peas book”) p 101). This is a most important concept, and operational readiness should be a formal test criteria, as it is in ITIL v3. One way to think of this is that the IT operations group perform their own acceptance testing, as well as the users doing so.

There is an element of locking the stable door in operational readiness testing. We need to work back to the start of the lifecycle and influence operational robustness (not an ITIL v3 term), i.e., how the system was designed and built:

Does the system include: functions and processes defined and tested for start-up and shutdown, availability checking (end-to-end test transaction), user provisioning, releasing locks, processing logs, data archiving, reversing a transaction, recovering a deleted object, data cross-check, reporting cross-check, ands data quality audit?

Is it a self-correcting system: transactional integrity, referential integrity, automated error recovery, automated rollback and restart.

Is it an integrated design?

I see too much “Tarzan software”. When Tarzan sets out swinging from vine to vine, it needs just one vine to be in the wrong place for him to end up on the jungle floor. Applications that pass data into a database file for a batch process to pick up; broadcast messages hopefully without confirmation; rely on external spoolers … these are a recipe for error if they do not have control and visibility over the entire transaction from end-to-end; if they cannot check that a transaction is viable before starting it; if they do not confirm the transaction was successful; and if they can’t roll it all back if it wasn’t.

Moving On