26.1 Continuous Procurement Process Improvement

Define the problem before selecting a solution

Continuous process improvement examines how procurement work actually flows and changes it to produce better public results. A slow purchase order may be caused by incomplete requisitions, duplicate approvals, unclear specifications, supplier delays, funding errors, or a system interface. Buying software before identifying the cause can automate the same problem or create a new control gap.

Write a precise problem statement with scope, affected users, period, and evidence. “Procurement is slow” is too broad. “During the last quarter, 35% of routine requisitions were returned for missing funding or scope information, adding a median four business days” identifies something measurable. Verify that the baseline uses consistent dates and excludes unlike transactions before setting a target.

Map the current process

A process map should identify the request, inputs, activities, decisions, handoffs, queues, outputs, roles, and controls. Follow actual cases instead of assuming the policy describes daily behavior perfectly. Record rework loops and waiting time as well as active processing. A ten-minute review can sit in a queue for a week; shortening the review to five minutes may barely change total cycle time.

Distinguish work that produces value, work required for a necessary control, and avoidable duplication or correction. A supplier identity check may be essential even though it does not change the purchased product. Improvement should make the control effective and proportionate, not delete it solely because it takes time. Consult the people who perform and receive each handoff.

Investigate causes rather than symptoms

Root-cause analysis asks why an observed failure occurs. A “five whys” discussion can trace repeated returns to a missing form definition or ambiguous ownership. A cause-and-effect diagram can group people, process, system, policy, data, and supplier causes. These are investigation tools, not proof by themselves. Test hypotheses against records and stakeholder evidence.

Avoid blaming an individual before examining the process. If multiple trained employees make the same mistake, the instructions, interface, workload, or incentives may be contributing. Conversely, a documented intentional control violation needs an authorized response even if the workflow could also improve. Process redesign and accountability are related but distinct tasks.

Use a controlled improvement cycle

A plan–do–check–act cycle provides a practical structure. Plan the proposed change, intended result, measures, risks, approvals, and trial boundaries. Do a limited authorized trial with training and support. Check measured results against the baseline, including errors and control exceptions. Act by adopting, adjusting, or abandoning the change and recording the decision.

A trial should not bypass procurement law or contract authority. If a new catalog or form changes an official approval process, obtain the required approval before use. Define a rollback path and preserve the original records. A short trial with reliable evidence is more useful than an immediate agency-wide rollout justified only by enthusiastic feedback.

Balance measures and avoid gaming

Cycle time matters, but a faster process that produces more incorrect orders or unauthorized payments is not necessarily better. Use a balanced set: elapsed time, staff effort, first-pass completeness, error rate, control exceptions, user experience, supplier access, and actual cost. Define each measure and owner before the trial.

Distinguish process capacity from cash savings. If automation releases 100 staff hours but payroll does not fall, report available capacity or time redeployed, not an automatic cash saving. Also account for implementation, subscription, training, support, exception handling, and audit effort. Do not count the same released time as both full labor savings and additional output without explaining the method.

Worked improvement example

A buyer maps routine requisitions and finds that 40 of 100 monthly requests are returned once for missing scope details. An approved revised form supplies examples and requires the requester to identify the deliverable, quantity, funding code, and needed date. During a two-month trial, returns fall to 15 per 100 requests while median cycle time falls from nine to six business days.

The return rate decreases by 25 percentage points, or 62.5% relative to its 40% baseline. Cycle time decreases by three days, or 33.3% relative to nine days. These are different measures with different denominators. Verify comparable request complexity and check whether users simply moved unresolved questions into later change orders before declaring success.

Sustain the result

Assign an owner for the revised form, document the approved process, train affected staff, retire obsolete versions, and update job aids. Continue sampling for errors and unintended barriers. A new mandatory field may improve clarity for ordinary purchases while confusing specialized service requests; provide a controlled way to handle legitimate differences.

Use lessons from complaints, audits, supplier feedback, and after-action reviews to choose the next problem. Continuous improvement is a repeated evidence-based discipline, not a promise that every change must lower price or that a particular technology is automatically an improvement.