An Impact Assessment is a systematic approach that seeks to discover possible risks associated with change.
When properly performed, an impact assessment is a critical input to organizational risk management and risk mitigation strategies. It is a key aspect of responsible requirements management, as it examines the proposed change to identify the elements that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change.
As a result, it provides an accurate understanding of the implications of a proposed change, and helps teams make informed business decisions about prioritization and sequencing of changes.
Unfortunately, more often than not, most “impact assessments” consist of emailing around an RFC (request for change) and waiting for someone to comment or speak up about it, or worse, a lead tech working in isolation on “one little change”
Another scenario often observed in practice is a meeting, usually a day or two before the change is to occur, where department heads talk about the upcoming work.
Most failed changes are simply the result of not taking into account current activities, and a failure to communicate anticipated activities. This includes any situation which proposes to alter system configurations, operating practices, policies, procedures, and/or any activities to be performed and which diverge from the norm.
Gartner and others have documented that about 80% of all IT incidents occur because of failed change management activities. To avoid adding to this statistic, leverage existing models for performing impact assessment:
Step 1: Understand the possible implications of making the change: Will there be any ripple effect into upstream or downstream processes or systems? Is there any risk of reducing product performance to unacceptable levels?
Step 2: What are the key differences between the “before” and “after”? Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change: Is traceability data available and reviewed? Are the process(es) documented? What features and key functionality needs to be tested / re-tested once the change is in place?
Step 3: Develop the plan:
◊ Identify the tasks required to implement the change
◊ Estimate the effort needed to complete those tasks
◊ Secure the resources required to execute the tasks
◊ Define the extent of the change proposed:
- Scope (explicit In & Out of Scope statements)
- Work environment (stakeholders impacted)
- Technical environment (systems impacted)
- Determine key differences in the future state (proposed) from a point of reference or the original state; common differences can be grouped as:
- Hardware and software models, versions, platforms, etc.
- Staff, personnel, vendor, and support persons, etc.
- Process, procedures, organization, schedules, time of day, etc.
- Environment, location, installation, etc.
- Focus on the possible effects of the key differences from step #2, and for each potential effect, list out what you can do to prevent, monitor, and detect it
This forms the basis of the impact assessment.
Next, sort and prioritize the possible effects based on the key differences, looking at risk and probability of occurrence, while also taking into account the effort and cost.
The deliverable of the impact assessment is a list of recommendations, with pros and cons, presenting what is currently happening, what might happen, and ways to avoid and mitigate risk and negative outcomes. All that remains is to make a decision using the results, based on your specific business’ tolerance profile.
Word of CAUTION: While following this framework significantly reduces organizational risk, the results will only be as good as the knowledge and skills of the people performing the assessment