What does a Change really want?
I must admit I was stumped the other day, when a customer asked me that questions in frustration at their attempts to implement a Change process.Of course, a Change doesn't really actually want anything , but it certainly give me pause for thought to reflect on what Change is really about. Logic that ITIL suggests we take for granted.
To try and answer this question some more I thought I would consider some of the attributes of Change.
Top hits - the best and worst of Change
First, Changes are equal opportunity. Just like email, anyone with the right address can submit one. Unlike an email system there is no spam filter or junk folder. But by comparison, Facebook behaves very differently.Second, Changes are implemented in priority order. There is a time-based aspect of priority - typically a First In First Out (FIFO) process similar to Email. But care should be taken not just to implement the most recent Change request, so we should also consider an override mechanism allowing Changes to be prioritized based on business need - for example Critical, High, Medium and Low.
Third, requests for Change do not expire. This is quite different from timeline notifications such as Twitter, which assume that we won't read information that's no longer up to date. Unless the request has been cancelled, it should still be in the Backlog.
Fourth, Change requests provide a persistent record. This is very similar to an To Do list. All Changes should be logged. In this way, requests for Change should never get lost and will eventually get implemented once they reach the top of the queue.
The Lightning bolt of Change
The Change process should be considered a system. Much like an ERP system, we shouldn't allow ourselves to operate outside the system. Occasionally we have individuals who try to opt out, but it's a dangerous precedent to set if allowed.Changes shouldn't be implemented unless Approved. Assuming the right Approvals are in place, allowing a Change to proceed without approval is risking unexpected outcomes- mostly undesirable.
Separating Notifications from Approvals should clearly distinguish who needs to know about a Change from the teams that may be affected by the Change. Getting this right will streamline the Approvals, whilst ensuring that everyone that needs to know is aware.
Providing Change templates should make it very easy to submit regular requests, such as for a new server or increased disk space.Making it easy to submit common requests will increase adoption. Change templates can include the minimum level of approval for the request - reducing overhead on common, low risk requests.
Improved Automation coverage is a a side benefit of Change templates. With Templates we can track accurately how many such requests are made, and more easily identify the best candidates for Automation.
Closing Changes properly should include details on how long the Change took and whether it was completed successfully.With complete coverage of all Change requests and accurate data about outcomes Reporting provides more insight on the quantity and quality of work - which can improve the relationship with customers and highlight the benefits of initiatives such as Automation.
Staying in Control
Hopefully, none of this is dramatic news. Every system has a way it wants us to work. Twitter wants us to Tweet where we are and what we're doing. Facebook wants us Post status updates and Like each other. And Email, unless we're very careful, becomes a To Do list.
But the business expects more from us than occasional Tweets and Likes. We need to work with our counterparts to ensure that we're constantly pruning and prioritizing Change requests and finding new ways to deliver them faster.
This requires us to make deliberate choices that support the outcome implement Changes in the most efficient manner, while minimizing the negative impact on customers when Changes are implemented.
