Procurement And Legal Review As Constraints

Almost every initiative of consequence in a large organisation passes through procurement and legal review, and almost no organisation measures how long either takes. The two functions sit on the critical path of new suppliers, new partnerships, new products, new markets, renewals, data sharing, hiring of contractors and anything involving money leaving the building. They are, in the strict Theory of Constraints sense, frequently the binding constraint on the enterprise's rate of change — and they are usually managed as cost centres whose performance is judged by spend saved and risk avoided, neither of which has any relationship to throughput.

The consequence is a peculiar organisational blindness. A business unit can spend six months building a case for a partnership, secure executive approval in a single meeting, and then wait eleven weeks for a contract. Nobody records those eleven weeks against the initiative. They appear in no dashboard, no programme report and no retrospective, because the clock that everyone watches stopped at the approval and did not restart until signature.

If you are a chief operating officer wondering why strategic intent converts so slowly into operational reality, this is one of the first places to look. It is also one of the more delicate, because the people in these queues are doing necessary work, are usually overloaded, and have heard "you are the bottleneck" often enough to have stopped listening.

Why adding lawyers and buyers rarely helps

The instinct when a queue is long is to add servers. In these two functions it works less well than almost anywhere else, for four reasons that compound.

The work is not homogeneous and cannot be pooled freely. A commercial contract, a data processing agreement, an employment matter and a regulatory question are not interchangeable work items served by interchangeable people. Adding a generalist to a queue whose backlog is specialist adds capacity to the wrong server. Queueing theory is explicit about this: pooled servers dramatically outperform dedicated ones, but only where the work can genuinely be served by any of them.

Onboarding consumes the constraint. The people capable of bringing a new lawyer or category manager up to speed on your commercial context are exactly the senior people who are currently the bottleneck. New capacity is negative capacity for a period, and the period is long in functions where judgement is the product.

More capacity attracts more demand. When legal review becomes faster, business units stop routing around it and start using it, which is mostly good and entirely predictable. Demand in these functions is elastic and largely invisible until it is served, so capacity increases are partly absorbed by demand that was previously suppressed.

The largest component is not processing time anyway. Measure a contract from request to signature and split the intervals. The lawyer's actual review typically accounts for a small fraction. The rest is waiting for the counterparty, waiting for the business owner to answer a question, waiting for a second internal reviewer, waiting for a security or data assessment to run in parallel that is in fact running in series, and waiting in queue before anyone opened it. Adding lawyers shortens the small term.

Differentiate the path before you optimise it

The single highest-value change available in both functions is to stop running one process for everything.

Most legal and procurement processes were designed around their highest-risk case and then applied uniformly, which means a routine renewal of a small software subscription travels the same path as a multi-year outsourcing agreement. The routine items are numerous and the complex ones are few, so the majority of the queue consists of work that does not need the process it is receiving — and, worse, that work is what makes the queue long enough to delay the genuinely complex items that do need careful attention.

Risk tiering fixes this, and it is best done with the risk function rather than around it.

Define tiers on observable criteria, agreed in advance. Contract value, data sensitivity, term length, termination rights, whether the counterparty's paper or yours is used, regulatory exposure, whether the arrangement is precedented. The criteria must be checkable by a non-lawyer from the request itself, or the triage step becomes its own queue.

Give each tier a genuinely different path, not a different priority. Priority reorders a queue; a different path removes items from it. The lowest tier should complete without a lawyer touching it at all.

Publish what each tier gets and how long it takes. Predictability is worth more to a business unit than speed. A reliable three weeks is more useful than an unpredictable one-to-eight, because a reliable number can be planned around.

Tier	Typical characteristics	Path	What the business gets
Standard	Pre-approved template, unmodified, below value threshold	Self-service, no review	Same day
Light	Template with pre-agreed fallback positions only	Checklist review by a trained non-lawyer	A few days
Full	Counterparty paper, novel terms, material value	Full review, named owner	A published percentile commitment
Exceptional	Novel risk, regulatory novelty, strategic significance	Senior review plus formal escalation	Scheduled, not queued

The tiering exercise is also a diagnostic. Categorise a quarter's worth of completed requests into the tiers you have just defined. If most of the volume falls into the bottom two, you have quantified how much of your constraint's capacity is being spent on work that did not require it.

Templates and self-service are work in progress reduction

A pre-approved template with pre-agreed fallback positions is not a document. It is a decision made once, in advance, at leisure, and then reused — which removes an item from the queue entirely rather than moving it through faster.

This is the most reliable form of constraint relief available, because it changes the arrival rate rather than the service rate. The same logic applies to a pre-approved supplier list, standard data processing terms, a catalogue of agreed commercial positions, and a set of playbook answers to the objections counterparties routinely raise.

