Getting started
Who should own this internally
The person who makes it work is not the most technical: it is whoever suffers the problem today.
It is the least considered decision and the one that most determines whether this sticks or gets abandoned. It usually gets settled by elimination — "let IT handle it", "let whoever has time handle it" — and both outcomes fail for the same reason: whoever owns it is not whoever has the problem.
The three usual profiles
| Profile | What they bring | Why it fails if they are the only one |
|---|---|---|
| Whoever suffers the problem | Knows what has to happen and notices when it works | May lack backing for decisions that affect everyone |
| IT | Solves access, domain, integrations | Does not know what documentation you require or why, and should not decide it |
| Management | Unblocks decisions and budget | Alone, nobody uses it day to day |
Important
The combination that works is the first with occasional support from the other two: **the owner is whoever chases documents today**, IT steps in for domain or access work, and management appears to decide what crosses departments. Making IT the owner is the commonest and costliest mistake: they end up administering a tool whose purpose they do not live.
What the owner must be able to do
The third is most underestimated. As soon as something starts working, requests arrive from other departments, and an owner who cannot say "that comes later" ends up with five half-built processes instead of one finished.
The mistake of sharing it out
Watch out
Two people "owning it together" without one being responsible is the most reliable formula for nobody owning it: each assumes the other reviews what is pending, and neither decides when a decision is needed. One is responsible and the others help — and that is said out loud on day one, not inferred.
How much time it really takes
- 1
The first two weeks: a few hours
Building the process, testing it, correcting it. That is when it is most needed.
- 2
The first quarter: a while each week
Checking what is stuck, tuning alerts, answering the team's questions.
- 3
Afterwards: half an hour a month
The tidy-up and the access review. If it needs much more, something is built more elaborately than necessary.
Worth knowing
If that person leaves or changes role, the handover is explicit: who picks up the owner's role, by name. An owner who disappears with no successor is the commonest reason a rollout that was going well fades within three months.
›What if we are too few to name anyone?
Then the owner is whoever chases documents most, even if that is the manager.
›Can an external adviser own it?
They can operate it, but the decision owner has to be inside.
›Does it have to be someone technical?
No. The technical part is small and occasional.
A real case
The situation
A company hands the rollout to IT and two months later nobody uses it.
What you do
- Names the person who chased documentation as owner
- Keeps IT for domain and access work
What you get
The process adapts to what actually happens and usage rises with no extra training.
The situation
The named owner has no time allocated for it.
What you do
- Reserves fixed hours each week during the rollout
What you get
The project stops competing with the day's urgencies.
The situation
Someone is named who cannot decide how the work is done.
What you do
- Picks someone who can change the procedure, not only run it
What you get
Adjustments are applied without asking permission each time.
The situation
The owner leaves and nobody knows how it was set up.
What you do
- Documents decisions inside the process itself
- Keeps a second person with access from the start
What you get
One person leaving does not freeze usage.
The situation
IT builds the process and whoever uses it does not recognise their work in it.
What you do
- Has it designed by whoever chases the documentation today
What you get
The process resembles the real work from the first version.
The situation
Nobody knows who to ask when something does not fit.
What you do
- Announces who the owner is and how to reach them
What you get
Questions reach somebody instead of becoming excuses.
This article answers
- who should own the platform internally
- internal rollout owner
- should it be IT or the department
- who administers the tool