Imagine a company where approving a request takes several days. To shorten that, the tech team is asked to improve the form: fewer fields, pre-filled data, a simpler interface.
The form gets better. The request is still waiting.
Why? Because only one person can approve it, and they go through their pending items once a week.
It’s a hypothetical example, but it shows a very specific management mistake: changing one activity without understanding what limits the outcome you want to improve.
#.First, understand the work
Being able to automate something doesn’t justify doing it. First you need to know what goal it serves, what problem it has, and what benefit you expect.
I’d start by talking to the people who do the work and watching how they get it done:
- Where do they wait?
- What information is missing?
- Which decisions depend on someone else?
- How many times do they have to send a request back?
That helps separate symptoms from possible causes. Then I’d check it against data: wait times, backlog, errors, and available capacity.
A queue tells you where to look. On its own, it doesn’t tell you the cause.
And the longest task isn’t always the bottleneck. If we’re talking about how much work gets done, what matters is capacity compared to demand. If we’re talking about how long each request waits, how often it gets reviewed matters too. Someone who approves once a week can have plenty of spare time and still add days to every answer.
It’s worth measuring the time from when a request arrives until it gets an answer, and splitting how much of that is waiting and how much is work.
With that in hand, here’s a simple first test. If each review clears whatever came in, and most of the wait happens between one review and the next, I’d try reviewing more often. If, over several weeks, more requests come in than go out, I’d look into what’s holding back the outflow: the approver’s available time, missing information, or requests that bounce back because they arrived incomplete.
It’s a lead, not a diagnosis. Depending on what turns up, the answer might be setting aside more time for approvals, delegating, changing the criteria, or reducing how much arrives incomplete.
#.What Toyota asks before bringing in a machine
Lean comes from the Toyota Production System. The way I read it, it means looking at how value is delivered and reducing waste along the whole flow. Speeding up one activity can still leave someone waiting just as long for the result.
The Toyota Production System has two pillars:
- Just-in-Time: make what’s needed, when it’s needed, in the amount needed. It doesn’t mean waiting until the last minute; it requires coordinating the stages.
- Jidoka (automation with a human touch): detect abnormalities and stop the work so defects don’t keep moving forward.
Explaining jidoka, Toyota says that rather than starting with a machine, you must first do the work by hand, smoothly and correctly. Improve it, remove the waste, and make it possible for anyone to do it. Only then does the machine take over that work, with abnormality detection built in.
Toyota is talking about machines, not software. And the analogy has a limit: if we can try a small, low-risk automation whose effects can be undone, it may be exactly what gives us the data to understand the flow. The difference is knowing what we want to learn from it.
That said, reverting the code doesn’t revert what the automation already did. If it approved requests, sent information, or changed data, that stays.
Carried over to our form, the analogy says: first understand which requests arrive incomplete, and why. Then automate their handoff to the next department.
An integration can pass information along perfectly. That doesn’t tell you it’s the information that was needed.
#.Kanban: deciding when more work comes in
The Kanban Guide asks you to define and visualize the workflow, actively manage the items in progress, and improve how they flow. It also requires explicitly controlling how much work is in progress, the famous WIP.
That’s why filling a board with cards is just the beginning. You still need to decide what comes in, when, and under what conditions.
Back to the approvals. If we keep starting requests while the earlier ones are waiting for approval, we can pile up open work without resolving any more of it.
Limiting WIP doesn’t give the approver more time. It can keep us from starting work we can’t finish yet. But on its own it doesn’t change how often approvals happen either: pending requests can just sit and wait before they ever reach the board.
That’s why it matters to measure from when the request arrives, not from when we start working on it.
What we do next depends on what we find in the inbox. A tool can help carry it out, but it won’t choose it for us. Those are management decisions.
#.Not every process deserves the same investment
Lean and Kanban help you look at the flow. But you also have to decide which outcomes to prioritize, which risks to accept, and where to invest.
COBIT 2019, for example, proposes tailoring the governance of information and technology to each organization’s context. And an ISACA article proposes going further: setting the target capability level process by process, since not all of them are equally critical.
My practical reading: raising every process to the same level makes no sense if their consequences are different.
A data recovery process may deserve investment even if it’s almost never used. A daily task may work well enough, and perfecting it adds little.
Frequency, speed, and how easy something is to automate are inputs for the decision. None of them replaces understanding the value, the risk, and the cost of the change.
Investigating has a cost too. I wouldn’t ask for the same analysis to simplify an optional field as to change who can approve a request. What I would ask for in both cases is being clear about what we want to improve and how we’ll check it.
#.Improve, then look again
In the example, I’d try one small change aimed at the approval wait, one we can roll back if it doesn’t work. If the wait depends on several things at once (who approves, with what criteria, and how often they review), a single change may not move the timeline, and that’s a result too.
Then I’d follow the requests:
- Are they resolved sooner?
- Did errors go up?
- Did the load land on another team?
The form may deserve improvements too: fewer errors, less effort, better accessibility. That’s worth doing on its own. But if what we want is to answer sooner, I want to understand where the days go for whoever is waiting for the answer.