Working for the US government can be a beautiful thing, especially if you manage to land a good position, like Sr. Developer or President. Even if you're a contractor, government jobs tend to pay well and are good for the resume. Like any organization, though, there are a lot of policies and procedures that need to be followed.

T. C. is a contractor working for the government on a systems monitoring product. As part of a migration, he needed to move his system and get a new IP address for it. To get things going, he had to follow the standard procedure.

Day 1
First, T. C. had to download the change request template, assess, and write up the change so the board can approve the request to move the computer. Then he went through a pre-submission review with his boss, making revisions as they went.

After the pre-submission review came the actual submission. T. C. met with the board members to discuss the change, and to get it granted or denied.

Day 2-8
Success! Approval for the change was granted. Now T. C. was crusing on easy street! Except that now he had to assemble a group of stakeholders, then schedule a meeting that everyone could make it to. They'd discuss everything needed for the move.

Day 9-22
Several stakeholder meetings were held before a decision was reached. Finally, a task list was assembled. The server would be moved, it'd get a new IP address, and a handful of firewall ports would be opened. Getting everyone in the stakeholder group in one room at the same time was always a challenge, so it took two weeks.

Day 23-36
T. C. was then responsible for finding someone in the documentation group and having them write up the changes. He acted as the liason between the stakeholders and the documentation group, which was frustrating because the documentation group kept screwing up changes. For two weeks, they had a back-and-forth going with changes to the documents (it's a slow group).

Day 27-40
Once the documentation was ready, T. C. had to hand things off to the project manager, who was then responsible for putting the plan into action. For two weeks, they talked frequently, though T. C. had the suspicion that the PM wasn't actually doing anything. He swore he was working, though.

Day 41-53
After those two weeks, the project manager asked T. C. for status report. Of what he was supposed to be working on. T. C. reminded the PM that it's his responsibility now. The same day, the regional manager checked with T. C., asking when the move would be done. T. C. explained that he has no idea; the project manager was supposed to be doing it.

Day 54
The project manager then asked T. C. for another status report. Of what he was still supposed to be working on. T. C. resubmitted the same information he has at least a dozen times already, this time in Excel because the PM apparently couldn't figure out the Word or Visio documents he'd sent before.

Day 55
And the final, most important step; T. C. submitted this story to WorseThanFailure.com (30 minutes. (Thanks, by the way! -ed.)).

The good news is that the move finally happened. It took three more weeks for the datacenter to document and approve the request (then T. C. about an hour to carry out the task). Still, proudly standing in front of a "Mission Accomplished" banner in the server room made it all worth it in the end.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!