Three conditions determine whether it works.

The fallbacks must be real. A template with a single acceptable position is a template that returns to the queue the moment a counterparty redlines anything. The value lies in the second and third positions, agreed in advance, that a non-lawyer is authorised to accept.

Authority must accompany the template. If a business owner must still ask permission to use the pre-approved fallback, you have created a document rather than a path. The decision rights need to move with the artefact, which is often the genuinely hard part organisationally rather than legally.

It must be easier than the alternative. Self-service that is harder to navigate than emailing a lawyer will be routed around, and the routing around will be invisible until it becomes an audit finding.

Service level expectations, not service level agreements

There is a strong temptation to solve the visibility problem by imposing service level agreements on legal and procurement. Resist it, and offer something better.

An SLA is a commitment made under threat of consequence, typically stated as a maximum. Applied to a function with highly variable work, unbounded arrivals and no control over intake, it produces exactly what Goodhart's Law predicts: the number improves and the system does not. Requests get returned as incomplete to reset the clock. Work is started nominally to stop the timer and then sits. The easy items are pulled forward and the hard ones age quietly. Categories are redefined. None of this is dishonesty; it is the rational response of competent people to a measure imposed on a system they do not control.

A service level expectation is a different instrument. It is an empirical statement derived from your own history, in this form: eighty-five percent of tier two contracts complete within N working days. It is falsifiable, it carries its own uncertainty, it does not require estimating the individual case, and — critically — it is a joint statement about the system rather than a promise extracted from one function. When it is missed, the question is what changed in the system, not who failed.

Publish the percentile and the median together. The gap between them measures variability, and variability is what makes these functions impossible to plan around. Reducing that gap, by tiering and templating so that most items follow a predictable path, improves the business's experience more than reducing the median does.

The reciprocal obligation matters as much. An expectation about response is only meaningful if intake is complete. Define what a well-formed request contains — counterparty, value, term, data involved, business owner, deadline and why — and let the clock start when it is complete. This is not bureaucracy; it is the removal of the largest single source of rework in both functions, which is the clarification round trip.

Measuring a function whose job is partly to say no

Here is the genuine difficulty, and it deserves to be taken seriously rather than waved away with a flow metric.

If you measure legal or procurement purely on throughput, you have created an incentive to approve things. The value these functions create includes the deals not done, the terms not accepted, the liability not assumed and the supplier not engaged — outcomes that are invisible, counterfactual and impossible to count. A pure speed measure quietly asks a control function to stop controlling.

The resolution is not to abandon flow measurement. It is to measure flow and quality as a pair, and never to report one without the other.

Measure the queue, not the judgement. Cycle time, work in progress, flow efficiency and tier distribution describe how work moves. None of them says anything about whether a decision was correct, and none should be presented as if it did.

Make refusal an outcome, not a failure. A request that is declined, restructured or withdrawn is a completed item and should be counted as one. If declining an item damages your cycle time statistics, the statistics will bias toward approval. This is the most important single point in the article.

Track the decisions, separately and qualitatively. Materially adverse terms accepted under time pressure. Exceptions granted outside policy. Suppliers engaged without completed review. These are risk measures, they belong in a risk report, and they are what should constrain any enthusiasm for speed.

Watch the routing-around rate. The clearest signal that a control function is too slow is not a complaint; it is people going around it. Unapproved suppliers appearing in the ledger, signed documents nobody in legal has seen, procurement cards used to avoid the purchase order process. Rising shadow activity means the official path has become slower than the risk of avoiding it, and that is a flow failure expressing itself as a control failure.

What to do on Monday

Take fifty completed contracts or purchase requests from last quarter. Reconstruct the timeline of each from the first request to completion, marking every interval as touch or wait. Compute flow efficiency. Present the distribution rather than the average, with the eighty-fifth percentile marked.

Categorise those fifty into provisional risk tiers. Count what proportion of your constraint's capacity went to the lowest tier. Take that proportion to the general counsel or procurement director as a capacity argument rather than a speed complaint.

Count the items currently open in each function and divide by weekly completions. That is the expected cycle time by Little's Law, and it is usually considerably longer than the number the function believes it delivers.

Define what a complete request looks like, publish it, and start the clock on completeness. Measure how many requests currently arrive incomplete; the number will justify the change on its own.

Then pick the single highest-volume, lowest-risk request type and build one genuine self-service path for it, with a template, agreed fallbacks and delegated authority. Removing that category from the queue entirely will do more for every remaining item than any amount of prioritisation within the queue.