Who Maintains the Tool? Assigning Ownership After Launch

Launch day goes well. People log in, the old spreadsheet is archived, and the project lead gets a nice message from a director. Six months later, nobody remembers how the approval routing works, three requests for new fields are sitting in someone’s inbox, and a team has quietly started a “temporary” tracking sheet again.

The tool didn’t fail. It was orphaned. Every internal tool needs named owners after launch, and “the project team” is not a name.

Why tools get abandoned

Projects have a natural end date. Tools don’t. The people who built the system usually move on to the next thing, and the system drifts. A few common patterns:

• The builder leaves. The one person who understood the setup changes role, and their knowledge goes with them.
• Everyone owns it, so no one does. Each team assumes another is responsible for fixing problems.
• Requests have nowhere to go. Users ask for changes in passing, nothing happens, and they stop asking.
• Nobody is allowed to say no. Every request gets bolted on until the tool is a maze.

Post 50, “Single Point of Failure: Getting Process Knowledge Out of One Person’s Head”, deals with the knowledge side of this. This post is about the roles and routines that keep a tool alive.

Two owners, two jobs

Most internal tools need two distinct owners. In a small company they might be the same person wearing two hats, but the jobs are different and worth naming separately.

Say your customer support team runs refund requests through a new tool. The support operations manager is the business owner: she decides whether refunds over a certain amount need a second approver. The technical owner is the analyst who built the forms and automations: he works out how to add that rule without breaking the reporting.

When the business owner tries to configure things alone, changes get made without testing. When the technical owner decides process questions alone, the tool drifts from what the business needs. You want both, talking regularly.

Write it down, including the backups

Ownership that lives in people’s heads evaporates with the first reorganisation. Put it in writing, somewhere visible inside or next to the tool:

• Business owner, plus a named backup
• Technical owner, plus a named backup
• Who can approve changes
• Where to send requests and problems
• When ownership was last reviewed

The backups matter more than people think. Holidays, parental leave and resignations all happen. If the technical owner is away for three weeks and an automation stops working, someone else needs admin access and enough context to fix it.

Review this list at least once a year, and whenever someone on it changes job.

A backlog for requests

A backlog is simply a list of requested changes, each recorded once, so nothing lives only in an email or a hallway conversation. It doesn’t need special software. A table inside the tool itself works well, and it’s satisfying when a process tool tracks its own improvement.

Capture a few fields for each request:

• What’s being asked for, in the requester’s words
• Who asked, and when
• The problem it solves (not just the feature wanted)
• Rough effort: small, medium or large
• Status: new, accepted, scheduled, done or declined
• The decision and reason, if declined

The “problem it solves” field does a lot of work. Requests for “a new column for customer region” often turn out to be “I need to report refunds by region,” which might already be possible with a filter.

Treat this like the request queue from “Project Intake: Turning ‘Can You Just…’ Requests Into a Managed Queue”: one front door, visible priorities, and honest answers.

A light routine that keeps it alive

You don’t need a steering committee. You need a small, regular rhythm.

Monthly, 30 minutes: business and technical owners review the backlog. Accept, schedule or decline new requests. Check anything broken. Look at one data quality signal, such as records stuck in a state for too long.

Quarterly, an hour: look at the bigger picture. Are people using it? Are there workarounds creeping back? Is anything unused that could be removed? Share a short summary with users so they see requests being handled.

Ongoing: the technical owner keeps a simple change log of what changed, when and why. That pays off the first time someone asks “when did this start working differently?”

Budget time for this explicitly. If the technical owner has zero hours a month allocated to the tool, the tool will get zero hours a month. Even two to four hours is enough for most modest systems.

Saying no is part of the job

A good business owner declines things. Not grumpily, and with reasons, but regularly. Each new field, state or automation adds a bit of weight that someone has to maintain and every user has to understand.

Useful reasons to decline or defer include: it serves one person and can be met with a personal view; it duplicates something that exists; it solves a rare case that’s cheaper to handle by hand; or it would complicate the main path for everyone. Record the reason in the backlog, so the same request doesn’t get relitigated every quarter.

Where to start this week

1. Name a business owner and a technical owner for your most important internal tool, plus a backup for each, and write it down where users can find it.
2. Create a simple backlog table and move every outstanding request you can find from inboxes and chat into it.
3. Book a recurring 30-minute monthly review between the two owners.
4. Agree a time allowance for the technical owner, even if it’s only a few hours a month.