Use cases by capability
Inheriting what somebody else built
You take over a role and inherit processes, cases and criteria you never wrote.
Someone left and this is yours now. One temptation is to rebuild it your way; the other is to touch nothing out of fear. Both are expensive. What works is a short, ordered walkthrough before deciding what to change.
The walkthrough, in one afternoon
- 1
See what is alive
How many cases moved last month. What has not moved in six months is probably unused.
- 2
See who signs in
The log shows who actually uses this. Sometimes it is two people, and not the ones you were told.
- 3
Open the most-used processes
Read them as the supplier who receives them. That is where you see why people deliver or not.
- 4
Look for what expires
It is what can blow up unannounced if nobody was watching.
What to touch, in what order
| Finding | Urgency | What to do |
|---|---|---|
| Expired documents and nobody warned | High | Fix it this week |
| Accounts and accesses of people who left | High | Close them |
| Processes with titles nobody understands | Medium | Rewrite them; it lifts delivery and breaks nothing |
| A folder structure you dislike | Low | Leave it. Changing it disorients people who had found their way |
Important
Do not close or delete cases you do not yet understand. One may be open for a reason you cannot see — a claim, a stalled site — and closing it with the wrong reason leaves a record you will have to explain later.
Watch out
If whoever built it is still reachable, half an hour with them saves two weeks. What is written nowhere is why each thing was decided, and only they have it.
Worth knowing
Change one thing at a time and let two weeks pass. If you change five and something worsens, you will not know which.
›Can I see who configured each thing?
The log shows who made each change and when.
›What if a process is clearly wrong?
Change it, but for future cases: running ones are corrected individually.
›Is it worth rebuilding entirely?
Almost never. What works, however ugly, is worth more than something elegant and untested.
A real case
The situation
Someone inherits a company's document management when the manager leaves.
What you do
- Spends an afternoon on the walkthrough
- Closes four accesses and fixes nine unwarned expiries
- Leaves the folder structure alone
What you get
Within a week they have the urgent things under control without breaking anything people already knew how to use.
The situation
You inherit a process built by somebody who has left and nobody knows why it asks for what it asks.
What you do
- Goes through the list with whoever uses it today
- Removes what nobody looks at and notes why the rest stays
What you get
The process is understood and can be improved rather than touched fearfully.
The situation
The inherited process has ten phases and nobody remembers the reason.
What you do
- Checks which phases genuinely add something
What you get
The process shortens without losing anything.
The situation
Something is changed and it breaks a case nobody knew about.
What you do
- Tests the change on a real case before applying it
What you get
The improvement does not break what worked.
The situation
There are four similar inherited templates.
What you do
- Unifies and archives the ones not being launched
What you get
The list becomes readable again.
The situation
Nobody knows which files use each template.
What you do
- Checks which ones are still active
What you get
You touch what is in use rather than what is dormant.
This article answers
- i inherited document management from someone else
- taking over a colleague's processes
- understanding a system i did not build
- reviewing configuration someone else left