Step 3 of the Comprehensive Software Assessment Process
This posting is the third in a series on Impact Assessment. In previous postings, we looked at Change Definition and outlined a broad activity in which we seek to describe every aspect of a proposed change, from who is making the request to the anticipated business value. Then we looked at Identify Key Differences, taking a deep dive into the elements of our systems and comparing before and after images of our infrastructure and operations to articulate what will be different and what those differences will be.
In the Focus on Effects step we turn our attention to things that might go wrong with our change project. While no amount of planning can ensure that every step of a project goes off without a hitch, a proper risk analysis can give you a framework that helps to head off problems and minimize the impact of any problems that do arise. In this step, we’ll systematically review each of the key differences, documenting risks associated with those differences and what the overall effect would be should those risks become realized.
The Risk Register
The risks that are documented by the team are maintained in a risk register. While risk registers come in various forms, from basic spreadsheets to full-featured dedicated applications, they generally appear as a table where every risk is listed in a row, with columns to capture key pieces of relevant information such as the description of the risk, the type of risk, the magnitude of the risk, potential mitigation, and the likelihood of the risk will be realized. Pictured below is a simplified example of a risk register.
Sources of Risk Data
As you work to identify project risks, it is important that you incorporate as many information sources as possible. Risk identification is part art and part science, and having multiple perspectives will help to ensure that you don’t overlook critical risks in your assessment. Some of the possible sources of risk information include:
Project Documentation: The listing of key differences developed earlier in the assessment will be your starting point, but you will also want to review other major project documents such as the statement of work, work breakdown structure, and schedule.
Risk Assessment Checklists: Checklists are excellent, frequently overlooked, and resource for risk analysis. Checklists generally present a series of subject matter checkpoint questions for the analyst to work through, with different checklists focusing on different areas of potential risk, such as business impact, process-related, or cyber-security.
Risk Repository: Your organization will hopefully maintain a shared record of prior impact assessment activities as well as lessons learned from past projects. Reviewing this historical information can provide insight into potential problems on your current project with the added value of reflecting your own team’s unique experiences.
Expert Review: Brainstorming work sessions with the project team and other experts from your organization can help reveal subtle project risks that might otherwise go undetected. Developers are often able to identify sticking points in the process such as the application of new and untested technology or potential scope creep. To be effective, such work sessions must be conducted in a collaborative environment where team members are comfortable expressing personal concerns and challenging others’ assumptions.
The ultimate assessment, or risk score, of each identified risk is an evaluation of the likelihood of the risk event occurring balanced against the potential impact of the risk. Simply put, an event that would cause substantial harm to the organization and that you and the project team consider very likely to occur is a greater threat than an event that is unlikely to occur and would cause minimal harm even if it did.
While a risk score is a quantitative, numeric value, the assessment process typically begins with qualitative, verbal descriptions. For example, the magnitude (or severity) of a risk is usually described verbally using a pre-established scale such as very small, small, medium, large and very large. This severity description is then converted to a number for the purposes of calculation. In this example case, very small might equal 1, small equal 2, etc.
Similarly, the likelihood of the event occurring could be first considered verbally as very unlikely, unlikely, likely, and very likely. These verbal evaluations would then be converted to a number, frequently expressed as a percentage.
The Panoptics Difference
Crosscode Panoptics’ industry-leading discovery and code-level dependency mapping capabilities will significantly improve your ability to identify and mitigate risks when preparing for software change projects. Our unique algorithms dig deeper into your infrastructure than any other solution to reveal dependencies and applications that others will miss - including critical third party and open source components.
Panoptics’ gives you the ability to analyze and assess risks to development and change projects as a function of the number of dependencies, and therefore the applications and databases, that will be affected by any proposed change. You can see at a glance how these changes will propagate through your infrastructure and take steps to reduce the likelihood and potential impact of developmental defects and unintended consequences.
If your responsibilities include conducting impact assessments for complex software and infrastructure change projects, contact us today for a personalized demonstration and let us show you how Crosscode Panoptics can save you time and money while driving down risk and improving your estimates.