When Does a Project Become Operations? Four Signs Instead of a Go-Live Date

On go-live day, responsibility changes hands on paper. How to tell whether it has reached day-to-day work as well, and why getting there is part of the project.

When does a project become operations? The question sounds simple, and many organisations have a quick answer: on go-live day. Or at acceptance. Or when the project is formally closed.

All three answers name a point in time. That is the problem.

A point in time says when responsibility is meant to change hands. It does not say whether the people taking it over can actually carry it. That is why the months after go-live look so similar in so many projects. The project manager is still the first person people call when something breaks. Changes go “through the project, just this once” because the regular route takes too long. Operations has taken the service over on paper, but not in practice. And at some point a “phase 2” appears in the plan, collecting everything that should have been part of the handover.

My answer is not a date. Operations is a state, and you can check it against four signs. As long as one is missing, you have a project with users, not operations. The stretch that gets you there, the hypercare period after go-live, therefore belongs to the project, not to the time after it.

This matters to project managers who build something that somebody else has to run afterwards, to the teams who are meant to run it, and to leaders who oversee both sides and wonder why a closed project is still tying people up.

Three worlds, three answers

If you teach project management, service management and DevOps side by side, you soon notice that the three worlds answer the question differently, and each answer has a blind spot.

The classic project world — PRINCE2, the IPMA Competence Baseline — treats closing the project as a step in its own right. Products are accepted and handed over, open items become follow-on action recommendations, and the project is closed. Acceptance checks whether the result matches its description. It does not check whether anyone can run it. PRINCE2 does require operational and maintenance acceptance, and the project product description already sets out how acceptance will work. In practice, though, this often comes down to a signature at the bottom of a list that operations reads under time pressure.

Service management as ITIL describes it starts with a different question: what is a service? ITIL gives you the vocabulary for what operations needs. The service is in the catalogue, incidents have a defined route, changes go through a governed change process, and the knowledge sits where the service desk needs it. That gives the transition a structure. The blind spot is in how it gets applied: the structure turns into an eighty-point operational acceptance checklist, operations says no, the project escalates, and the handover becomes a negotiation between two departments instead of shared work.

DevOps seems to make the question go away. “You build it, you run it,” as Werner Vogels put it in 2006. If the people who build a service also run it, there is no transition, because there is no other side. That works where a team really can do both and is allowed to. In many organisations the transition is still there. It has just moved: to the network team, the database team, the service desk, licence management, whoever is on call at night. It has not been removed. It has become invisible, and nobody is accountable for an invisible transition.

All three are right, and none is enough on its own. The classic world says closure has to be planned. ITIL says what operations needs. DevOps says the transition should be as small as possible. What is missing is a checkable answer to when the project becomes operations.

Operations is a state, not a date

Four signs are enough. They do not depend on the method the project used, and you can check them in an afternoon.

1. Incidents have an owner who has agreed to take them

When the service fails, the service desk knows where to send the incident. There is an on-call rota or set support hours, and whoever is on duty is not part of the project team. The second half of the heading is what counts: the owner has agreed. A line in a responsibility matrix that the operations team only hears about on Monday is not agreement. And the owner is a named person with a deputy, not a department. It has to be clear who picks up the phone when that person is on leave or off sick.

The check: log a test incident for this service with the service desk and watch where it goes. If the answer is “we’ll have to ask the project”, sign 1 is missing.

2. Changes take the operational route

A change to the service goes through the same process as any other operational change. Small, recurring changes are described and pre-approved as standard changes. It is settled who may change the rules for this service from now on. And nobody is still saying, “Let the project do it quickly, it’s not worth raising a change.”

This is the last sign to fall into place. The project route is well practised and fast, while the operational route looks slow. As long as the fast route exists, people will use it. And as long as they use it, operations never learns how to handle changes to this service.

3. The service is measured as a running service

A project measures milestones, budget and progress. Operations measures availability, incident volumes, resolution times and the lead time of changes. If the service does not appear in any operational report, it is not in operation, however many people use it.

