Running a technology needs assessment
How to establish what problem you are solving before anyone shows you a demonstration, and how to write it down so it survives a change of chief.
Assess, procure, implement, and make it stick
The management work around a technology purchase, which is where most fire service technology projects actually fail. None of this is about the product.
How to establish what problem you are solving before anyone shows you a demonstration, and how to write it down so it survives a change of chief.
Sequencing purchases so each one builds on the last, and so a grant cycle does not dictate your architecture.
Cooperative contracts, RFP language that protects you, data ownership clauses, and the exit terms to insist on while you still have leverage.
Why the system that tested well fails on C shift, and what a realistic rollout looks like across a department that works around the clock.
Framing benefit in terms elected officials recognize, without overclaiming in ways that damage your credibility on the next request.
What you are actually exposed to, what your vendors are responsible for, and the handful of controls worth arguing for first.
This outline is public so it can be argued with before it is written. If something here is wrong, missing, or in the wrong order for how a department actually works, that is worth knowing now.
Send a note