Step 8 · Plan the Implementation

Decide how the technology will be configured, integrated, deployed, supported, trained and introduced before the contract is signed and the rollout begins.

GUIDE · 14 min read
Step 8 · Plan the Implementation

The short version

Implementation planning belongs before the signature, not after it. Name three owners and make sure everyone knows which is which: the project owner who is accountable for the outcome, the technical owner who deals with configuration and integrations, and the operational owner who answers for how it works on the floor. Then work through the unglamorous list — timeline, configuration, integrations, data migration, user accounts, policies, training, communications, support and what you do if it goes badly.

The fourth owner: sustainment

The project owner, the technical owner and the operational owner have one thing in common. Their job is largely finished when the rollout is finished.

Name a fourth. The sustainment owner is the person responsible for making sure the system is still functioning, funded, administered and supported after implementation ends.

That is a different job from the other three, and it is the one that quietly goes unassigned. It is also the one that decides whether this system is still working in year three or has become the thing everybody works around.

Implementation has an end date. Ownership does not.

Plan for Day 366

Day 366 is the first day the project is nobody's project. The consultant has gone, the go-live team has moved on, the vendor's implementation contact has been reassigned, and the system is simply part of how the department works.

Decide who holds each of the following before go-live, by name, and write the names somewhere the next person will actually find them.

Name these before go-live

  • Primary system administrator
  • Backup administrator
  • Operational owner
  • Technical support owner
  • Budget and renewal owner
  • Vendor contact
  • Training owner
  • Documentation location
  • Account and credential recovery process
  • Annual review date

If the only person who understands the system retires, promotes, transfers or leaves, can someone else keep it running tomorrow?

Documentation that has to exist before go-live

Not a binder nobody opens. A findable, current record of the things the next administrator would otherwise have to reconstruct from scratch.

  • Administrator documentation
  • Configuration documentation
  • Integration documentation
  • Vendor contacts
  • Renewal dates
  • API credentials and secrets — held in the department's approved credential store, never written into the documentation itself
  • Training materials
  • Known issues
  • Support procedures

Plan the old system's retirement before the new one goes live

The new system gets a project plan. The old one usually gets forgotten, which is how a department ends up paying for two systems, maintaining two sets of records, and quietly depending on the old one for the information nobody migrated.

Decide all of this before go-live, while the vendor is still paying attention and the budget conversation is still open.

The retirement checklist

  • Parallel-operation period — how long it runs, and what ends it
  • Historical data migration
  • Records retention
  • Read-only archival access
  • Legal retention requirements
  • Contract termination
  • Exporting data
  • Removing old accounts
  • Revoking vendor access
  • Hardware disposal
  • Old integrations
  • When the old workflow officially stops

Running two systems indefinitely is not a transition plan.

Two items on that list are worth checking with someone outside the project team.

Retention obligations for public safety records are set by law and by your records retention schedule, not by whatever the new system happens to store. Confirm them with your records custodian or legal counsel before anything is deleted, and before anything is left behind in a system you are about to switch off.

And confirm what happens to your data in the old system once the contract ends. Some vendors delete it on a schedule, some hold it, some charge to return it. The answer is in the contract you signed rather than in the relationship you have with the account manager.

See it applied

Worked example — built from published USFA sources, not from a department's reported results

Worked Case Study: The NERIS Transition Through the Technology Adoption Roadmap

Every fire department reporting incident data had to move from NFIRS to NERIS on a national timetable. The destination was fixed; almost everything else was still a local decision. This works the twelve steps through that transition, using published U.S. Fire Administration material for the facts and clearly labelled examples for everything a department would do locally.

Read it

Go deeper

Questions to ask your vendor

  1. Who owns this project, technically and operationally?
  2. Who owns it after implementation ends, and who is the backup?
  3. What has to be configured before anyone logs in?
  4. What data are we migrating, and who checks it?
  5. How are accounts created, and what happens when someone leaves?
  6. What policy has to change before go-live?
  7. How is training delivered across every shift?
  8. When does the old system actually get switched off?
  9. What is our contingency if the rollout has to stop?