Ask any project manager (PM) what he hates the most about running projects and he’ll probably say “surprises.” So, for PMs, few things are more feared than the change request.
Whether a PM is managing development of a small application for internal use or enterprise software, change requests have the potential to wreak havoc on the schedule, budget, and quality of the finished product. Of course, these dreaded requests cannot be avoided, but how does a PM decide whether or not she should proceed with a proposed change?
Two words: impact analysis.
Impact analysis is the PM’s best friend because it ensures that change requests are considered with an eye on the “big picture.” It doesn’t alter the impact or the size of the changes, but it will reveal how long the change will take and/or how many bugs it could introduce into the code. Simply stated, an impact analysis eliminates (or at least greatly reduces) surprises. And that alone should make it every PM’s mantra. So say it with me, “Impact analysis. Impact analysis.” You should be feeling better already.
Here are some of the critical questions to ask during impact analysis:
Does this change conflict with an existing project requirement? If yes, why?
Do any of the proposed changes conflict with existing requirements?
Does the proposed change support the business case for undertaking the project? If not, what are the reasons for the change?
What are the potential ripple effects of the proposed change?
What are the modules, interfaces, files and other applications that are impacted?
Will the change introduce performance issues?
Does the change impact existing code or require the creation of new modules?
Does the change impact the database architecture of your application?
What areas of the application or system will need to be tested or re-tested because of this change?
What should those tests be?
Will the proposed change introduce user training issues?
Does the timing of this change impact the stability or scheduling of an upcoming release? If yes, how?
Is it realistic to make the change for the current release of the application?
Should the schedule change in order to include this change?
Is the cost of the change request too high because of the late timing in the schedule?
Does the change request impact any marketing or sales materials or activities?
If yes, can the marketing and sales groups absorb the impact of the change?
Since change requests are a normal part of any project, PMs should get very comfortable with impact analysis. Not only can it help avoid budget overruns, slipped schedule dates, and lost credibility, but it can also help eliminate those dreaded surprises.