Transformation Services – Effective ITSM vs. “Passport Processes”

In an ideal world our ITSM discipline would be mature enough to not require the use a separate process. A passport document outlining the current service state would already exist in the Configuration Management System, all dependencies would be mapped and would understand support and warranty levels for everything.

Project teams could go to the CMS, the Service Acceptance Criteria (SAC) process would be invoked followed by RFC and Release management ending with a migrated service.

In reality though it is often suggested that a “Passport Process” should be utilised to handle IT transformation activities.

What is a passport?

A phrase that seems to crop up a lot in conversations regarding transformations is the “passport process”.

For those of you not familiar a passport process is used to describe the discovery and documentation of the current as-is state of an application in readiness for transformation or migration.

So one of the important details we need to understand is what is included in the passport. Generally speaking the passport will contain a service description, ownership and support information. A list of all configuration items associated with the service. So to summarise it should contain an AS-IS description with supporting information. Now this is much like a UK passport.

The right to travel

This is where I think the phrase “passport” term breaks down. As well as the above information several places I have been have also included the TO-BE and detailed migration plan. Now depending upon the ITSM maturity of the organisation this seems odd to me – in fact it seems odd to me in terms of travel as well. See to travel to say China from the UK we need certain documents. We need to hold a valid UK passport, we also need to have a VISA.

To me the passport should contain the AS-IS information. We should then create a migration certificate (VISA) which is a pre-check to show that supportability and security of the To-Be has had a level of QA (governance and compliance). This data should then feed into the RFC process enabling the service transition to be completed in line with organisational change management and release management processes. This approach should in turn reduce the time and effort and level of process change required to transition a service. While there is no specific “right” way of handling this to me this seems like a clearer description than just calling it the “passport process”, it should also keep roles and responsibilities for enabling the transition intact with standard business as usual changes, the passport team are then acting as a facilitator prior to RFC, not becoming a bottleneck and keeping the responsibility of the system owner/business to take any required actions to complete a Change request.

In Conclusion

Regardless of how the service transition process is designed at some point a body has to act as Border Control. The change management function is built with this purpose, it seems strange to me to not use that as the mechanism to deliver service transition. To me the “Passport Process” is a band aid for low maturity ITSM processes. Not to say a band aid shouldn’t ever be used. It just seems that the effort could be spent improving the organisations ITSM processes which can remain in place rather than creating programme/project specific process that will be retired upon completion.