Step 12 · Lessons Learned and the Technology Roadmap

Capture what worked, what failed, what you would change, and what the project revealed about the department's next technology priorities.

GUIDE · 20 min read
Step 12 · Lessons Learned and the Technology Roadmap

The short version

Every technology project should make the next technology decision better. Write down the lessons while they are still uncomfortable and specific: what worked, what failed, what you would do differently, the gaps this project exposed, the dependencies you discovered, the training that turned out to be necessary, and what all of that says about your three-year priorities. Then go back to the beginning. Start with the need. Choose the technology last.

Sustainment belongs on the roadmap

A technology roadmap that lists only what the department wants to buy next is half a roadmap. The other half is what the department already owns and has to keep running.

For every major technology in the department, someone should be able to answer the following without going looking. If nobody can, the roadmap is a wish list rather than a plan.

What you should know about every system you own

  • Owner
  • Backup owner
  • Annual operating cost
  • Renewal date
  • Contract expiration
  • Hardware lifecycle
  • Support end date
  • Integration dependencies
  • Training requirement
  • Data-retention requirement
  • Replacement horizon

This does not need to be a large document. For most departments it is one table, reviewed once a year, and it turns budget season from an argument into arithmetic. It is also the single most useful thing to hand a successor.

Every system eventually leaves

Decommissioning should be part of lifecycle planning, not something discovered after a replacement contract is signed.

The end of a system is a project in its own right, and it is almost always run under time pressure by people who have already moved on to the replacement. Plan it while you are calm — ideally at the point you buy the thing — and revisit it whenever the replacement horizon moves.

Questions to answer before a system is retired

  • How will we export historical data?
  • What records must be retained?
  • Will we maintain read-only access?
  • What integrations need to be retired?
  • What accounts and credentials need to be revoked?
  • What hardware needs secure disposal?
  • When does the old contract actually end?
  • Who confirms the old system is no longer being relied upon?

A system is not decommissioned when the replacement goes live. It is decommissioned when the contract has ended, the records are retained where they belong, and the accounts are gone.

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

Start here

If you read one thing on this subject, read this.

Go deeper

Questions to ask your vendor

  1. What worked, and what would we do differently?
  2. What gaps did this project reveal?
  3. What does this system now depend on?
  4. When does it need replacing, and is that budgeted?
  5. What integration should come next?
  6. What are our three-year priorities now?