Most of the difficulty in buying professional services through a cooperative contract has nothing to do with the contract. The contract settles one question, which is whether a competitive procurement has already been carried out. Everything else, and it is most of the work, happens inside your own organization.
This is a practical sequence for getting from "we need help with this" to a supplier starting work. It assumes you already know how cooperative purchasing works. It is a description of common practice, not legal advice, and your own procurement office has the final word on every point below.
Confirm three things before you do anything else
These are quick to check and expensive to get wrong, because each one can invalidate the whole approach after you have spent weeks on it.
- Membership. Is your organization a current member of the cooperative? Membership can lapse, and it is checked against the cooperative's own records rather than a supplier's. For TIPS, membership and the current contract list are published at tips-usa.com.
- Authority. Do your own policies permit purchasing through a cooperative contract for a purchase of this type and this value? This is set by your organization, by statute, and by whatever thresholds your governing body has adopted. It is not set by the cooperative and it is certainly not set by the supplier.
- Category. Is there a contract awarded for the category of work you are buying? A supplier holding a contract for one category does not thereby hold one for another.
If any of the three is uncertain, resolve it before you invite anyone to scope work with you. Suppliers are generally happy to help you find the right contract number, but they cannot tell you what your own rules allow.
Define the requirement, not the solution
The most common failure in a services purchase is describing the answer rather than the problem. "We need two network engineers for six months" is an answer. It may be the right one, but stated that way it prevents anyone from telling you that four weeks of design work followed by a two week installation would achieve the same outcome for less.
A requirement worth putting in front of a supplier usually contains four things:
- The outcome you need, described in terms someone outside your organization would understand.
- The constraint that makes it urgent or difficult: a date, a compliance obligation, an expiring system, a dependency on another project.
- What already exists, at least in outline. Suppliers price uncertainty, so an unknown environment is priced as an expensive environment.
- What you will do yourselves, and what you need someone else to do.
That last point saves more money than any negotiation. An organization that intends to run its own change control, provide its own after-hours access, and handle its own user communications is buying a materially smaller engagement than one that is not, and the difference should be stated rather than discovered.
Identify the correct contract, and record why
Find the contract awarded for the category of work you are buying, confirm it is current, and note the number. Then write down, in one or two sentences, why that contract covers this purchase. This takes a minute and it is the note that answers the only question an auditor is likely to ask.
Where a requirement genuinely spans two categories, say infrastructure work and application work, ask before assuming a single contract carries both. The answer is often yes, sometimes no, and it is far cheaper to find out at this stage.
Write a scope the supplier can price
A cooperative contract establishes a commercial framework. It does not tell anyone what you want. For a services purchase, the scope you write is the actual specification, and it does most of the work that a solicitation document would otherwise have done.
A workable scope answers: what is being delivered, by when, to whom, and how anyone will know it is finished. For an assessment that might be a written report and a briefing. For an implementation it might be a system in production with documentation handed over and staff trained on it. For supplemental resources it might be a named skill set for a defined period with agreed reporting lines.
Two things are worth being explicit about because their absence causes most disputes: who provides access to systems and premises, and what happens if the environment turns out to differ from the description. Neither needs to be adversarial. Both need to be written down.
Request pricing
With a scope in hand, ask the supplier for pricing and a proposed approach. What you should get back is not only a number but a statement of what that number assumes. Read the assumptions before the total, because that is where the difference between two quotes usually lives.
Some cooperative contracts publish their rates as part of the award, in which case the hourly figures are settled before you ask and the estimate turns entirely on hours and mix. LABUSA's are published, and are set out in what TIPS 230601 IT consulting costs. Where rates are published, ask for the estimate broken down by role and hours rather than as a single total: it is the only form in which you can judge whether the mix is sensible.
If the response arrives with an approach you did not expect, that is often useful information rather than a problem. A supplier who has done the same work at other organizations may reasonably propose a different sequence. Whether to accept it is your decision, but the reasoning is worth hearing.
Some organizations obtain more than one quote even when a cooperative contract is being used and a single quote would satisfy their rules. That is a local decision about diligence rather than a requirement of the model.
Take it through internal approval
This is the step most likely to determine your timeline, and the one suppliers have no visibility of.
Every organization has thresholds: a value below which a manager can approve, a value above which the finance office must, and a value above which the governing body must. Cooperative purchasing does not change any of them. Find out which threshold your purchase falls into before you promise anyone a start date, because the difference between "the director signs" and "it goes to the next board meeting" can be six weeks.
The paperwork the approver needs is usually modest: the requirement, the quote, the contract being relied on, and the note you wrote earlier explaining why that contract covers this purchase. Assembling it in advance turns an approval into a formality.
Issue the purchasing documentation
Follow your organization's normal process. Two details are specific to cooperative purchasing and both are easy to omit:
- Reference the contract by number on the purchase order. This is what connects your purchase to the competitive procurement you are relying on. A purchase order that does not cite it is, on its face, an uncompeted purchase.
- Attach or reference the agreed scope. A purchase order with a value and no scope is an invitation to disagree later about what was bought.
Start the engagement properly
Agree, before the first day, who the supplier reports to, how progress will be reported and how often, who can approve a change in scope, and what the escalation route is when something is not going well. None of this is contractual ceremony. Services engagements that go wrong usually go wrong because nobody was clearly accountable for noticing early.
A worked example
This is an illustration of the sequence, not a recommendation and not a description of any actual organization.
A public agency finds that its core switching hardware is out of support and must be replaced before the next audit. It has one network administrator, who has not carried out a replacement at this scale.
The agency writes a requirement: replace the core switching at two sites, before a stated date, with no more than one planned outage per site, retaining the current addressing scheme. It notes that it will provide out-of-hours site access and will handle its own user communications, and that it needs design, configuration, installation, and knowledge transfer to the existing administrator.
Procurement confirms membership is current, confirms that policy permits cooperative purchasing at the expected value, and identifies a contract awarded for the relevant technology category. The agency sends the requirement to a supplier holding that contract and receives a quote with a fixed design and installation phase, an hourly rate for anything found to be different from the description, and a named engineer for the knowledge transfer.
The value sits above the director's threshold, so the item goes to the governing body with the quote, the contract number, and the one paragraph explaining why the contract covers the work. Approval is given, a purchase order is issued citing the contract number and attaching the scope, and work is scheduled for the following month.
Total elapsed time is measured in weeks. Almost all of it is the agency's own scoping and approval. The contract removed the solicitation; it did not remove anything else, and it was never supposed to.
What procurement should ask before signing
- Is our membership current, and is the contract we are citing current?
- Is the contract awarded for the category of work in this scope?
- Does our policy permit cooperative purchasing at this value, and where is that recorded?
- Does the purchase order cite the contract number and attach the scope?
- Is it clear what is fixed price and what is variable, and what triggers the variable part?
- Do we know who accepts the deliverable on our side?
The point of all this
Cooperative purchasing removes one step from a long process. It is a genuinely useful step to remove, and for a small team it can be the difference between a project happening this year and next. What remains is ordinary purchasing discipline: know what you want, know what you are allowed to do, write it down, and agree how you will tell whether it worked.
One last point on scoping, because it decides which of those two shapes you are buying. Work with a definable end, such as an assessment or a migration, is a project. Work with no natural end, such as monitoring, patching, and help desk, is a service, and LABUSA describes that side of it on its managed IT services page. Deciding which one your requirement is before you ask for a price prevents the most common mismatch between what an organization approves and what it receives.
LABUSA holds awarded TIPS contracts in several categories, and the IT services available through TIPS include consulting, project management, staff augmentation, cybersecurity, cloud migration, and application development. If you have a requirement and want help turning it into something that can be scoped and priced, that is a reasonable conversation to start early.