This sign is the easiest to overlook and the most effective. Whatever is in the operational report gets attention, budget and time. Whatever is not gets done on the side. If you are serious about the handover, you put the service into the reports before the project team leaves.

4. The knowledge sits where the incident arrives

There is operational documentation that someone in operations has already worked with. Known errors are in the knowledge base with their workarounds. Access, permissions and contacts are not stuck in one project member’s head.

Again, what matters is in the qualifier: already worked with. Documentation that nobody in operations has needed yet is a guess about what operations will need. The proof is the first incident that operations resolves without the project team. Until then, sign 4 is only a hope.

When all four signs are in place and operations has confirmed the takeover, the deliverable is in operation, whatever the project plan says. If one is missing and the steering committee has not accepted that as a deviation with an owner and a date, the project is not finished, even if it has been formally closed.

Opens straight away, no account

The decision is made at the start, not at the end

The four signs are checked at the end. Whether they will be in place is decided at the start.

Who will run the result? That question belongs in the first week of the project, not the last, because it determines which requirements get raised at all. Monitoring, backup, logging, an access and permissions model, maintenance windows, documentation: these are operational requirements, and they do not come up in a requirements workshop without operations in the room. Operations is a stakeholder from day one and should be treated as one. If you only invite operations to acceptance, the missing requirements get raised there instead, and then it is called resistance.

The same goes for money. A business case that counts only project costs leaves out the larger part. Licences, support staff, maintenance and ongoing development come round every year for as long as the service runs. If that is not on the table at the start, the argument happens later, when the project budget is spent and operations has to ask for headcount nobody planned for.

Take a look and get started, the account is free

Hypercare belongs to the project

Between “the project delivers” and “operations runs it” there is a stretch in which both are true at once: the service is live, and the project team is still around. In IT this is usually called hypercare, and ITIL calls it early life support.

Hypercare is part of the project, not an extension of it. It is in the project plan from the start, with its own budget and tolerances, and the project ends on the day operations confirms the takeover, not on go-live day. If you only plan it once go-live has happened, you have to extend the project, which runs into three fair objections: the team has already been assigned elsewhere, the budget is closed, and the portfolio still shows the project as open.

Three things have to be agreed before hypercare starts.

The roles. During this period operations takes the lead and the project team backs it up. Incidents go to operations, operations works on them, and the project team helps when operations asks. Not the other way round. If the project team keeps the lead, operations never gets to know the service, and the period never ends.

The fallback. What happens if the service fails during this period and nobody can rescue it? Go back to the old system, carry on by hand, switch it off? That cannot be decided under pressure. It is decided beforehand and written down.

The exit criteria. The period does not end because four weeks have passed. It ends when conditions you can check have been met. For example: operations has resolved three incidents without going back to the project, the first change has gone through the regular change process, the service is in the operational report, and the service desk has used the workarounds for two known errors on its own. Those are the four signs, written as criteria. If you demand instead that no question ever goes back to the project, the period will never end.

If the criteria are not met by the planned end, there are two honest options. Either hypercare continues, visibly and with a stated reason, and the project with it. Or the steering committee closes the project anyway and accepts the gap as a deliberate deviation: each open item gets a named owner and a date on which it comes back on the agenda. The project manager quietly carrying on is not a third option.

Length says nothing about quality here. A hypercare period that ends after two weeks with its criteria met is better than one that drags on for three months because nobody defined any.

Take a look and get started, the account is free

A lot happens during this period that nobody will be able to reconstruct later: which incidents came up and how they were resolved, what was recorded as a known error, which questions still went back to the project team. If nobody writes it down, the period ends with an impression instead of a record. An agent that keeps a log works well for this: it takes incident tickets, minutes and notes, tracks what operations resolved on its own and what it did not, and shows each day which exit criteria have been met.

Take a look and get started, the account is free

How to tell it is going wrong

