Districts bring in outside technical people for two quite different reasons, and conflating them produces most of the disappointment associated with the model.
The first is cover. A network administrator resigns in February, the replacement will take four months to recruit and onboard, and in the meantime somebody has to keep the network running. The second is capability. The district is replacing a system nobody on the team has replaced before, and it needs someone who has, for as long as that takes.
Both are legitimate. They call for different people, different contract lengths, and different definitions of success, and a district that asks for one while needing the other tends to get an engagement that nobody is happy with.
Why district teams run short
Not usually through poor planning. The structural reasons are consistent across districts of very different sizes.
Central technology teams are sized for steady state, and steady state in a district is already demanding. When a modernization project arrives, it arrives on top of that rather than instead of it, and the people best qualified to run it are the people whose absence would be noticed first.
Specialist skills are needed intermittently. A district might carry out a core network replacement once every seven years. Employing someone who can design one is not a sensible use of a permanent position, but needing that skill for four months every seven years is entirely real.
And recruitment is slow and competitive. A district hiring a cloud engineer is competing with the private sector on salary, and the posting-to-start timeline is measured in months. That gap has to be covered by someone.
Cover and capability need different things
When you are buying cover, continuity is the point. You want someone who can pick up an existing environment quickly, keep it stable, follow the district's established practice, and hand back cleanly. Deep specialism matters less than adaptability and a tolerance for the unglamorous. The measure of success is that nothing noticeable happened.
When you are buying capability, the point is that this person has done the specific thing before. You are paying for judgment accumulated somewhere else, and you want it applied to your environment and then left behind in a form your own team can use. The measure of success is that the thing works and the district understands it.
Ask which one you are buying before you write the requirement. It changes the length, the profile, and what you should be checking at the end.
The roles districts most often bring in
The contract defines these roles and publishes an hourly ceiling for each, so what a role costs is known before you ask. What scoping settles is which of them your work actually needs, how many hours, and whether a specialist is free on your dates. The rates are set out in what TIPS 230601 IT consulting costs.
- Network engineers. Wireless design and remediation, switching, segmentation, and the work around a refresh.
- Systems administrators. Servers, directory services, backup, and the day to day that cannot pause during a project.
- Cloud engineers. Migration, identity integration, and the configuration that determines what a cloud platform actually costs.
- Cybersecurity specialists. Assessment and remediation work, and support for policy and governance that a district team rarely has time to write.
- Enterprise architects. For districts trying to make several systems work as one rather than as five, usually in short engagements.
- Developers and integration specialists. Connecting a student information system to everything else that needs to read from it.
- Project managers. Frequently the highest-value role and the one districts add last, after discovering that a technical lead running a project is not doing either job fully.
- Business analysts. Turning what campuses say they need into something that can be built or bought.
Using the model to deliver a project
The most productive pattern is not "hire hands to do the project". It is to use supplemental resources to protect the district team's capacity so the district team can do the project, or to bring in the one specialism the project genuinely requires while the district retains ownership.
That distinction matters because ownership determines what happens afterwards. A project delivered entirely by outsiders leaves a district operating something it did not design. A project the district led, with outside help where it was needed, leaves a district operating something it understands. The second costs about the same and is worth considerably more.
They are not district staff, and the distinction matters
Supplemental technical resources are supplied under a services agreement. They are not district employees, and treating the arrangement as though they were creates problems for both parties.
Practically, this means the district directs the work but does not manage the person's employment. Hours, conduct, performance management, and the employment relationship itself sit with the supplier. If the fit is wrong, the district raises it with the supplier rather than performance-managing an individual, and a replacement is a commercial conversation rather than a personnel process.
Two district-specific points are worth settling explicitly at the outset. Districts generally require criminal history and background screening for anyone working on campus or with access to student data, and the engagement should state who arranges and evidences that. And access to student information systems is usually governed by district policy about who may see what; agree the access level and the reason for it before the first day rather than at the point somebody needs it.
Knowledge transfer is a deliverable, not a courtesy
The most common failure of the model is an engagement that ends with the environment working and nobody inside the district able to maintain it.
This is avoidable, and it is avoided by treating knowledge transfer as something specified and accepted rather than as something that happens if there is time at the end. In practice that means naming the district person who will own the system afterwards, and stating what they will have when the engagement closes.
Useful things to specify: written documentation of the configuration as built rather than as designed, a walkthrough with the named owner, the routine tasks written down as procedures, and an agreed period after handover during which questions can still be asked. None of that is expensive if it is scoped at the start. All of it is expensive to recreate afterwards.
Define the engagement so it can end
Staffing engagements drift. They drift because they are priced by time rather than by outcome, and because a capable person who is already there is easier to keep than to replace. Three things prevent it.
- State the outcome, not just the duration. "Six months of a network engineer" has no end condition. "Wireless remediated across four campuses, documented, with the district administrator trained on the management platform" does, and it may take five months or seven.
- Name who directs the work day to day, and who reviews it. Resources without a clear district owner default to whoever asks loudest, which is rarely the priority.
- Set a review point before the money runs out. A checkpoint at roughly the two-thirds mark is enough to decide whether to extend deliberately rather than by default.
Extending an engagement is a perfectly reasonable decision. Extending it because nobody noticed it was ending is not the same thing.
What to check before the engagement starts
A short list, most of which takes minutes and saves weeks.
- Is there a named district owner? One person who sets priorities for this resource and who is available to answer questions. Shared ownership is no ownership.
- Is workspace and access ready? Accounts, credentials, VPN, building access, and a place to sit. A specialist waiting three days for a login is a specialist you are paying to wait.
- Has screening been completed and evidenced? Start it early. It is routinely the thing that delays a start date.
- Does the district team know why this person is here? Supplemental resources introduced without explanation are read as a judgment on the existing team. A sentence from the technology director at the right moment prevents a great deal of quiet resistance.
- Is there a written handover expectation? Even one paragraph. See above.
How districts buy it
Staff augmentation is a professional services purchase, so it needs a scope in the same way a project does: what the person will work on, for how long, reporting to whom, and what will exist at the end. A rate alone is not a scope. The hourly ceilings are published, which removes one variable from the conversation and leaves the one that actually decides the total, which is hours.
It is also worth checking whether the district actually wants people or wants a service. If the need is continuous operational work with no end point, a district is usually better served by managed IT services than by an indefinite series of extensions, because the accountability and the pricing both change. Supplemental staff suit defined periods and defined outcomes.
Districts that are eligible TIPS members can obtain technology professionals through TIPS, subject to their own purchasing policies and approval requirements. The purchasing sequence itself is not specific to staffing and is set out in our guide to purchasing IT services through a cooperative contract, while the wider question of which engagement model fits a given problem is covered in our guide to IT consulting for public agencies.
If the requirement is one specialist for one project, say so plainly. It is a much easier thing to scope, price, and approve than a general request for help, and it is far more likely to end when it should.