War Stories: Closing out Projects
This article is Part 10 in a 12-Part Series.
- Part 1 - War Stories: Loops that Permanently Broke the Network
- Part 2 - War Stories: Switches Lying about Duplex Mismatches
- Part 3 - War Stories: Check Point Meltdown
- Part 4 - War Stories: Dual-Vendor Firewall Strategy
- Part 5 - War Stories: Proxy ARP Auto-Configuration
- Part 6 - War Stories: Gratuitous ARP and VRRP
- Part 7 - War Stories: Cursed VLANs
- Part 8 - War Stories: Unix Security
- Part 9 - War Stories: ITIL Process vs Practice
- Part 10 - This Article
- Part 11 - War Stories: Backup NICs, DNS and AD
- Part 12 - War Stories: Always Check Your Inputs
We put a lot of energy into new projects. We argue about the design, we plan the cutover, we execute it…and then we move on. But decommissioning the old system is critical part of any project. It’s not over until you’ve switched off the old system.
Years ago I was involved in the buildout of a new network. The new network was a thing of beauty. A clear design, the best equipment, redundant everything. It was replacing a legacy network, one that had grown organically.
The new network was built out. Late one night the key services were cut over, and things were looking good. Everyone was happy, and we had a big party to celebrate. The project group disbanded, and everyone moved on to other things. Since the project was closed out, funding & resources stopped. Success, right?
Except…the old equipment was still running. A handful of applications were left on the old network. Some annoying services used undocumented links between the networks. Even worse, disused WAN links were still in place, and still being billed for.
The problem was that the project was officially ‘over.’ Who’s responsible for finishing off that last bit of cleanup?
I’ve seen similar things in different organisations. The worst case was where they had the ‘new’ environment, the previous one, and buried in a corner, the first one they ever built. The old ones were still trucking along, with a handful of customers left on each.
This is another form of technical debt. In this case it also has clear financial implications. The original financial model for the project would have included cost savings from reduced support costs, etc. It would definitely have assumed that we wouldn’t be running two networks at once. But if we’re still running all the old gear too, will there actually be any cost savings?
Yet this often gets forgotten about. No-one goes back a year later and checks “Did that project actually deliver the savings we thought it would?” The old stuff keeps trucking along, and no-one cleans it up.
In this case I found the time to rip out all the old gear. It was about 12 months after the “official” project close-out when I finally finished. I wanted to send out a “Project is complete!” email, but the boss told me it might not be a good idea politically. Seems that people don’t like to be reminded that they hadn’t actually finished the job.
The project isn’t over when the new system goes live. It’s over when you’ve finally unplugged the old gear.