A department does everything right during vendor evaluation. Feature demos, reference calls, price comparisons. They sign the contract and implementation begins. Within weeks something goes wrong. The battalion chief's staffing logic doesn't match the union agreement. Payroll is still running manual corrections. Firefighters can't log in from the app without calling IT.
The scope was defined for whoever was in the room during the demo, and the user groups who would actually live in the system daily were never part of that conversation.
A feature list tells a department what a system can do. Whether that system was configured, tested, and validated for the people who will use it every day is a separate question, and one that most vendor evaluation processes never fully answer. Getting scope right means defining it for every user group before the contract is signed, surfacing the operational constraints that shape implementation, and agreeing on what a successful go-live looks like for each part of the department involved.
Most procurement conversations happen at the command level. The fire chief reviews the demo, the administrative staff evaluates pricing and integration requirements, and the vendor shows its strongest workflows to whoever is in the room. By the time the contract is signed, the scope reflects the needs of the people who attended those meetings.
That creates a problem because a fire department runs on several distinct user groups, and each one interacts with the platform in a completely different way.
Battalion chiefs and scheduling officers need staffing logic to be accurate in the specific configuration the department runs. Overtime rules, staffing lists, Kelly Days and shift patterns, and FLSA compliance all have to work together correctly. When they don't, workarounds start on day one and build up over time.
Payroll administrators need the system to handle calculations that fire department payroll demands. Pay code logic, FLSA calculations, timecard approvals, specialty pay differentials, and acting pay assignments all have to be processed correctly before a paycheck goes out. Their measure of success is whether the platform helps them process payroll faster or adds a new layer of manual work to a cycle that was already complicated.
Firefighters need the system to work on a phone without requiring them to remember a password. Single sign-on, mobile access, and an interface that doesn't require retraining determine whether they actually use the platform in practice. Everything else is secondary to those three things.
Most vendors design well for one of these user groups, sometimes two. Departments that don't map requirements across all user types find the gaps after go-live, when the cost of addressing them is significantly higher. The questions worth putting to any vendor before signing are a useful starting point for making sure those conversations happen before the contract is done. For chiefs navigating vendor evaluation, the IAFC Technology Council is a resource specifically focused on technology decisions in the fire service.
Three gaps surface consistently in departments that didn't address them before signing.
Fire departments that work under collective bargaining agreements frequently have contract language that directly governs how scheduling, overtime distribution, and shift assignments operate. That language is often more specific than either the department or the vendor anticipates during a standard discovery process. Minimum staffing requirements, overtime distribution rules, seniority-based callout procedures, and shift trade policies can all be structured in ways that a vendor's standard configuration doesn't accommodate without custom work.
When a CBA clause turns out to be incompatible with how the vendor's system handles a particular workflow, the options are limited. A custom build adds cost and time to an implementation that may already be behind schedule. Revisiting the CBA language means reopening a negotiation most departments aren't eager to start. A workaround typically means recreating some version of the manual process the department was trying to replace. The IAFF's collective bargaining resources detail the kinds of provisions common in fire department labor agreements, and research from the UC Berkeley Labor Center has documented how technology adoption frequently intersects with contract language in ways that don't get surfaced during procurement.
The CBA belongs in front of the vendor during discovery.
Fire departments operating within municipal governments typically don't control their own IT environment. Cybersecurity reviews, procurement approvals, vendor vetting, and system integration clearances are managed by city or county IT departments that operate on their own timelines. A vendor can be technically ready to begin implementation while a department is still waiting on the municipal IT sign-off required to connect the platform to existing systems.
Implementation timelines in contracts are built around vendor capacity and the department's stated readiness. They rarely account for the municipal approval layer sitting between the two. Mapping those dependencies before signing means understanding which city or county approvals are required, who owns each approval, and what a realistic timeline looks like given how those processes have run in the past.
Payroll in fire departments is substantially more complex than in most public sector agencies. Acting pay, specialty pay differentials, FLSA Section 207(k) calculations, Kelly day adjustments, and timecard approval chains all have to interact correctly with the payroll system for a pay period to close accurately.
The One Big Beautiful Bill, signed into law in July 2025, added a federal reporting requirement that departments separately identify FLSA-required overtime premium from CBA-required overtime on payroll records. That distinction matters for W-2 reporting beginning with the 2026 tax year, and it adds another documentation layer to an already complex payroll environment. A standard payroll integration typically handles basic time entry and employee data. The fire service-specific complexity that sits on top of that is what creates reconciliation problems for departments that didn't surface it during scope definition. A closer look at how payroll errors compound across a department's pay cycle shows how far downstream the consequences run.
Getting payroll administrators into the scope conversation before the contract is signed gives both sides a clear picture of what the integration actually needs to do.
There are four things worth covering before the contract is signed.
Most vendor demos show the system from an administrative or management view. Asking to see the batch scheduling workflow from a battalion chief's seat, the timecard processing flow from a payroll admin's seat, and the mobile login experience from a firefighter's perspective surfaces configuration questions and capability gaps that a single admin-level demo won't reveal.
The relevant sections are those governing scheduling, overtime distribution, callout procedures, and shift assignments. Getting written confirmation of how those clauses are handled in the vendor's system, in the exact configuration the department runs, removes one of the most common sources of post-go-live surprises.
That means knowing which city or county approvals are required, who owns each approval, what the typical turnaround time has been for similar requests, and whether the implementation schedule can realistically accommodate those timelines before it gets locked.
The system going live for the administrator and payroll reaching its first accurate pay period close are different milestones. Documenting what a successful go-live looks like for scheduling, for payroll, and for the frontline user, and naming who has sign-off authority for each, turns a vague contract milestone into something departments can hold a vendor accountable to.
PMI research has consistently identified an incomplete scope statement as one of the leading causes of project failure across industries. A more complete discovery process, run before the contract is signed, is what closes that gap. For a fuller set of questions to bring into vendor conversations, this guide covers the specifics.
Vendors write scope based on what they hear during discovery. A vendor who conducts discovery exclusively with command staff will write a scope document that reflects command staff needs. That's how most discovery conversations are structured, and it means the gaps in user coverage are built into the project before implementation even starts.
Departments that get scope right treat the discovery process differently. That means getting payroll administrators, scheduling officers, and a representative frontline user into the conversation alongside command staff. It means bringing the CBA, the current payroll configuration, and the IT dependency map to discovery before the contract is drafted. And it means agreeing, in writing, on what a successful implementation looks like for each user group before anyone signs anything.
The friction points that follow from these gaps, and how departments have navigated them, are the focus of the webinar.
Getting scope right is a decision that happens before the contract is signed. The work is identifying the right people for the discovery conversation and defining what success looks like for each of them before implementation begins.
The webinar "When Technology Meets Reality: A Fire Chief's Playbook" brings together fire service leaders from command, admin, and labor to work through exactly these friction points. Register here!
.png)
