<img alt="" src="https://secure.leadforensics.com/149263.png" style="display:none;">

Defining Change

Posted by Sam Wonderlich on Jul 23, 2019 11:05:03 AM

Defining Change

Step 1 of the Comprehensive Software Assessment Process

Defining the Change Thinking


This posting is the first in a series on Software Change Assessment.  In today’s rapid development environment, it is more important than ever that software development organizations follow a disciplined approach to change management that accurately identifies risks and estimates the level of effort required to accomplish software changes.  Define the Change is Step 1 of a five-step process that systematically brings your team from an initial change request to a final prioritization and goes/no-goes decision on the change.

With fully automated features for application discovery, code-level dependency mapping, and change assessment, our Crosscode Panaoptics solution supports a data-driven approach to change management that not only helps you conduct a more accurate analysis but can save you and your team months of work gathering and analyzing key data about your infrastructure.  Throughout this series, we will explore how Panaoptics can help you at every step of the journey.

In the change definition step of software change assessment, we consider all aspects of a proposed change to describe the systems and environments that will be affected and try to envision what will happen before, during and after the change.


There is a great deal of variety in the way that organizations approach change definition. Some organizations rely on a rigorous process that mandates specific data be documented – frequently on a Request for Change (RFC) template or similar change management form. Other organizations use a more free-form approach where the change requestor, project manager, or business analyst describes the change in a written narrative.

Regardless of how your organization structures its data collection for change definition, there are certain standards questions of who, what, when, where and how that a robust usable definition will address.

Defining_Change before , during, and after the change

Goal of the Change

Every change should be motivated by a clearly defined goal. A software change might improve workflow efficiency, address a flaw in the current solution, or introduce a new value-added capability or feature. The change definition should articulate what the organization hopes to accomplish and what business value is hoped to be realized by the change.

Magnitude of the Change

Defining_Change Risks of the Change

The magnitude of a software change is a function of both the complexity of the proposed change and the sheer volume of code and other changes. Larger projects not only demand a greater commitment of time and resources, but they also are inherently more challenging to estimate.

Scope of the Change

Many software changes will reach far beyond the software itself. Some changes involve new or modified hardware, changes in policies and procedures, or a new workflow. It is easy to forget a routine follow-on activity such as updating documentation or providing user training, so it is important to spend time working through the scope to capture as many implications of the change as possible.

Risks of the Change

Much of the information gathered during the Change Definition step will be expanded and refined throughout the impact assessment process. In particular, both the scope of the change and the risks of the change will become the focus of the analysis performed in Step 2: Identify Key Differences and Step 3: Focus on Effects. By bringing in the appropriate expertise early and taking the time to develop a comprehensive definition upfront, you can lay the foundation for a solid analysis down the line.Identifying the potential negative outcomes of a proposed change is perhaps the single most important element of the change management process. Project risks come in a wide variety of forms, from cost overruns due to poorly understood requirements to system outages caused by breakdowns among unknown software dependencies. It is only by systematically evaluating all risks and putting appropriate mitigation plans in place that the organization can move forward with confidence.


Defining Change Code-Level Change Assessment


Crosscode Panoptics software gives your development team the insight and understanding needed to support in-depth impact assessments. Panoptics’ change assessment features enable you to analyze the effect of any proposed system changes with a visually intuitive and easy-to-use tool that lets you see instantly how a proposed change will impact other applications and databases across the enterprise. Unique in the industry, Panoptics provides a mechanism to estimate the magnitude of a proposed change in terms of the number of methods that would be impacted by that change.

Panoptics’ application discovery and dependency mapping features are fully automatic, saving months of labor compiling the data for impact assessment. In upcoming posts in this series, we will continue to explore the impact assessment process and the many ways in which Crosscode Panoptics can save you time and money while driving down risk and improving your estimates. 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 the difference Panoptics can make.


Download this article for future use here.



Topics: Change Assessment