Enhance team productivity by mastering workflow management and improving project efficiency with effective collaboration tools and task prioritisation.
Productivity conversations in most businesses default to effort. People should be more focused, meetings should be shorter, everyone should try harder. That framing is comfortable because it requires nothing structural, and it produces very little.
The larger constraint is almost always the work itself. How it arrives, how it moves between people, how many times it stops, and how much of it is somebody doing something a system could do. Those are design problems rather than effort problems, and they are considerably more tractable.
This article covers where the time actually goes and what changes it.
If you measured a piece of work from when it arrived to when it was finished, most of that elapsed time would be waiting rather than working.
Waiting for an approval. Waiting for information from somebody else. Waiting for a batch process to run. Waiting for somebody to be available. Waiting in a queue behind other work.
People experience this as being busy, because they are working on something else during the wait. The organisation experiences it as things taking a long time.
That distinction matters because it points the improvement in a different direction. Making people faster at the working portion barely moves the total. Removing a wait does.
The practical implication is to measure elapsed time rather than effort time, since the gap between the two is where the opportunity sits.
Every time work passes between people it stops, and each stop costs more than the transfer itself.
The receiving person has to understand the context, which the sending person had and did not fully transfer. That reconstruction is genuine work and it happens at every handoff.
There is also a queue at each stop, since the receiving person is doing something else and this joins a list.
And each handoff is a place where things go missing, because responsibility is ambiguous during the transfer.
Mapping a process and counting the handoffs is a short exercise that reliably surprises people. Processes that feel simple frequently have six or seven, and several of them exist for historical reasons rather than because anybody needs to be involved.
Approval steps deserve specific attention because they are the most common wait and the most frequently unnecessary.
Every approval was added for a reason, and the reasons decay. Somebody made a mistake once, a control was added, the circumstances changed, the control remained.
The useful test for each approval is what proportion of items are actually rejected. Where an approver rejects almost nothing, they are not exercising judgement, they are adding delay.
That does not always mean the control is worthless, since a deterrent effect is real. It does mean the threshold is probably wrong, and raising it so the approval applies only to items where judgement is genuinely required removes most of the delay while keeping the control.
The other common problem is sequential approvals that could be parallel, or that could be a single approval at the right level rather than three at ascending ones.
A substantial amount of coordination effort exists because nobody can see the state of anything.
Where somebody has to ask whether an invoice was approved, where an order is, or whether a task is done, the asking and the answering are pure overhead, and they interrupt the person being asked.
Where the status is visible in a system, the question does not need to be asked. That removes both the interruption and the delay of waiting for a reply.
It also changes behaviour. Work that is visible gets done, because the queue is apparent to the person holding it and to everybody waiting.
This is one of the more reliable improvements available and it is mostly a configuration exercise rather than a process redesign.
The most mechanical and most quantifiable waste in most businesses is somebody moving information from one place to another.
An order arrives by email and somebody types it into the system. Payroll runs in one place and somebody journals it into another. Hours are written on a sheet and typed into payroll. Data is exported, manipulated in a spreadsheet and imported back.
Each instance is time, and each is an error opportunity that produces downstream work when it goes wrong.
Counting these is straightforward. Walk the main processes and note every point where somebody moves information between systems by hand, estimate the time each consumes weekly, and rank them.
That ranking is an improvement backlog with numbers attached, which is considerably more actionable than a general sense that things are inefficient.
A category of delay that is easy to miss because it looks like thinking rather than waiting.
Somebody needs to make a decision and does not have what they need, so they go and find it. Open a different system, run a report, ask a colleague, check a spreadsheet.
Where the relevant information is present at the point of decision, that disappears. A credit controller who can see the customer's history, their payment behaviour and their open orders on one screen decides immediately. One who has to assemble that decides later.
This is largely a matter of how records and dashboards are configured, and it is frequently never optimised because the default configuration was adequate and nobody revisited it.
Asking people what they have to go and look up before they can act is a fast way to identify these.
The most useful reframing available is to design processes so that routine work flows and only exceptions need attention.
Most processes treat every item identically, which means human judgement is applied to the ninety per cent that did not need it and is therefore rushed on the ten per cent that did.
Where the routine passes automatically and only exceptions are surfaced, attention concentrates where it is worth something.
Invoice matching is the clearest example. Where an invoice matches the order and the receipt within tolerance, nothing needs a human. Where it does not, somebody investigates, and they have time to do it properly because they are not also processing the matched ones.
The prerequisite is defining what routine means, which is a business decision about tolerance rather than a technical one.
Batching work feels efficient and frequently increases elapsed time substantially.
Processing invoices once a week is efficient for the processor, since they are in the right frame of mind and the setup cost is paid once. It also means an invoice arriving the day after the batch waits six days before anything happens.
Where the batch is the constraint on the whole downstream process, that wait propagates.
The judgement is whether the setup cost is genuinely significant. Where automation has removed most of it, batching is preserving an efficiency that no longer exists, and processing continuously is both faster and no more effortful.
Reviewing what is batched and why is worth doing periodically, because batches tend to persist long after their justification.
Worth naming because it is genuinely large and is frequently caused by process design rather than by culture.
Where people have to ask each other for status, for approvals, for information the system does not surface, every one of those is an interruption to somebody doing something else.
Interruptions cost more than their duration, since resuming concentrated work takes time.
Most of these are removable by making information visible and by routing requests through a system rather than through a person. That is not about discouraging communication, it is about not requiring communication for things a system can answer.
The measure worth watching is how often people are asked questions the system could have answered, which is usually higher than anybody expects.
The diagnostic is a short exercise and it points the effort accurately.
Pick your two most important processes, meaning the ones that touch customers or cash. Quote to cash and purchase to pay are the usual candidates.
Map each end to end, with every step, every handoff, every approval and every system.
For each step, note the effort time and the elapsed time. The difference is waiting.
Then identify the three largest waits, the handoffs that add no value, and every point of manual transcription.
That produces a specific list ordered by size, which is what makes improvement happen rather than being discussed.
The sequencing principle that determines whether an automation programme delivers.
Automation encodes whatever process it is applied to. A process with unnecessary steps and unclear ownership becomes a faster version of itself with the problems baked in and harder to see.
It also becomes harder to change afterwards, since modifying it is now a configuration exercise rather than a conversation.
The order that works is to remove the steps that should not exist, clarify who owns what, then automate what remains.
Most processes lose steps under that examination, and the automation that follows is simpler and cheaper than it would have been.
Beyond process design, some productivity problems are structural and no amount of process improvement reaches them.
Where information lives in several systems that do not talk, every question spanning them requires manual assembly, and that is a systems problem rather than a workflow one.
Where the same information is entered more than once as a matter of routine, the same applies.
Where nobody can answer a question about profitability by product, project or customer without an exercise, the constraint is the data structure.
Distinguishing these from process problems matters, because effort applied to the wrong one produces very little. Our piece on the hidden costs of outdated systems covers how to make that assessment.
The practical point that determines whether improvements stick.
The people performing a process know where it is awkward, which steps are pointless and what they work around. That knowledge is not written down and it is not visible to anybody designing from outside.
Asking them produces both better improvements and better adoption, since a change somebody suggested is one they will use.
The question that works is not whether the process could be better, which gets a general answer. It is what part of this annoys you most and what do you do to get around it.
That second half is the valuable one, because a workaround is a precise description of a design failure.
Productivity measures frequently drive the wrong behaviour, so it is worth choosing carefully.
Elapsed time from arrival to completion, since that is what the customer or the downstream process experiences.
The proportion of items passing without human intervention, which indicates how well exception based design is working.
The number of manual transcription points, since removing those is where the mechanical gains are.
And the time people spend answering questions the system could answer, which is the coordination overhead.
What to avoid is measuring individual output volume, which drives people to prioritise easy items and to avoid the difficult ones that actually needed attention.
Productivity improvement in most businesses is available through process design rather than through effort, and the largest single component is waiting rather than working.
The useful first step is mapping one important process end to end and separating effort time from elapsed time, because the gap between them is the opportunity and it is usually larger than anybody expects.
Our piece on where automation genuinely helps covers what can and cannot be automated, and managed services covers the ongoing capability to actually make the changes once they are identified.
If work in your business takes longer than it should and you are not sure where the time goes, get in touch.
