Service Design: A Comedic Tragedy

# Leadership Insights

# Service Management

# ITIL

Lessons from a career spent navigating the all-too-familiar challenges of Service Design and Transition.

October 1, 2026

David Flacks

Service Design: A Comedic Tragedy

There is a moment in almost every technology project that deserves a formal place within IT service management.

I call it The Sudden Discovery of Operations.

It usually occurs shortly before go-live.

The project has been running for months. The solution has been designed. The build is largely complete. Testing is progressing. Reporting is reassuringly green. Senior stakeholders have been told everything is on track.

Then someone asks an apparently simple question:

"Who is actually going to support this?"

Silence.

And thus begins another episode of Service Design: A Comedic Tragedy.

Over the course of my career working across Service Design, Service Transition, ITSM and project delivery, I have seen countless variations of this story. Different organisations, different technologies, different suppliers, yet remarkably similar outcomes.

The irony is that most transition challenges are neither unexpected nor particularly complex.

They are predictable.

More importantly, they are preventable.

Operations Is Not the Final Destination

One of the most persistent mistakes in technology delivery is treating Operations as the destination at the end of a project lifecycle.

The model is familiar:

Design it.

Build it.

Test it.

Hand it to Operations.

The flaw is equally familiar.

Operations possesses knowledge that fundamentally influences service success.

Operational teams understand:

Monitoring and event management

Support volumes and escalation paths

Capacity constraints

Security and compliance requirements

Supplier dependencies

Maintenance windows

Recurring failure patterns

Recovery and resilience processes

Most importantly, they understand something architecture diagrams rarely capture:

What happens at 02:17 on a Sunday morning when something breaks.

That operational perspective should shape service design from the outset, not simply receive the outcome of it.

The £10 Question That Prevents the £100,000 Problem

Early operational engagement is rarely expensive.

In many cases, it is simply a matter of involving the right people at the right time.

During requirements and design activities, operational teams are likely to ask questions such as:

How will this service be monitored?

What constitutes service degradation?

Who owns each component?

What happens when automation fails?

Where are alerts routed?

What access will support teams require?

What diagnostics will be available?

What are the upstream and downstream dependencies?

Who provides support outside business hours?

How is the service recovered?

Where does supplier responsibility begin and end?

And perhaps the most valuable question of all:

"Has anybody actually tested that?"

These are not administrative questions.

They are engineering questions disguised as service-management questions.

Asked during design, they might result in additional monitoring requirements, configuration adjustments, or improved acceptance criteria.

Asked three days before go-live, they often result in emergency workshops involving fourteen people and a PowerPoint presentation titled:

Operational Readiness Recovery Plan v7 FINAL FINAL.pptx

The Service Acceptance Criteria Problem

Effective Service Design and Transition are not exercises in document production.

The objective is not to prove that a template was completed.

The objective is to establish whether the organisation can:

Operate, support, maintain and recover the service it is about to inherit.

That requires meaningful Service Acceptance Criteria.

Not:

Monitoring documented: Yes

But:

What must be monitored? What thresholds apply? Where are alerts routed? Who responds? Has that process been tested?

Not:

Support model complete: Yes

But:

Can the Service Desk identify the service, categorise incidents correctly and route them to teams capable of resolving them?

Not:

Knowledge transfer completed: Yes

But:

If the engineer who built the service leaves tomorrow, can someone else support it effectively?

There is a significant difference between:

Evidence of documentation

and

Evidence of operational readiness.

Mature Service Transition practices recognise the distinction.

Why Do Organisations Continue to Struggle?

Most organisations understand the value of early operational involvement.

Yet many continue to engage Operations too late.

The reasons are typically structural rather than procedural.

Projects and Operations Are Measured Differently

Project teams are generally measured against:

Scope

Schedule

Budget

Operations teams are measured against:

Stability

Availability

Customer experience

Incident performance

This creates an inevitable tension.

Projects ask:

"Can we go live on Friday?"

Operations asks:

"Can we support this on Saturday?"

Both are valid questions.

The mistake is allowing one to consistently outweigh the other.

Operational Readiness Is Not Exciting

New platforms are exciting.

Transformation programmes are exciting.

Artificial intelligence is exciting.

Support models, observability, configuration records, resilience testing, capacity planning, and escalation procedures rarely attract the same executive attention.

Until they fail.

At that point they become extremely interesting.

Engagement Often Arrives Too Late

One of the most common patterns is requesting Operations to "sign off" a solution they had little or no opportunity to influence.

That is not engagement.

It is an approval exercise.

Once a service has been designed and built, operational teams are typically presented with three options:

Accept the risk.

Delay the deployment.

Attempt late-stage redesign.

None are particularly attractive.

Governance Becomes Theatre

Many organisations invest heavily in governance structures:

Gates

CABs

Design Authorities

RACI models

Readiness reviews

Transition boards

Yet governance only provides value if it can influence outcomes.

A gate through which every project inevitably passes is not a gate.

It is scenery.

The purpose of Service Transition governance is not to ensure forms are completed.

Its purpose is to expose risk early enough for meaningful action to be taken.

Shift Service Transition Left

The technology industry has spent years advocating the concept of shifting left.

Testing earlier.

Security earlier.

Quality earlier.

Operational readiness deserves the same treatment.

Shift Service Transition Left

Bring Operations into requirements workshops.

Bring support teams into solution design.

Define Service Acceptance Criteria before build completion.

Establish support ownership before support is required.

Design monitoring alongside the application.

Test recovery alongside functionality.

Understand supplier obligations before contracts are signed.

Build the operational model alongside the technical solution.

When this happens, the transition into live service becomes what it was always intended to be:

A confirmation of readiness rather than the discovery of unreadiness.

Service Design Is Ultimately About Consequences

Some of the most valuable work I have undertaken in Service Design, Service Transition and ITSM has not involved introducing new processes.

It has involved connecting people who should have been speaking to one another months earlier.

Architecture understands the technical solution.

Projects understand delivery.

Suppliers understand their products.

Security understands risk.

Operations understands the realities of the live environment.

The role of Service Management is to bring those perspectives together and continually ask a simple question:

"What happens when this becomes a real service?"

Because eventually it will.

Real customers will use it.

Real incidents will occur.

Real engineers will support it.

Real suppliers will dispute ownership.

And real executives will ask why something seemingly obvious was not identified sooner.

The Final Act

The tragedy of poor Service Design is not that organisations lack knowledge, frameworks or experienced practitioners.

Most possess all three.

The comedy is that we continue to relearn the same lessons.

We know Operations should be engaged early.

We know supportability should be designed rather than retrofitted.

We know Service Acceptance Criteria should be defined long before go-live.

We know operational risks become exponentially more expensive the later they are discovered.

Yet somewhere today, a project is approaching deployment.

The dashboard is green.

The steering committee is satisfied.

The launch communications are ready.

And somewhere within Operations, somebody has just received an invitation titled:

"URGENT - New Service Handover."

The meeting starts tomorrow.

Go-live is Friday.

And nobody has invited the Service Desk.

Curtain up.

Enjoyed this post? Join the conversation by leaving a comment or sharing your thoughts below, we’d love to hear your experiences and perspectives. Don’t forget to explore our upcoming events for more opportunities to learn and connect, and visit the forum to continue the discussion.

Where conversation, connection, and real-world practices come together.