There’s a lot more data that’s now available that lends itself to a more policy-based approach or automation of the change process itself.” … Users have to go into the change management tool, log in a ticket, provide information about the change, fill out a multi-question form, and then wait for a change approval board to review the changes. “If all the information has been provided, then the CAB can go ahead and approve it; otherwise, there’s a back and forth in terms of the data that needs to be provided — things like test results, or was there any adverse performance impact because of that change,” … Once that is done, the policy model can be created for automatic approval of changes. If changes are for non-revenue-generating applications, or if regression tests pass, when the changes fall into categories such as those, the system should be able to automatically approve them, freeing up people to focus on the more high-risk changes that do require more in-depth analysis and understanding before they can be approved. SD Times, November 14, 2018, Service management dragging down DevOps. Image: it.sheridancollege.ca

I didn’t call the normal change review meetings for the project. Instead, I had reviewed the many requests we had and then published about a half dozen business rules to the teams. If the request fell under one of these rules then it was automatically approved. Just submit the change and reference the rule that the change fell under. Done.

See you may need business rules not meetings

Having a policy and a few rules trumped having the normal meetings or any level of automating the meeting based approval method. While I really love automation, the business rules and the analysis that developed the rules was the real secret to our success at accelerating this process. Automating a bad decision-making meeting process rarely improved anything.

Are you automating a bad process that could better be improved by a thoughtful policy or by business rules?