The symptoms look much the same in every organisation. These are the ones I see most often:

• Six months after go-live, the project manager is still the first person people call. Not because they want to be, but because everybody knows their number.
• There is a “phase 2” collecting everything operations still lacks. Documentation, monitoring, deployment automation: everything the project put off as “non-functional”.
• Developers have admin rights in production “because it doesn’t work otherwise”. That is not only a security problem. It shows that sign 2 is missing.
• Operational acceptance is an eighty-point list, signed two days before go-live. A list signed under time pressure checks nothing. It only settles who gets the blame later.
• The service is not in any report. Not in the availability report, not in the incident statistics, not in the change overview. It exists for its users, but not for management.

None of this is a criticism of either side. These symptoms appear when the question “when does this become operations?” is answered with a date and nobody looks at it again.

What this means for three roles

Project managers: hypercare is a work package with its own effort estimate and its own budget, not the last milestone.

Operations: an operational acceptance fits on one page, and every point on it is one of the four signs or part of one. If you say no, say exactly what is missing.

Leaders: a project counts as closed only when operations has confirmed the takeover. If the project team is still tied up months after go-live, that does not show an unusually committed team. It shows a handover that never happened.

Where the check changes shape

The four signs assume there is an operations team inside your own organisation. In three cases the check changes shape but does not go away.

A provider or a SaaS vendor runs the service. Then the owner in sign 1 is the provider, bound by a service level agreement with response times and an escalation route. Inside your organisation you still need a named person with a deputy who knows that route and has used it at least once. Signs 3 and 4 stay with you either way. If you neither measure the provider nor know which errors it is working around, you have outsourced your attention, not operations.

A regulated environment prescribes the acceptance list. In medical devices, energy or financial services, the eighty points are not a bad habit but an obligation. The four signs do not replace that list. They come on top of it. The list shows that the requirements are met. The signs show whether anyone can run the service on Monday.

The team runs it itself. Then sign 1 is in place quickly, once it is settled who in the team is on call and who covers for them. Sign 2 often is as well. Signs 3 and 4 matter all the more, because nobody from outside asks about them. A team that builds and runs a service tends to measure itself on the building alone, and its knowledge sits in people’s heads rather than in documentation a new team member can work with.

The four signs at a glance

1. Incidents have an owner who has agreed to take them. A named person outside the project team, with a deputy and known availability, and the service desk knows the route.
2. Changes take the operational route. Through the regular change process, with standard changes for the recurring ones, and no shortcut through the project.
3. The service is measured as a running service. Availability, incidents, resolution times, lead time of changes. The service is in the operational report.
4. The knowledge sits where the incident arrives. Documentation, known errors and access are with operations, and operations has already worked with them.

Plus hypercare as part of the project: with agreed roles, a fallback, and exit criteria derived from these four signs. The project ends when operations confirms the takeover.

If you want to try this yourself

Two things need no sign-up: the four signs at a glance and the list of symptoms. You can take both into your next handover meeting exactly as they stand.

The four tools linked above are all free. On the public resources page you can see the title, purpose and context of each one, and download the template directly. Only the prompt texts and the guide itself need a free account.

Open the resources

How much of a change’s lead time is really waiting time, and why four fast departments can be slow together, is the subject of a separate article: Flow efficiency: is there a typical value?

In closing

When does a project become operations? The question is hard to answer mainly because it is usually asked too late. At the end, when the budget is spent and the team is already on the next project, the only answer left is a date.

Ask it early and you get a better answer: a project becomes operations when the four signs are in place and operations has confirmed the takeover. That happens at the end of hypercare, and hypercare belongs to the project.

A project is not finished when it is closed. It is finished when somebody else gets the call and can deal with it.

Whether that works out is decided in the first week, when somebody asks who will run the result later. It becomes visible with the first incident that operations resolves without calling the project. It is sealed when operations confirms the takeover.

That day belongs in the plan, just not as a date, but as a condition.