A municipal utility that starts an HRIS RFP from a vendor’s template will buy the shape of that template. The work that has to happen first is unglamorous: a requirements catalogue, an integration inventory, a decision on what stays outside the suite, a named internal team, and a calendar counted backward from the date the current system will no longer be supported.
This is that list. It is for electric, water, wastewater, gas, and fiber utilities, and for cities that run utility services on the same HR and payroll system as the rest of the municipality. The practice that carries it is HRIS and HCM advisory. The industry context is the utilities page.
None of this requires you to name a product yet. If you are already comparing UKG, Workday, and Oracle HCM, use the decision framework after this list exists, not before.
A requirements catalogue, by module
Write requirements from the work. Group them so a proposal can answer module by module, and so a demonstration script can point at a line.
- Core HR. Employee, job, position, department, and the manager relationship, including crews and plants that are not departments in the finance sense.
- Employee and manager self-service. What an employee can see and change. What a supervisor can approve from the field.
- Payroll administration. Cycles, retro pay, special pays, garnishments, and corrections. The pay codes you actually use.
- Time and labor administration. Timekeeping, scheduling, leave, on-call, call-out, and shift differentials if you run them.
- Benefits administration. Active employees, and retirees and surviving spouses and dependents who stay covered.
- Compensation and performance. Grades, steps, stipends, and how a pay plan or a contract becomes a rate.
- Labor administration. Disciplinary action tracking and the record a grievance will ask for.
- Health and safety. Drug and alcohol testing, workers’ compensation claims, and safety training with an expiration.
- Accomplishments. Certifications, licenses, and degrees, tied to the job that requires them.
- Union and bargaining rules. One bargaining unit or several. The rules that differ. Put the agreement in the requirements, not the phrase “supports unions.”
- Recruiting and learning. Only after you decide they are in scope. See below.
- Queries and reporting. The reports payroll, HR, finance, and a council packet actually ask for. Name them.
Retiree and pension data, and any interface to a retirement system, belong in the catalogue as a requirements area. That is not the same thing as claiming a pension-system project has already been done.
A catalogue this specific is what Caliber is for on our side of the table: requirements that stay attached to the script and the score. The tool is not the point. A traceable list is.
An integration inventory
Make a table before the RFP. One row per system.
Columns that matter: system name, what it does, direction of the data, how often it moves, who owns the business side, who owns the technical side, and whether the HRIS vendor, a separate integrator, or your staff will build and maintain it.
Rows a municipal utility usually has, when they exist in your environment:
- Finance system (payroll to the general ledger, position costing, project or fund accounting)
- Timekeeping, if it is not the HRIS itself
- ATS and LMS, if they stay outside the suite
- Compensation software
- Surveys
- Internal directory
- Badging
- Benefit-vendor EDI files
- Safety training
Add CIS or billing only if employee or payroll data actually moves there. Do not add it because both projects are “utility technology.” Customer billing and payroll share a board calendar more often than they share a database.
If you cannot name the system, you are not ready to ask a vendor for a price.
Data and retention
Decide what converts, what archives, and what is allowed to die.
Employee history, payroll history, benefits elections, disciplinary records, and certifications do not all have the same retention. Public-record schedules and your own audit practice set the floor. The RFP should say which history must be queryable in the new system, which must be retained in a read-only store, and for how long each is kept. Do not leave “all historical data” as a sentence. Vendors price that sentence in ways you will not like, and payroll will not be able to answer a question the archive cannot support.
Name the owner of each record type. A conversion with no owner becomes a spreadsheet the week before parallel payroll.
Pension and retiree records follow the same rule. Specify the data you must send or receive. Do not assume an interface exists because a proposal uses the word “integration.”
Decide ATS and LMS in or out
This decision belongs before the RFP, because it changes the requirements, the price, and the interfaces.
In the suite means recruiting and learning are requirements, demonstration scenarios, and contract scope. You will live with how that product handles a public-sector posting, a bargaining-unit eligibility rule, and the training a license depends on.
Out of the suite means you keep or buy a separate ATS or LMS, and the HRIS RFP includes the interface, not the module. You avoid paying for a module you will not turn on. You accept an integration you have to test.
Either decision is defensible. An RFP that says “propose your approach” is how you end up with three prices that cannot be compared. Write the decision down, tell the vendors, and make the demonstration match it.
Governance
Name who can change a requirement, who can accept a deviation, and who can slip a payroll date. A utility HRIS project has at least HR, payroll, finance, IT, operations (the people who run shifts), and an executive sponsor. If there is a bargaining unit, decide how labor relations sees the requirements that quote the agreement. They do not have to sit in every meeting. They do have to see the lines that paraphrase the contract.
Write the decision rights before the integrator arrives. Changing them during build is how scope becomes a dispute.
Risk management is the same forum: open interfaces, failed test cycles, a bargaining question nobody owns, a support end date that is now closer than the plan. Review it on a cadence the sponsor will actually attend.
The internal team
A vendor project plan assumes your people have hours. Most utilities do not have a bench of HRIS analysts waiting. Name the roles and the percentage of time before you release an RFP.
You will need, at a minimum: a payroll lead who can explain a difference in parallel testing, an HR lead who owns requirements, an IT lead who owns interfaces and access, a finance lead who will accept the journal, and a sponsor who can decide when the room is split. Backfill is part of the cost. If the payroll lead is also running payroll, parallel testing will lose.
Training and organizational change management are part of this team, not a communications email at the end. Every employee is a user. Managers in the field will not attend a downtown workshop unless the schedule says so.
Count the timeline backward
Find the date that actually constrains you. Often it is the end of vendor support on the current HRIS, or the last version you are willing to run, or a fiscal year you cannot cross with two payroll systems. Sometimes there is no such date, and the honest finding is that you can take longer. Manufactured urgency is a vendor’s clock. Yours should be written down. The test for a date in a letter is the same one in when not to replace.
If the date is real, plan backward from it:
- Stabilization after go-live, through at least the first payroll cycles that include a retro and a benefits change.
- Go-live on a payroll calendar, not on a Friday someone liked in a kickoff.
- Parallel payroll, enough cycles to compare real results, before that go-live.
- Testing of conversions and interfaces before parallel payroll.
- Configuration and data conversion before that testing.
- Contract execution before configuration.
- Evaluation, scripted demonstrations, and selection before the contract.
- The RFP only after the catalogue, the integration inventory, the ATS and LMS decision, and the team are real.
If step 8 does not fit before the support end date, the finding is not “write a shorter RFP.” The finding is that the date, the scope, or the staffing has to change, in front of the board, before you are in a procurement you cannot finish.
Parallel payroll is a gate, not a phase name
Parallel payroll means the new system calculates a real cycle beside the system that actually paid people, and someone explains every difference you have agreed matters. It is the test that payroll administration is ready.
Put the number of cycles, the comparison method, the threshold for a difference, and the person who signs acceptance into the statement of work. Oversight of that test is part of implementation oversight. Skipping it because the calendar slipped is how a utility finds out about a bargaining-unit differential on payday.
Data conversion oversight sits immediately upstream. A parallel that fails because the history was mapped wrong is a conversion problem. Do not “fix” it by changing the payroll rule to match the bad data.
Then write the RFP
When the list above is done, the RFP is mostly assembly: the catalogue, the inventory, the decisions, the team, the calendar, and the evaluation method. Planning and developing that RFP is straightforward. Doing it earlier is how the document starts making the decisions for you.
Avèro does this work as the utility’s advisor. We do not implement the software, we do not resell it, and we are not paid by the vendor who wins. If you are in front of a support end date, or you are being asked to release an RFP next month, write to us and say which date you are counting from.