A second complaint from my students (see yesterday’s post) is: “Management adds requirements to my project without asking me if I can still make the schedule and without taking anything away. All the time.”
Of course, what’s “bad” about this behavior is not that requirements change: that’s expected: although there must be a limit. What’s “bad” is making the changes without a change management process.
So, in class, first we’ll discuss the benefits of a change management process, from their (Engineering’s) point of view:
· Allows impact to be assessed
· Allows effort estimates and schedules to be adjusted
· Provides a way to track cumulative impact of all changes, including all the little ones
· Provides an opportunity to negotiate requirement trade-offs to try to preserve the schedule
But, like I said before, it doesn’t do any good to sell Engineering on the benefits of process only to have Management say there’s no time or budget to put them in place, or to ignore them when they are in place. We have to sell the benefits of change management to Management and get them to respect the process once it’s in place. Here’s a start (I’m sure you can think of some of your own):
· Giving Engineering the time to think about the impacts of each change, as well as to provide a well-considered new estimate, will strengthen Engineering’s commitment to the new schedule. Otherwise, if changes are piled upon changes, Engineering will stop feeling that their schedule has any basis in reality, is garbage, and deserves to be ignored. It is a way to keep Engineering’s buy-in.
· Constant, small changes can sink a project (and you can show them how). Why would they want the project to fail? It’s not in their interest to promote “scope creep”. A change management process is a way of keeping track of the changes so that things don’t spiral out of control. It is a way for Management to maintain control of the project.
· A change management process includes updates to the written requirements, and since the written requirements will form the basis for the tests, Management can be confident that the testing will be complete, and there will be no surprises when the product gets to the customers. How else can Management be sure that everything was tested?
Management must be convinced that sneaking in changes without a process, without allowing Engineering to evaluate, estimate, or negotiate them, is not a Management strategy. It’s a death sentence for the project. And once they’re convinced, maybe they’ll think a change management process was their own idea: .
Anita Wotiz
www.duckpondsoftware.com
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering (next class Aug 2008)
Software Project Planning, Monitoring, and Management(next class Nov 2008)
