Change control is important in day-to-day IT activities as well as in IT projects. Without suitable change-control policies in place, people aren't notified of changes that have taken place and things quickly get out of control. In IT projects, the scope begins to creep when changes are made that are not put through a rigorous change-management protocol first.
In this section, I talk about some elements of change control that will bring more successes to your efforts toward managing change.
The change-control process that you detail in your scope document must outline, at a minimum, the following components:
How to request a change Stakeholders, customers, and sponsors need to know how they can go about requesting a change in scope. You could use a small intranet site for tracking your project and including a place for change requests. There are many good, easy-to-use website development software programs that you can use to formulate a site for tracking your projects.
How to analyze the impact of the requested change This section could present some interesting problems to deal with. Most probably you' l l just use a common-sense method to assess and analyze how the requested change will affect the project. The customer, stakeholder, or sponsor requesting the change may have no idea of the large impact the change may have on the scope. It ' s up to you to make wise, logical decisions about such things as:
■ The value of the change
■ What the change implies in terms of extra project resources or time
■ How these balance with other aspects of the project, such as its budget and priority
How to gain approval for the additional funds and/or time required to implement the change So you' ve reviewed this change and found it to be worthy. Part of the problem with scope changes is that they often require additional funding, resources, or time—none of which may be readily available. Your change-management profile shouldn' t necessarily say how you're going to gain approval; instead, perhaps you should make the additional resources or time a mandatory component of the change request. In other words, the safe (and effective) thing may be to leave the impetus of gaining time and/or resources up to the individuals requesting the changes.
Conversely, on bigger projects, you may find that the change is merited but that the entity requesting the change cannot provide the resources or time needed to implement it. Your change-management paradigm should provide instructions that say, "This is the approval process we ' l l go through if we find a change to be deserving of implementation."
While this all sounds very straightforward, changes to a project can be very difficult to manage. On the one hand, you may have a need for a change that makes sense, while on the other hand you could be under the gun in terms of the project ' s original resources and timelines. Your policy should be prepared to delegate some of these decisions and evaluations if the PM is not present or doesn ' t have the technical expertise to weigh them.
Some changes make absolute sense and should be integrated immediately. Dor example, you ' re working along on a project and one of the development engineers finds a significant security loophole in the code you' re developing. The change to fix the loophole will take an additional 80 hours of coding time. This is a no-brainer (but one that nevertheless must still be run through the change-management process). Other changes require more consideration. For example, a cosmetic change to a GUI interface may have questionable merit and might adversely impact the project ' s timelines.
Was this article helpful?