There is a version of this story that sounds impressive and stops there. Five hundred plus locations. Eighteen months. Every desktop recalled and replaced. Not one missed cutover.

That version makes for a good sentence on a resume. It teaches nothing.

Here is the version that teaches something.

This happened during my Wall Street years, supporting five hundred plus branch locations serving 17,000 brokers and 9,000 sales assistants and back office operations personnel. The industry was Retail Brokerage (Finance). The discipline was not industry specific then, and it is not industry specific now. Every organization running a distributed operation faces the same governance problem, regardless of what it sells.

The Cadence

Weekend cutovers were not a scheduling preference. They were mandatory. Brokers had to be online and functioning the moment the market opened Monday morning. There was no acceptable version of a broker sitting at a dead terminal at 9:30 a.m. That single constraint, a market that opens on a fixed clock and does not wait for anyone's IT project, is what forced every other decision in this program.

Every week, for the better part of eighteen months, the same rhythm repeated across eight geographic locations at a time.

Friday: teams arrived on site. Saturday: the new architecture went in. Sunday: final checks, training for the local staff. Monday morning: movers pulled the old equipment from a centralized point, and the location was live on the new system. Trainers remained on staff for three days following cutover to assist brokers and sales assistants with any application problems they were experiencing.

Then the cycle started again at the next eight locations. Week after week. Five hundred plus times. Zero missed cutovers.

People who hear that number assume the story is about the weekend. It is not. The weekend was the easy part, by design. The real work happened months before anyone showed up with a truck.

What Nobody Sees

Three things had to be true long before a Friday ever arrived.

Roof rights. Satellite communication was a new technology, and it meant physical access to rooftops, which meant approvals from the township and the landlord at every single location. That negotiation started months ahead of the cutover date, location by location, because a denied roof rights request discovered on a Thursday is a program failure, not an inconvenience.

Cable pulls, done early. Every desktop at every location needed new cable. If that work happened on cutover weekend, cutover weekend would have been a coin flip. Instead, cable was pulled on ordinary weekends, weeks ahead of the actual cutover, so that by the time Friday arrived, the only thing left to do was the thing that had already been tested and proven. Cable from the satellite also had to be pulled through the building riser to the brokerage office floor, plus a lateral run to the technology server room, and all of it tested weeks before cutover.

Engineer allocation, sized deliberately. IBM's engineering bench was not infinite, and this was not the only program drawing from it. Eight locations per cycle was not an arbitrary number. It was the number that let the cutover proceed without starving other work that depended on the same people.

None of this shows up in a program status report that only tracks the weekend. All of it is the actual reason the weekend never failed.

And none of it was a one-person job. The onsite project manager gets remembered because that is the visible role, but a cutover of this kind only worked because home office, operations, the data centers, network, the vendors, and the help desks all knew the event was happening and scheduled their own people and systems accordingly. Every one of those functions had to be synchronized in advance, every single weekend, or the location that looked ready on paper would not actually be ready when the market opened Monday. Adding to the complexity, sixty-five other retail brokerage office projects were happening across that same calendar year, new office openings, closures, and modifications, and every one of them had to be integrated into the schedule, which meant coordinating with construction personnel on cutover weekends as well.

The Governance Lesson

Governance is not the moment of execution. Governance is the elimination of every undecided variable before execution begins.

By the time a location's Friday arrived, there was no open question left to resolve. Access was secured. Cable was in place. The right number of the right people were available and not needed anywhere else. The weekend that looked flawless from the outside was, by design, almost boring on the inside. That is what good governance produces. Not drama survived, but drama prevented.

Decades later, I carried the same discipline into a very different arena. As the DHS OCIO/CISA representative to OMB's Federal Acquisition Security Council, I sat inside the body that coordinates supply chain risk decisions across the civilian federal enterprise, the same four-party logic now written into policy under EO 14306: CIO, Contracting Officer, Engineering, and the Business Unit, each with a defined seat before a decision is made, not after something goes wrong. I saw the same principle again on GSA's Section 889 Prohibited Equipment Committee and in contributing to the NIST SP 800-161 supply chain risk management rewrite. Different rooms, different decades, different threat. Same rule: authority has to be assigned and exercised before the pressure arrives, not during it.

Not Just the Rollout, Every Week After

The rollout ended after eighteen months. The discipline did not.

Every subsequent upgrade, every technology change, every piece of maintenance to that environment was scheduled for a weekend, without exception. The reasoning was the same reasoning that governed the original cutovers: a broker had to have full trading capability every single business day, and no change, however routine it seemed to the engineering team, was worth the risk of that not being true on a Tuesday morning.

That meant sustainment was never just an engineering calendar problem. Every change management weekend required the same coordination as the original build: the branch office, the brokers, the sales assistants, and building management, confirming access and readiness in advance, every time. Not for the big rollout. For the routine patch, the equipment swap, the software update. Always. Every other stakeholder was aware of the change as well, the help desk, the data center, network and operations staff, and the vendors, all of them knew what was happening and stood ready for whatever the change might affect.

That is the part people miss when they think about governance as something you establish once. Governance that only holds during the signature project and quietly disappears during ordinary maintenance is not governance. It is a one-time performance. The standard here was that the same rigor applied to a Tuesday patch as applied to the original 500-location build, because the risk to a working broker was identical either way.

The AI-Era Parallel

Every organization deploying AI systems today is living through its own version of the roof rights problem, whether it recognizes it yet or not.

The dependency is no longer a landlord or a township. It is a vendor's model update cycle, a data pipeline someone else controls, an approval chain for a system that makes decisions faster than any human review process was built to handle. The organizations that will avoid a very public failure are the ones treating those dependencies the way we treated roof rights: negotiated, secured, and resolved long before the system goes live, not discovered the week something breaks.

The technology changes. The governance discipline required to deploy it safely does not.

Where This Leads

Governance, Authority, and Relationships is the first pillar in the IT Risk and Cybersecurity Governance Framework for a reason. Every other pillar, from risk classification to incident response, assumes that someone with real authority already made the decisions those pillars depend on. Take governance out, and the rest of the Framework is a set of good intentions with no one accountable for enforcing them.

That is the discipline this series will keep coming back to, pillar by pillar. It started on rooftops and cable runs across five hundred locations. It shows up today in federal procurement committees and it will show up tomorrow in how organizations govern the AI systems they are racing to deploy.

​

This is the first article in a series exploring the eight pillars of the IT Risk and Cybersecurity Governance Framework. Read more about the Framework and the Governance and Authority pillar at MVWConsultants.com.