Came up with this initial change assessment checklist for early identification of potential issues that must be taken care of.
The sparkle was a detected tendency that somehow inflicts change analysts to disregard planning and risk analysis. I found this in a customer that relies heavily on a subcontracted service provider for most of its service management activities.
As with all that has real value, it takes work and real thinking. A checklist can be helpful as a kickstarter.
- Does it need specific people in my organization?
- Does it need specific expertise not available in my organization?
- Is there a clear potential affected user list?
- What training for end users will be needed?
- What training for operational and administration level is required?
- Does it need multiple teams effort?
- Will it need specific resources (not people)?
- Does it include technology never used within our organization?
- Does it need additional testing, staging environments?
- Does it need specific licensing?
- Is it dependent on other changes?
- What is the scope of the change? Does it affect only one component or several?
- Is it possible to fully test the change?
- Is there a work-around available should things go wrong? If so does it need specific preparation and resources?
- Do we know what benefits it will bring?
- Does it have a clear business deadline?
- How critical are the affected services?
- What is the duration and scope of possible service disruption? Can the change be deployed within a scheduled maintenance window for services affected?
- Are there any special circumstances regarding this change?
I am working on testing this set (or a smaller one) on a customer.
Interested in how much meaningful analysis can really be performed early on a change life cycle and what the payoff will be.