Do you have the majority of incidents being caused as a result of project or other releases into production?
Do you often have a 'Bad Feeling' about a changes that are going in?
Thats right, the dreaded RISK word. In most cases Risk analysis conjures up bad thoughts and ways to quickly address the risk tabs in the change record adequately enough to get the change approved. Maybe a quick 'cut & paste" from a similar change? I have seen this, been guilty of doing it, and seen many other poor practices in companies I have worked for and consulted with over the last 28 years in my career.
There are 3 main concerns here that are not being addressed adequately by change management in a large number of organisations, they are;
- Clear understanding and collaboration of Incidents that could occur as a result of the change.
- Clear understanding of the reasons WHY these incidents could occur.
- Lack of contingency planning to be able to deal with the incident quickly and effectively if it does occur.
Clear understanding and collaboration of Incidents that could occur as a result of the change.
What incidents could result during or as a result of this change or release? This question should be asked and answered by the change implementation team and some other key stakeholders (e.g. Project teams, SMEs, business etc) to ensure site knowledge, past experiences, SME experience and intuition is captured effectively. These incidents are the ultimate concern we are worried about e.g. 'Data Loss' or 'Critical Application X outage' etc.
This information is gained from past experience with similar changes or outages that have occurred, or maybe there are key defects, capacity/performance concerns, poor testing etc that people have a strong 'gut feel' about.
Clear understanding of the reasons WHY these incidents could occur.
It is all well and good to think of all the high probability incidents that could occur in the previous step, BUT don't stop there. You now need to understand what are the 'Likely Reasons' that these nasty incidents could occur in the first place as a result of this change. Using 'Data Loss' example from the previous step, maybe likely reasons for this could be things like 'data corruption during transfer', 'incomplete backups' etc.
Once you have the most probable likely reasons, you can the understand the 'Avoiding Actions' to take to prevent the incident occurring all
Lack of contingency planning to be able to deal with the incident quickly and effectively if it does occur.
Ok, so in the previous steps we have planned to stop the incident occurring. However, what happens if it occurs anyway? This is where most teams get caught up by not being ready to deal with the incident, or its effects, quickly and efficiently. Ask yourself, 'What actions do we need to plan for, or have ready, to deal with the incident and/or its effects if it does occur? Continuing with my example, these may be actions such as 'having a tested rollback plan' or 'key vendor/staff onsite ready to deal with it if it does happen,' etc.
I am sure you have seen many different risk approaches. The effective ones are ones that analyse a change, initiative, project or even simple support actions in a more granular way quickly and efficiently. No one wants to add more time to a change, right? That is why the approach above is mainly applied to high impact, legacy/dodgey apps/infrastructure, change teams with poor reputation and customer outage related changes. We have short, medium and longer analysis tools/approaches to do this very quickly and effectively depending on the analysis.
Let's face it, unless you can see into the future, Incidents will happen. But using tips and techniques like this WILL drastically reduce the chances of of them ocuring. If they do ocurr, you can be adequately equiped to deal with them quickly and reduce cost and reputation impact at the same time increasing your Change Sucess Statistics!
