Designed originally for JEA while at Coleman Technologies in 1999, brought to the City in 2005 as the enterprise change standard, and handed to operations to run in 2012.
The handover is the part worth stating. A process still owned by its author is not yet a standard — it is a habit with one person maintaining it, and it ends when they move on. Giving it to the people who run change every day is what turned it into something the organization owned, and it is the reason the next paragraph is possible at all.
The city eventually bought a commercial tool to do what the process already defined, which is the right order: the process was proven first and the product was fitted to it, rather than an organization adopting a vendor’s workflow and calling that governance. The Computer Associates platform was later succeeded by ServiceNow.
The process outlasted both, a decade after it left my hands, and that is the whole claim. A change process that dies with its tooling was never a process — it was a product configuration with a policy document stapled to it. This one was written down independently of any platform, which is why two migrations were tool migrations rather than governance rewrites.
Why it sits under automation
Change control and automation are the same discipline seen from two ends. Automation multiplies the blast radius of a mistake: a bad change made by hand affects one device, and the same change made by a pipeline affects every device it reaches, in the time it takes to run. That means automation requires more governance than manual work, not less — and it means the people holding the keys have to understand what a bad change costs before they are given a tool that makes changes fast.
Every cutover, revision-controlled design and back-out plan elsewhere in this record ran against this standard.
Outcome
A process proven first and fitted with a product second, which is the order that survives a platform change.