No one likes process — well, maybe the pointy hairds do, but hopefully they’re not looking while you’re reading this. Anyway, everyone wants to minimize process. One way to do so is, when something comes up that dictates a change in process, to concentrate on modifying existing processes before adding new processes.
An example would be a hand off process I’ve been helping refine. One team writes features/modifies functionality for an automation process and the other is responsible for the management/operations of said automation. For whatever reason, the ancients dictated that the maintenance team must write the configuration files for the automation.
Hind sight is more probably like 20/120 when dealing with process
Obviously, it’s been a bumpy road any time there is a hand off between the maintenance team and the operations team. The short-sighted process that dictated the maintenance team must maintain configs resulted in a healthy dose of environment-related problems — files in different locations than anticipated, missing metadata in various places, etc.
After the two teams got fed up with bickering about who broke what the proposed solution was a “handoff checklist.” For whatever reason people default to adding documents when something goes all wonky. While it seems like an “easy” fix, man, that’s such a pain in the ass. To get a new document in place the teams must agree upon a strategy for where they should be stored, what format to use, how they will be maintained, who will maintain them, how to backfill for existing artifacts, and a whole bunch of other scenarios.
Avoid process-overload by modifying existing processes
That’s a lot of man hours and added frustration to fix the core issue: Operations should maintain the configuration. It’s their environment, it’s their automation process. By modifying the existing process (in this example, forcing poor ops to maintain the config) you can save a lot of energy.