Who owns the system during the go-live warranty period?

Transitioning a project into Production is a complex process. One of the trickiest parts is transitioning responsibilities.

"Go-live" is sometimes seen too simplistically as a handover to Operations, as if Ops will magically run it from Day One without help. Or DevOps sees it the opposite way, where Operations plays a minor role forever.

There needs to be a transitional phase.

ITIL calls a transitional phase Early Life Support, which incidentally must be one of the worst names of all time. The ITIL authors meant Early-Life Support but all anyone hears is Early Life-Support, which is entirely the wrong connotation. ITIL Service Strategy already used the word "warranty" for the concepts of "utility and warranty" (look it up) and so there seemed to be a reluctance to call Early Life Support what it really is: the Warranty Period.

DevOps sometimes thinks it changes the picture, that a DevOps team eliminates the need for Operations - which gave rise to that hideous and ridiculous term "NoOps". Of course it doesn't, not in the wider sense of Ops that includes more than technical boiler-room tasks and takes into account service support. We need a concept of DevOpsRun to get the whole picture. Somebody has to take and allocate incidents. Development teams are never truly supporting a standalone system in real world organisations. In Real IT somebody always needs to front services to the business, to allocate and coordinate response. In 95% of situations, users are not going to want to contact dedicated support for a system. They want a general help team to work out all their issues from desktop configuration to planned network outages to system failures.

It does get more complex in a DevOps situation, where the project will go live early in the process and then iterate. This is the huge challenge that the Agile method presents to normal business thinking: "the project won't deliver once, it will deliver many times, no we can't define for you exactly what the deliverables are at any of those milestones".

In my mind, that first go-live is the handover regardless of what follows: all teams and processes must be ready for the arrival of the system. Users expect to ring help numbers and have the Service Desk know what they are talking about, and for their desktops to include and support the new service. Customers expect reporting, service discussions, and funding transactions for this service along with all the others. A DevOps (or other Agile) approach just means the project has an extended lifetime with multiple delivery phases that happen to have short unpredictable cycle times... possibly measured in hours. But once it goes live it is in Operations whether a Devops build team likes it or not. Not all DevOps proponents understand this: they don't dig DevOpsRun.

A similar situation arises in a pilot, which goes live in a limited transitional way before an eventual full release: it doesn't matter from an Operations point of view, it is live and the organisation's teams and processes need to be ready for it.

In all cases, it is not enough for a project or development team to say "don't worry we will support it".

As often as not, the view of the project team is quite the opposite: "it's live, were done, the money is all gone, it's yours. Bye". That is of course equally unacceptable.

So the correct answer is always a middle ground where there is a transitional period: the project continues to exist, to pay close attention to the system, to work closely with Operations, to gradually transition knowledge and activity.

If you have gone live, Operations has accepted and owns it. You can't have anyone else own a live service: no accountability without authority and responsibility. And Operations is always accountable. Wait until a service fails catastrophically and see who the CIO calls first. Business units which are permitted to go live with Shadow IT services without the involvement of IT Operations are doing Dark IT: it represents a failure of governance and an abdication of responsibility by the executive.

I heard of an organisation A whose marketing people hired a media company B to get their brand onto public media. The media company B sub-contracted a little web development company C to build the associated website. The marketing department did not even tell the IT department of company A. The marketing department vaguely knew of the existence of company C. On the night of the media going live hundreds of thousands of people clicked on the website and it crashed. The CEO of company A called his CIO.
(To rub salt in the wounds: when the forums erupted with angry users, media company B assured everyone that the technical staff of company A were working on resolving it).

I don't care what the builders say: IT Operations owns live systems. IT Operations is accountable for the brand integrity and service levels of the organisation.

Then we have two scenarios (or shades in between):

1. A project team that is winding up must include funds and resources for some of its staff familiar with the system to remain during the warranty period providing one more Level 2 and Level 3 resolver teams. At the end of warranty, Level 2 and 3 support transitions to an Applications Maintenance team.
2. A DevOps project that will continue to improve a system after first go-live must provide Level 2 and Level 3 resolver capability. They also provide Level 1 support: they're on call from the Service Desk and/or direct from users. This is the only way to get attention bandwidth from them for incident and problem resolution.
   Eventually the organisation loses interest and the Devops team gets disbanded. Then Level 1 support transitions to Service Desk and Level 2 and 3 support transitions to an Applications Maintenance team.