Procurement leaders need to understand the work their teams are carrying, without turning every practitioner into a full-time reporting assistant. That is the problem explored in the WOP archive conversation with Acada founder Rich Sains. The original episode description focuses on reducing administration, making work visible and designing an interface people can use.
This companion develops those themes into a practical workload model. The interview is an archive record. Product descriptions and guest roles belong to the time of recording, and this article makes no claim about Acada's current capabilities or commercial offering.
Why a project count gives an incomplete picture.
Ten open projects can mean ten straightforward renewals or ten difficult sourcing decisions with several operational dependencies. Counting them equally hides complexity. Counting only completed projects can encourage people to prioritise easy closures while important work remains stuck.
Start by describing the work in a way that supports allocation. Record the business need, category or supplier, business owner, procurement owner, current stage, next decision and blocker. Include the date by which an outcome is needed. A tracker that says “in progress” everywhere offers very little help with the next week.
Add context to the most demanding cases. An implementation dependency, unclear specification or unresolved stakeholder decision can explain why a project requires more attention than its spend would suggest. Spend is relevant, but it is a weak substitute for effort, complexity and business consequence.
Capture information where work already happens.
The episode description highlights a useful design principle: visibility should not depend on repeatedly entering the same information. Map where the team already creates a request, records a decision or updates a supplier interaction. Those events can support a progress record if the data is reliable and the team knows what it means.
Keep the first model small. A project identifier, owner, stage, next action, due date and blocker can be enough to run a useful weekly review. Add fields when they improve a specific decision. Collecting information because a dashboard can display it is a poor reason to impose another administrative task.
Define stage changes carefully. “Contracting” might mean waiting for a first draft, negotiating a disputed term or waiting for signature. A leader needs the blocker and the decision owner to tell the difference. The system should make it easy to record that distinction.
Separate active work from elapsed time.
An RFP can take several months without requiring several months of continuous procurement effort. Record elapsed duration and active effort separately where possible. Include waiting time for business decisions, supplier responses and specialist reviews. That gives you a way to improve handovers instead of assuming every slow project needs a faster buyer.
Use estimates honestly. If the team does not record detailed time, begin with effort bands and explain their limitations. Revisit them after completed work. You can learn that a recurring category needs more preparation without inventing a precise productivity figure from incomplete records.
A weekly review that changes allocation.
Ask each owner to identify the next decision and what prevents it. Look for work waiting on the same specialist or stakeholder. Resolve priorities where two urgent projects compete for the same person. Escalate a missing decision with enough context for the decision-maker to act.
Keep the meeting focused on exceptions. Routine work can be visible in the record without receiving a lengthy verbal update. A useful review should end with changed priorities, resolved blockers or agreed actions. If none of those occurs, reconsider the information the meeting is collecting.
A worked example: the renewal queue.
Imagine eight renewals arrive at once. Three need a routine commercial check, two involve changed requirements, one needs a replacement search and two have no confirmed business owner. A count of eight offers no allocation guidance. A record of the next decision makes the problem clear.
The leader can assign the routine checks, schedule discovery for changed scope, start the replacement assessment and ask the relevant executive to name the missing owners. The system has created value by enabling those decisions. Its benefit is not the existence of a colourful portfolio chart.
Avoid turning visibility into surveillance.
Explain why information is collected and how it will be used. People need to trust that a blocker record will help solve the blocker. If every delay is interpreted as an individual failure, the tracker will become less accurate precisely when leadership most needs the truth.
Review outcomes alongside context. Compare similar types of work and account for dependencies before drawing conclusions about performance. The purpose of workload visibility is to improve service and allocation. It should also reveal where the operating model asks people to carry more work than the available capacity can support.
What to test before buying a tool.
Run the model on a small portfolio. Check whether the information stays current, whether updating it is manageable and whether a leader can use it to make a better allocation decision. Then ask a vendor to demonstrate that same work with your routine and exception cases.
The Acada conversation is a useful starting point because it brings user experience into a discussion often dominated by reporting features. The enduring test is simple: can practitioners keep the record accurate while doing the job, and can leaders act on what the record reveals?