DBASC INSIGHTS — PROCESS IMPROVEMENT
Why processes fail even when procedures exist
The procedure has been written. People have received it. The same problem happens again. Before revising the document or repeating the training, ask what prevented the process from working.
By David Bowman — Founder of DBasc and co-founder of Zebsoft
A documented procedure describes an agreed way of working. Its success depends on the conditions around it: available resources, clear decisions, reliable information and people who understand their responsibilities. When those conditions are missing, another revision may leave the underlying problem untouched.
Start with the last time it went wrong.
Choose a recent example and follow the work from its starting point to the outcome. Speak to the people involved and examine the information they had at each decision. Establish where the actual sequence departed from the intended one.
This makes the discussion specific. A statement such as “the team did not follow the procedure” becomes a set of questions about what happened, what was possible and why a particular decision made sense to the person making it.
Four useful opening questions
What was the person expected to achieve?
What information and resources were available?
What prevented the agreed approach being followed?
When did the problem first become visible to someone able to act?
1. The requirement cannot be delivered with the resources available.
A procedure might require a manager to approve every order before release. If that manager is regularly unavailable and no authorised alternative exists, the process creates a predictable choice between delay and bypassing the control.
The same issue arises when checks take longer than the available time, equipment is shared without planning or a task requires skills that are unavailable on a particular shift. The instruction may be clear while the delivery conditions make compliance difficult.
Check capacity when defining the process. Establish who will do the work, how long it takes and what happens during absence or peak demand. Where resources are insufficient, management needs to change the capacity, the commitment or the process.
2. Responsibility becomes unclear at the handover.
Each department may understand its own task while holding a different view of when responsibility transfers. One team considers an email to be a completed handover. The receiving team is waiting for an approved specification before accepting the work.
Both teams can believe they have acted correctly while the job remains unattended. A procedure that simply says “pass to operations” leaves important decisions unresolved.
Define what a complete handover contains, who accepts it and how missing information is addressed. Give someone responsibility for resolving the exception so the work does not sit between departments.
3. People receive the procedure without understanding the decision.
Sending a document or collecting an acknowledgement establishes that a communication step occurred. Further checks may be needed to establish whether someone understands how the requirement applies to their work.
Terms such as “where appropriate”, “promptly” and “refer significant issues” rely on judgement. Unless the boundaries are explained, different people may apply different thresholds while believing they are following the instruction.
Use a realistic example. Ask the person to explain what they would do, which information they would use and when they would seek help. Their explanation can reveal ambiguity that a read-and-acknowledge record will not resolve.
4. Daily priorities pull people away from the agreed method.
A written requirement to complete a check can conflict with a repeated instruction to release work immediately. People notice which outcomes receive attention and which delays attract criticism. Those signals influence how the process operates under pressure.
Management needs to resolve competing expectations. Clarify which controls are mandatory, who can authorise a departure and how urgent work should be handled. An exception route should make the decision visible and preserve accountability.
5. Completion is recorded, but effectiveness is never checked.
A completed checklist, closed action or revised document provides evidence of an activity. Management also needs to understand whether that activity achieved the intended result.
If the purpose of a new order review is to prevent incomplete jobs reaching production, examine subsequent jobs for missing information and avoidable clarification. That provides a more useful test than counting how many review forms were completed.
Agree the effectiveness check when planning the change. Define what improvement should be visible, who will examine the evidence and when enough work will have passed through the process to make the review meaningful.
ILLUSTRATIVE EXAMPLE
The order was handed over. Production still could not start.
Imagine a business where sales must provide a completed order pack before production begins. Orders repeatedly arrive with details missing. Management responds by revising the procedure and asking sales to read it again.
What a closer review might reveal
Some technical details require input from operations, but the process assigns the whole pack to sales. Delivery dates are promised before that input is available. Nobody has clear authority to hold an incomplete order or resolve the resulting conflict.
The documented instruction does not resolve the dependency between the teams or the pressure created by the customer commitment.
What a practical response could include
Agree the technical review point before a delivery commitment is made. Define the information required for acceptance, name the owner of unresolved queries and establish who can approve an exception.
Review a sample of subsequent orders to check whether production receives usable information and whether the revised approach fits the available capacity.
This is an illustrative scenario, not a reported client result.
APPLY DEFINE, COMMUNICATE, ASSURE
Use the failure to examine the whole process.
Define
Specify the required outcome, ownership, inputs and decision points. Test whether the work can be delivered with the available people, time, skills and resources. Resolve conflicting requirements.
Communicate
Work through the process with those who use it. Check their understanding of handovers, exceptions and escalation. Make the current information accessible at the point where it is needed.
Assure
Examine real examples of delivery. Look at results, departures and recurring difficulties. Give findings an owner and check that corrective action addresses the cause of the problem.
A practical first step for your management team.
Choose one recurring problem and trace a recent example with the people involved. Compare the intended process with the actual sequence, including waiting time, missing information and informal decisions.
Agree one change that addresses an evidenced cause. Assign an owner, provide the necessary resources and set a point to review the outcome. Update the procedure to reflect the agreed working arrangement and check that people understand it.
That exercise gives management a concrete basis for improvement and a way to judge whether the change has helped.
Where technology can help.
Once the process is defined, technology can support controlled information, assigned actions and visibility of outstanding work. The requirements for a platform should follow from the decisions and controls the organisation needs to maintain.
As co-founder of Zebsoft, I consider that connection between management thinking and daily control central to useful software. Before configuring a workflow, establish who owns it, what each stage requires and what should happen when the normal sequence cannot continue.