If you’ve been working in the software development field for years (like me), for sure you have done some kind of impact analysis at least once among the projects that you have worked on. Maybe you were not just aware but actually what you were doing is a form of impact analysis.
How do you define Impact Analysis?
Impact Analysis is the technique of analyzing how a new / or a modification of a functionality would affect the current business process as a whole.
I’m trying to define it here using my own words, on how I understood the concept. If you are trying to research the “technically correct” definition, then I guess my blog is not 100% reliable on that. 🙂
This is commonly done during a start of a project wherein the team is in the stage of analyzing the complexity of a project implementation.
I have recently done impact analysis on a project I am working on and here are some of the key points that I watched out in constructing my investigation.
Since I am (as of this writing) a NetSuite developer, mostly my concern of the impact analysis is on the records/scripts level. I should be able to pinpoint —
- How the changes would affect the new records and the flow on how users interact with them (CRUD operations)
- How it will affect existing records (CRUD also)
- How it will indirectly affect other records (i.e. parent/child records, sourced fields, saved searches via the delete/inactivate dependencies list)
- How it will affect other scripts; compare if there would be conflicting logic flows compared to the other existing scripts
Then I evaluate these points based on how critical the effect would be on the overrall process — high, medium, or low. Take note that when presenting this to the team (BA, QA, and the management), you have to make sure that you are using the same terminologies (i.e. how impact is being measured — S1-5 or U1-7).
Doing impact analysis is an extremely important step before starting the projects. Aside from seeing the changes in a high-level point of view, this approach also allows the team to do checking to ensure all existing functionalities would work as expected after a new feature implementation has been released to production.