Public agencies buy IT consulting for reasons that have very little to do with a shortage of technical ability. Agency technology teams are frequently excellent. What they lack is a second person who has done this particular thing before, or the eight uninterrupted weeks the thing would take, or the standing to tell a director that the plan will not work.
Those are three different problems and they call for three different kinds of engagement. Choosing the wrong shape is a more expensive mistake than choosing the wrong supplier, and it is made more often.
When an outside consultant is not the answer
Worth putting first, because a guide of this kind usually assumes the purchase.
If your team knows what to do and simply has not had time, what you need is capacity or a reordered set of priorities, not advice. Buying a strategy engagement to tell you something you already know is a way of converting a resourcing problem into a document.
If the decision is genuinely political rather than technical, an external report will not settle it. It may be useful as evidence, but be honest with yourself about which you are buying.
And if the question is small enough that a competent person could answer it in a week, the overhead of scoping, procuring, and onboarding an outside party will exceed the value of the answer. Ask a vendor you already work with, or ask a peer agency. Cooperative contracts make purchasing easier; they do not make small purchases worth making.
Four engagement models
Nearly everything an agency buys under an IT consulting contract is one of four shapes. They differ in who is accountable, how they are priced, and how they end.
Strategic advisory
An experienced practitioner works with your leadership on decisions rather than delivery: what to prioritize, what to retire, how to sequence a modernization across budget years, how to structure governance. The deliverable is a decision and the reasoning behind it, usually written down.
Accountability sits with your organization throughout. The adviser is accountable for the quality of the advice, not for the outcome of acting on it. This is the model to use when the question is "what should we do", and the wrong one when you already know and need it built.
Defined project
A scope with a start, an end, and something handed over: an assessment, a design, a migration, an implementation. The supplier is accountable for delivering the defined thing, and the engagement ends when it is delivered.
This is the model most public agencies default to, and for good reason. It fits budget cycles, it is straightforward to approve, and it fails visibly rather than quietly. Its weakness is that it needs the requirement to be knowable in advance. Where it is not, a small assessment engagement first is usually cheaper than a large project scoped on guesswork.
Supplemental technology resources
Experienced people working alongside your own team, under your direction, for a defined period. Accountability for the outcome stays with you; the supplier is accountable for supplying capable people.
This is the right model when you know exactly what to do and lack the hands to do it, or when a modernization project would otherwise consume the same staff who keep the lights on. We cover the model in detail, including how to define outcomes so an engagement can actually end, in our article on IT staff augmentation.
Ongoing managed support
A continuing service rather than an engagement: monitoring, administration, help desk, patching, and the operational work that has no natural end date. Priced as a service, renewed rather than completed.
Agencies sometimes buy this when what they actually wanted was a project, because ongoing cost is easier to approve than capital. That is worth noticing, since a permanent operating cost is a larger commitment than a one-off project, not a smaller one.
The two decisions people conflate
This is the part that causes the most avoidable trouble, and it is almost never written down anywhere.
Choosing what to do, and choosing how to buy it, are separate decisions. They are usually owned by different people, they answer to different criteria, and they are best taken in that order.
The first decision is technical and operational. What outcome do we need, what approach will achieve it, what shape of engagement fits, and what would good look like? That belongs to the technology function, informed by whoever will live with the result.
The second decision is procedural. Given that we know what we want, what is the compliant, efficient way to buy it? A cooperative contract, an existing agreement, a fresh solicitation? That belongs to procurement.
Taken in that order, the procurement vehicle is a means to an end and the conversation is short. Taken in the wrong order, the available vehicle starts to shape the requirement, and the agency ends up buying the thing that was easiest to buy rather than the thing it needed. The tell is a scope of work that reads as though it were written to fit a contract category rather than to solve a problem.
One clarification, because the words overlap. Procurement advisory, meaning help deciding what technology to buy and how to manage it through its life, is itself a consulting service an agency can purchase. That is a different thing from cooperative purchasing, which is a mechanism for buying. An agency can use the second to obtain the first.
What the work actually consists of
Across those four models, the substance an agency buys tends to fall into a small number of areas.
- Planning and assessment. Establishing what exists, what condition it is in, what it costs, and what the options are. Almost always worth doing before a large commitment, and almost always cheaper than the commitment.
- Project and program leadership. Running an initiative that crosses teams, vendors, or budget years. Frequently the difference between a technically sound project and one that finishes.
- Infrastructure and networks. Design and delivery of the physical and logical foundations, which for public agencies often means work scheduled around when buildings are empty.
- Cybersecurity. Assessment, architecture, vulnerability management, governance, and policy. Distinct from operational security monitoring, which is a managed service.
- Cloud. Readiness, migration planning, architecture, and the cost governance that determines whether the move saves anything.
- Applications and integration. Building what is not available, connecting what is, and modernizing what has become a liability.
- Governance and compliance. Structures, policies, and the evidence that they are being followed.
LABUSA's own description of the consulting work it does is on the IT consulting capability page. This article is deliberately about the category rather than about one supplier's version of it.
Reading a proposal
Proposals from experienced suppliers tend to look similar on the surface. Four things separate them, and none of them is the total.
- Does it restate your problem in its own words? A proposal that repeats your requirement back verbatim has not been thought about. One that reframes it, and explains why, has.
- Are the assumptions written down? Every fixed price rests on assumptions about access, environment, and your own team's availability. A proposal that lists them is easier to hold to than one that does not, and the omission usually surfaces as a change order.
- Is there something left behind? For a public agency, an engagement that ends with documentation your staff can use is worth considerably more than one that ends with a report only the author understands.
- Does it say what is not included? Suppliers who are specific about exclusions are generally being specific about everything else too.
Choosing well
Three questions usually settle the model.
- Do we know what to do? If no, buy advisory or an assessment. If yes, do not buy advice.
- Is there a definable end? If yes, buy a project. If no, you are buying either supplemental resources or a managed service, and the difference is whether you or the supplier directs the work.
- Who should be accountable for the outcome? If it must be you, do not buy a model that transfers it. If it can be the supplier, do not buy a model that leaves it with you.
An agency that answers those three before approaching the market gets better proposals, because the proposals are answering the same question.
Where the vehicle comes in
Only at the end, and that is the point. Once the shape and the scope are settled, the procurement question is narrow: is there a competitively awarded contract covering this category of work that our organization is permitted to use?
Where there is, the remaining work is scoping, pricing, and internal approval, which is the process set out in our guide to purchasing IT services through a cooperative contract. Where there is not, you run a solicitation, and the earlier decisions you made about model and scope become the specification.
LABUSA holds an awarded TIPS contract for IT consulting and related services. If you have worked out what you need and want to know whether it can be bought that way, the detail of LABUSA IT consulting through TIPS sets out the service categories the contract covers.