Every company has its set of idiosyncrasies like oddities in work decor or strange holidays or seemingly backwards business practices. When these occur at my firm I’ve taken to saying “Welcome to <firm name>”.
For the last few days, a coworker and myself have been testing a patch to our CAD system to bring back a piece of functionality lost during an update. The functionality is non-trivial and involves CAD documents remembering their parameters. It would be analogous to a document that whenever you opened it all the formatting went away in addition to the information like when it was created and by whom. After doing a bunch of testing, the patch appeared to function correctly and we got ready to deploy the fix across our servers.
Me: I’m applying the patch to our development server.
Boss: Whoa, you can’t just change the CAD system.
Me: But this is the dev system. I thought we just had to document changes to our production server.
Boss: Nope, since the dev system receives changes that may eventually reach the production server those changes have to be documented too.
Me: Then, do we have a sandbox that we can just mess around with?
Boss: Yeah, we have a copy of the development server that runs as a virtual machine that we wipe each week. You can make any changes you want as long as you document it.
–Later–
Me: Ok, I’ve documented the change on the development server and I’m ready to roll it out to the production server.
Boss: You can’t just change the production server, you need to submit a business justification.
Me: I need to submit a business justification?
Boss: Outline costs, how it will change our operations, any training required. Yep, tell me when it’s done.
So, I need to write a justification, to get permission to apply a patch that’ll make our non-functioning system functional. That’s like requiring a business justification to turn on a piece of manufacturing equipment. I wonder if I should include the cost of doing the business justification in my business justification.
Welcome to <firm name>.