A purchase order under this contract buys hours at a published ceiling. That is what the award settles, and it is very nearly all the award settles.
It is usually not what the buyer wanted. What a public organization wants from a consulting engagement is an object: something written down that says what to do, that a director can read without a translator, and that outlives both the person who wrote it and the budget year it was written in. The hours are how that object gets made. They are not the object.
Nothing in the award performs that conversion. It happens, or fails to happen, in a sentence somebody writes into the order.
Buying an object rather than an interval
The same piece of work can be bought two ways under the same ceiling, and the choice decides what you are left holding.
Bought as an interval, the engagement is a quantity of expert time. It ends when the time is used. Whatever exists on the last day is what you get, and if that is a shared understanding among four people who attended the meetings, the understanding leaves when they do.
Bought as an object, the engagement is a named thing with a stated shape, and it ends when that thing is delivered and accepted. The hours become the supplier's estimating problem rather than yours.
Neither is wrong. Supplemental capacity is genuinely an interval and should be bought as one. But advisory work sold by the hour and never named as an artifact has a way of concluding without producing anything a successor can pick up. The unit price is identical either way, because the ceilings are published in advance; what an hour costs is set out in the published rates for this contract. What is not settled anywhere is which of the two things you are buying.
Many engagements are honestly both: a fixed artifact first, then a quantity of time to help act on it. That is a sound arrangement and it is worth writing as two things in the order rather than one. An order that runs them together tends to consume the artifact's effort in early implementation work, and the document arrives thin, late, or as a set of slides assembled in the last week.
What the artifact contains
A document written for a procurement decision is a narrow genre, and it is not the same as a technical report. Its reader is somebody who has to approve money, defend the approval, and hand the file to a successor. That reader needs six things, and a document missing any of them tends to come back.
- The question, restated in the organization's own words rather than the supplier's, so the answer can be checked against what was actually asked.
- What was examined and what was not. A review that was never given access to the finance system should say so, in the document, rather than leaving the omission to be discovered later.
- Findings with their evidence attached, so a reader who doubts one can check it without reopening the engagement.
- A recommendation, and the options rejected, and why. The rejected options are the part a board asks about and the part most often left out.
- What it would cost and in what order, at a level of confidence the document states plainly.
- The assumptions, dated. An assumption without a date cannot be tested later, and this is the section that decides whether the document is still usable in eighteen months.
Two things about the shape of it are worth putting in the order as well. State that the document opens with a summary a non-technical reader can act on, because the audience that approves money is rarely the audience that commissioned the work. And say roughly how long it should be. Length is not quality, and an unbounded page count reliably produces a document that is circulated, praised and never read to the end.
That list is deliberately generic, because the contents of a plan depend on its subject and this page is not the place to specify any of them. Where the subject is a district's security program, what belongs in a district security plan covers it properly. And for a worked example of a named artifact with its contents published in advance, LABUSA describes one in an AI and technology roadmap, set out in full.
How it is produced
Turning a ceiling into an artifact is mostly a matter of writing three things down before anyone starts.
Name the artifact in the order, with its table of contents. Not "a report" but the document, listed section by section. That list is the specification, and it is what makes the later question of whether the work is finished a matter of fact rather than of taste.
Ask for the estimate by role and by hour against the published ceilings, and read the arithmetic. An estimate expressed that way can be argued with: too many senior hours, too few, an activity nobody needs. A single total cannot be argued with at all, only accepted or refused.
Agree the checkpoints inside the effort. An outline before a draft, a draft before a final, each with a named reader and a date. Most disappointing documents were not badly written; they were written all the way to the end in the wrong direction, and the outline would have cost an hour to correct.
Then be honest about what the supplier needs from you, because a document is made largely out of your organization's own information: people who will sit for an interview, records in a usable form, and decisions taken by a date. A supplier who cannot list those dependencies has probably not produced this artifact before. Where those obligations belong, and who signs the order that carries them, is covered in how the order gets issued and approved.
How it is used afterwards
The value of a written deliverable is mostly realized after the engagement that produced it has closed, which is why it is worth specifying as an object in the first place.
It becomes the specification for the next purchase. A scope written from a completed assessment is quicker to produce, cheaper to price, and less likely to be quoted defensively, because the supplier is no longer pricing uncertainty about your environment.
It becomes the paper that goes to the board, which is a different document from the one that goes to the IT team, and a deliverable written only for the second audience will be rewritten by somebody for the first.
It becomes the briefing for whoever inherits the work. Public-sector roles turn over, and the institutional memory of a project frequently leaves with one person.
It is also the evidence the next time the same requirement comes round. A year later somebody will ask whether the position has changed, and an organization holding a dated document with stated assumptions can answer that in an afternoon rather than by commissioning the review again.
And it becomes the answer when somebody asks why the money was spent that way. For purchases made with federal award funds, the standards at 2 CFR 200.318, the federal general procurement standards, require records sufficient to detail the history of a procurement. A document that states its question, its evidence and its rejected options is most of that record already.
One discipline makes all four uses possible: put a review date on the document itself. An undated plan is treated as current long after it stopped being true.
What makes a written deliverable acceptable
Acceptance is where an artifact purchase either works or quietly becomes an interval purchase after all, and it needs three sentences in the order.
- Who accepts it, named by role before the work starts, with somebody named as their alternate. A deliverable with no acceptor drifts.
- The test. Completeness against the stated contents is a test a supplier can meet and a buyer can apply. Satisfaction is not a test, and an order that asks for a document to be acceptable to the customer has agreed nothing.
- The window, with a stated consequence at the end of it. A review period that expires into acceptance protects the supplier from an indefinite obligation and protects you from your own diary.
Say what a rejection produces as well: a defined revision against the stated contents, not an open-ended duty to keep working until everyone is happy. Where federal funds are involved, the same standards oblige the buyer to maintain oversight that a contractor performs in accordance with the terms of its purchase order, which is only possible if the terms said something specific.
What a supplier's answers to all of this look like when they are strong, and when they are not, is set out in comparing two responses under the same contract.
Where this leaves the order
Everything above reduces to a short paragraph in a purchasing document: the artifact, named, with its contents listed; the effort estimated by role against the published ceiling; the checkpoints; the acceptor and the test; the review date. Five sentences, written before the work starts, are the whole difference between owning a document and having funded some activity.
The service categories available, and the roles and ceilings the work is estimated against, are set out on the award a named deliverable is ordered under. If you can describe the decision your organization has to make, LABUSA can help turn it into a specified artifact with an acceptance test attached, and you are welcome to tell us what you need to decide.