Start with the situation, not a service menu.

You do not need to diagnose the problem before calling. Start with what is not working and the result you need.

A. IT Operations X-ray

Something is wrong, but the cause is unclear.

When this fits

Repeat incidents keep returning.
Planned work keeps losing to urgent work.
Queues and handoffs are hard to explain.
Tools, vendors, governance, or leadership changes have not changed the outcome.
Leaders cannot connect spend, risk, and delivery to one clear cause.

What you get

A clear view of how the work and decisions actually move.
Evidence tied to the findings.
The few operating constraints creating most of the problem.
A sequenced plan the existing team can execute.
A readout that forces the calls needed to start.

I map only the 2 to 3 flows needed to explain the constraint. An X-ray is not a full ITSM documentation exercise.

How long it runs: Typically 3 to 5 weeks, with about 4 weeks as the target.

What you own afterward: The findings, action sequence, roadmap, evidence expectations, and a clear record of what must be decided and who owns execution.

How it ends: You know what is driving the problem, what happens next, and who will carry it. Plain Ops hands operating control back rather than creating long-term dependency.

B. Optional Execution Leadership

You know what has to change, but nobody has room to run it.

Execution Leadership often follows an X-ray and may also stand alone when a decision-quality diagnosis already exists.

When this fits

A decision-quality diagnosis already exists.
The first operating changes are known.
Internal leaders cannot give the work sustained attention.
Decisions and cross-team dependencies keep stalling execution.

What you get

Temporary leadership for an agreed period.
Clear owners, decisions, order of work, and review schedule.
Priority changes installed or moved into stable execution.
Internal owners prepared to continue without outside pressure.

How long it runs: Typically 12 to 16 weeks.

What you own afterward: The operating cadence, priority mechanisms, artifacts, and active internal ownership.

How it ends: The agreed period is done, or the client team is running the work.

You know the result you need, but the work is not getting done.

When this fits

The deliverable or operating result is clear.
The work crosses teams, vendors, executives, or specialist functions.
The source material is fragmented or inconsistent.
Decisions are buried in meetings, comments, or competing documents.
The organization needs someone to reconstruct the real state and carry the work to a defined completion point.

What you get

Agree on the result, what counts as done, who can make which calls, and how the work hands back. Then finish it. Depending on the work, the output may be a release-ready operating package, decision set, governance artifact, recovery plan, implementation package, or another clearly defined result.

How long it runs: Set by the work, evidence, stakeholder access, and required completion date.

What you own afterward: The finished work, the decisions behind it, a list of what is still open, and who owns what next.

How it ends: The agreed work is finished and handed back to the client.

Fractional IT Operations Leadership

You are without an operating owner for a while.

When this fits

A leadership role is open or in transition.
The environment needs stabilization after an incident or acquisition.
Managers need temporary operating support.
A permanent owner is expected but not yet in place.

What you get

Focused ownership of a defined IT operations remit.
Operating reviews and priority discipline.
Coordination across internal teams and vendors.
Transition to the permanent or internal owner.

How long it runs: Based on the transition and responsibility required. It is not open-ended outsourced management.

What you own afterward: A stable operating rhythm, clear decisions, current roadmap, and prepared successor.

How it ends: The named client or permanent leader takes control.

How I work

I critique the system, not the people.

Your team usually knows where the problems are. I make those problems clear without turning the work into a performance review.

I focus on patterns, handoffs, decisions, and evidence. Findings are not attributed to individuals.

What I look at underneath the symptoms

The exact flows depend on the problem. Common constraint areas include:

Who owns the service or result, who can make which calls, and what still waits for escalation.
Intake rules and how much work is allowed to stay active at once.
Vendor lanes, handoffs, and acceptance criteria.
Change gates and release discipline.
Incident closure, problem follow-through, and repeat-driver removal.
Whether executive reporting matches operating reality.
Capacity, prioritization, and what gets displaced when urgent work enters.
Service levels and operating guardrails that people can actually run.

When the obvious fixes have already been tried

Plain Ops starts by asking what the prior fix failed to change.

If work can still bypass intake, a new tool adds another lane without fixing priority.
If unresolved work has no clear finish, more headcount spreads the same backlog across more people.
If routine calls still climb the management chain, another governance layer adds reporting without shortening the wait.
If incident review does not create tracked follow-through, the same failures return with a new date on them.
If a new leader inherits the same operating rules, the organization can repeat the same cycle with a different person in the chair.

The question is not what else to add. It is which operating mechanism the prior fix left unchanged.

Not a fit

Full ITSM process documentation when the process itself has not been shown to be the constraint.
A favorable score or reassuring narrative.
A multi-year transformation program.
Permanent outsourced management.
Picking tools before anyone has shown the tools are the problem.
A narrow technical audit outside my competence.
Work where the decision makers are unavailable or nobody has agreed what done means.

Choose tools after the work problem is clear, not before.

Start with what is not working.

I will tell you whether the problem fits Plain Ops and what a useful first conversation should cover.

Let's Talk Email Nick