Procurement Team Calculator: A First Step Towards the Procurement Control Tower
The number of sourcing events assigned to a buyer tells us surprisingly little about their workload. Several RFQs may require less attention than one complex RFP. A project awaiting business approval stays open, while another may require intensive work on specifications, bidder clarifications, or negotiations.
Yet we still need to allocate workloads, commit to completion dates, and justify the team’s headcount. Without a consistent capacity model, those decisions depend heavily on the manager’s judgment (or simply the gut feeling) and the team’s preparedness to absorb additional work.
I see procurement capacity planning as one component of a wider Procurement Control Tower. Its purpose is to connect incoming tasks and existing commitments with the resources needed to deliver them. We can start developing that component even before reliable operational data is available.
The Procurement Control Tower vision
This concept brings together the records procurement already needs and runs, even if they sit in separate spreadsheets or trackers.
A master staff roster would identify each person’s role, experience, and category responsibilities.
Leave and other planned absences would establish their availability.
A workload catalog would define the effort associated with different activities.
A project register would show assigned work, current stages, and expected remaining effort.
That combination would let management examine capacity by person, skill set, and category. It could also support a forward view of commitments, including work that has been planned but has not yet reached procurement.
Additional headcount may be reasonably justified where demand persistently exceeds available effort.
A shortage of category expertise may require a different staffing decision from a simple staff augmentation.
The control tower should help distinguish these situations and show the consequences of proposed interventions.
Procurement workload needs a defensible calculation
The distinction between elapsed cycle time and active procurement effort is fundamental.
An RFP can remain open while suppliers prepare their offers or stakeholders evaluate technical proposals. The procurement owner still needs to coordinate and follow up, but you can't treat the full elapsed duration as dedicated labor demand.
Buyers can therefore manage several events in parallel. The difficulty arises when activities requiring their attention coincide. Annual capacity may appear sufficient, but a particular month may become unmanageable.
Work outside formal sourcing events also needs recognition. Reporting, stakeholder support, committee preparation, contract queries, and regular staff meetings consume time. We can estimate these activities separately, and we will.
The workload model should make these choices visible. Otherwise, a utilization percentage can conceal more than it explains.
Starting with assumptions
We do not need an integrated project tracker or historical activity records to explore how such a model would work. We need initial estimates of demand, effort, staffing, and availability.
Those estimates allow us to test alternatives. We can examine how staffing requirements change as request volumes increase, procedures require more effort, or recruitment and onboarding reduce available capacity.
Starting without operational data means relying on explicit, basic assumptions. It doesn't allow us to establish the organization’s actual staffing requirement. The initial result is a scenario to investigate and calibrate.
The Procurement Team Calculator
I developed the Procurement Team Calculator as a first step in this direction.
It explores the relationship between staffing, salary cost, and procurement service levels across five procedures: Open RFP, Closed RFP, Single-source, RFQ, and Contract extension. Users can adjust volumes, completion targets, effort, and waiting times, then compare different staffing options.
The model also considers availability and disruption, including leave, sickness, turnover, recruitment, and reduced productivity during onboarding. Monte Carlo simulation explores variations in workload and staffing availability and estimates the share of simulated requests completed within the specified service targets.
The illustrative inputs let users explore these relationships before assembling their own records.
Developing the operational version
The next stage towards the Procurement Control Tower would be to connect actual records progressively:
A project register could supply assignments and stages.
The staff roster and leave calendar could update availability.
Completed events could help calibrate effort estimates and distinguish procurement work from time spent waiting.
Company-specific cycle times for all appropriate sourcing event types will add precision to our current generic assumptions.
Staff skill sets and sourcing event complexity can add additional dimensions to the analysis (not every team member can run a complex, category-specific RFP).
I would begin with a limited set of procedures and compare the model’s expectations with observed delivery. Investigate differences: the effort estimate may be wrong, an assignment may be unusually complex, or an approval delay may be driving the result.
That comparison would also test whether maintaining the records produces enough management value to justify the administration. A field should earn its place by improving a forecast, explaining a constraint, or supporting an allocation decision.
Our calculator gives us a practical place to begin that discussion. We can test the assumptions, identify the inputs that materially affect the result, and use those findings to define the first operational data requirements.
Comments