Who Owns the Work When You’re Not There?

The process has an owner. The owner is on leave. A change needs a decision before the next shift. Who can act, and where does their authority stop?

ORR IMS is an evolving learning example, currently connecting five starter kits. It is not a complete implementation of the four standards in its intended scope.

A responsibility chart may identify the right person for ordinary conditions. The more revealing question is whether the arrangement still works when that person is unavailable, information is incomplete or two priorities conflict.

These conditions deserve a place in implementation discussions. People should be able to recognise when they can decide, when they must seek advice and where an unresolved concern goes next.

For an IMS practitioner, that means examining the decision itself, including its boundaries.

A name needs a defined responsibility

The fictional Cedar Estuary journey assigns different responsibilities to several people. Lina owns the customer-specification risk and the related data. Arun performs the shift communication control. Sofia makes scoped resource and risk decisions. Maya coordinates implementation.

Those roles connect, but they are not interchangeable.

Lina’s responsibility for the specification does not make her the person who verifies every shift handoff. Arun’s responsibility for a check does not automatically give him authority to approve a new technical operating condition. Maya’s coordination role does not make her the owner of every unresolved obligation.

This is a useful starting point for examining your own arrangement. Ask what each person must deliver and which decisions they can make. A broad title such as “IMS owner” may conceal several different expectations.

What can this person actually authorise?

In the fictional case, Sofia’s delegation covers defined administrative decisions within the pilot. It does not establish authority to waive duties or accept every technical risk associated with the site’s work.

That limit helps explain why a competent specialist may still be required. A senior title cannot supply missing expertise, and a responsibility chart cannot make an unresolved technical criterion disappear.

When reviewing a decision route, describe the decision in concrete terms. Is someone approving a document, accepting a resource tradeoff, authorising a release or confirming that an outcome criterion has been met? Those actions may require different information and authority.

Also distinguish a person who recommends from the person who decides. The recommendation may be well founded, but the accountable decision needs to be identifiable. Otherwise, everyone can leave a meeting believing somebody else approved the next step.

Cover the absence before it becomes an emergency

Consider an illustrative variation on the case: the normal supervisor is unavailable when the next customer change arrives. The team needs to establish who will perform the control and whether that person can access the relevant information.

This variation is a discussion exercise, not a new event claimed by the source.

A useful relief arrangement includes more than a replacement name. The substitute needs to understand the work, the decision boundary, current issues and the evidence expected. They also need enough time and access to perform the role.

Ask how the transfer is confirmed. An email assigning cover may leave practical questions unresolved. Does the substitute know which changes are pending? Can they identify the effective instruction? What happens if they find an inconsistency?

These questions can expose a weakness before a real handoff depends on assumptions.

Make escalation a usable route

An instruction to “escalate to management” may be too vague to help somebody facing a live decision. Identify the receiving role, the information needed and the condition that triggers escalation.

Then examine what happens while the matter is unresolved. The appropriate response depends on the actual process, risk and authorised arrangements. Do not invent an operational workaround because a template lacks an answer.

In Cedar Estuary, missing prerequisites hold the affected administrative release decision. That is the fictional case’s defined response. A different organisation needs its own competent assessment and legitimate authority.

An escalation route also needs a response. If concerns are passed upward and disappear, the person raising them has no dependable way to know what to do next. A recorded decision should return to the affected users with conditions, ownership and any required follow-up.

Give owners the resources to own the work

Ownership becomes difficult when responsibility grows while authority, time and support stay unchanged. During implementation, ask what the owner needs to perform the role.

In the public example, a workload concern reaches leadership and results in allocated briefing time. The connection is visible: a control depends on an activity, the activity needs resources, and a person with authority makes a decision about those resources.

This is a practical subject for management review. Which controls depend on overtime, unofficial favours or one experienced person? Which owners are carrying conflicting responsibilities? Where has a deadline been accepted without examining capacity?

An honest resource discussion may change the plan. Record that change so the owner is not judged against an assumption that management has already made impossible.

Write an absence decision card

At a fictional consultancy, a project lead is away when a client requests extra work. A named substitute still needs a defined spending boundary, current commitments and a route for decisions outside that boundary.

Create one decision card: decision required, authorised role, deputy, authority limit, information needed and escalation recipient. Test it in a fictional owner-absent scenario.

Start with the beginner guide. What would your deputy need before deciding? Leave a comment below; a question or fictional example is enough. If you want to propose a document change, the contribution guide explains the optional GitHub route.

Use fictional examples only. Do not share employer or client records, personal information or copied standards text.

Images are AI-generated illustrations, not photographs or evidence of actual implementation.

Part 4 of 12 in Making IMS Work with ORR IMS. Explore the series.