I was talking to a project manager at one of my customers when we started talking about using ITIL based Release Management methods. e has several applications, some that interact and some independent but they that make up one service.
We were talking about developing a release policy for the service as a whole and how to apply that policy to each application that makes up the service. The proposed release policy is shown below.
We were talking about developing a release policy for the service as a whole and how to apply that policy to each application that makes up the service. The proposed release policy is shown below.
ITIL Change Management Process has three defined change types
and three defined categories
There is not always a one to one relationship between Release Management Types and Change Management Categories and this can lead to confusion
Let's take the case of an application rewrite for the purpose of cleaning up the code and making packaging and deployment more manageable. The functional specification and the user interface are unchanged. This is not a major release because the EU is not getting new capability but it is a major change because it carries high risk of something not working as before .
A minor release could be a significant change due to the business benefit.
The point being it is not a good idea to automatically brand a major release as a major change, a minor release a significant change and a break/fix release as a minor change. Just like in release management where there is a release policy, there needs to be a change policy and the two policies should have clear guidance of how they relate to each other.
R.
- Standard Change - usually pre-authorized, low risk and done frequently
- Emergency Change - a change that must occur immediately to remediate or prevent service impact
- Normal Change - Any change that does not meet the criteria of the other two
and three defined categories
- Major - High risk or positive business impact
- Significant - Moderate risk or business impact
- Minor - Low risk or business impact
There is not always a one to one relationship between Release Management Types and Change Management Categories and this can lead to confusion
Let's take the case of an application rewrite for the purpose of cleaning up the code and making packaging and deployment more manageable. The functional specification and the user interface are unchanged. This is not a major release because the EU is not getting new capability but it is a major change because it carries high risk of something not working as before .
A minor release could be a significant change due to the business benefit.
The point being it is not a good idea to automatically brand a major release as a major change, a minor release a significant change and a break/fix release as a minor change. Just like in release management where there is a release policy, there needs to be a change policy and the two policies should have clear guidance of how they relate to each other.
R.