Managing Change in a Project


A documented and functional change control methodology is crucial to project success because so much change is inevitable, particularly in a complex, developing, and evolving IT project.

There are two categories or types of changes the project team and organization need to be aware of and track closely. The first are those changes that the customer initiates as she evaluates the needs. These kind of changes occur because the project requirements were not clear at the start, the technology changes, or the need changes because of market considerations. Sometimes, particularly with new technology or developing technology, it simply is not possible to completely define the project until some design work or prototyping is completed. Whatever the reasons, these kinds of changes constitute changes to the scope and must be accomplished with a change to the contract or, with an internal customer, a formal memorandum of understanding. The reason for a formal change procedure is that most scope changes will impact the budget, the schedule, or both. This category of change should be spelled out in the contract documents and enforced. Otherwise, the project is doomed to suffer scope creep, that is, adding additional tasks onto the project without consideration for the extra costs and schedule time required.

The second category of changes occurs within the project as it develops. These changes are usually those that become evident enhancements, as more of the design and development is understood. They may, or may not, constitute scope changes. This type of change is internal to the project and the organization but, ultimately, requires the customer's consent before implementation.

There needs to be a formalized process for change management that the project team, and all functional personnel, understand and follow because anyone can recommend a product change. Consequently, without a standard change procedure, the project would collapse in chaos. A sample change control procedure is shown in Exhibit 9-7.

Exhibit 9-7: A sample change control process.

start example

click to expand

end example

All change requests or recommendations must be directed to the project manager so that they can be tracked, documented, and acted upon. Many organizations authorize their project managers to approve recommended or suggested changes, provided the changes do not impact the budget, schedule, or product performance—that is, no scope impacts. Even then, the project manager actually does not institute the changes without obtaining the customer's approval first.

All potential changes that exceed the project manager's authority are passed on to a change (or configuration) control board (CCB). The CCB is usually a group of three to five members whose function it is evaluate change requests, their viability, and the impact to the project scope. The group usually meets on an ad hoc basis, that is, as needed, but in cases where rapidly or often changing projects are the norm, the CCB may be a standing committee meeting on a regular basis, perhaps once per week.

Changes are recommended by submitting a form describing the change, its impact to the project, how much it will cost in terms of budget and schedule, and its benefits to the product. These changes are not necessarily changes that enhance the product and add to cost and schedule; one can also recommend the elimination of functions, which can substantially reduce both cost and schedule. Exhibit 9-8 shows a sample change request format.

Exhibit 9-8: A sample change request form.

start example

click to expand

end example

Once a change is approved, the project manager's designated configuration management specialist must document the changes and update the project specifications. In large contracts, the configuration management process is very elaborate and very detailed, with each change documented, numbered with a configuration item number, and logged. The configuration management position is so important that it has become a separate labor category and is considered to be a specialist function.

After the change is approved and the files are updated, the project baseline is updated, the changes are published, and all stakeholders are informed of the changes. Changes to the baseline often—in fact, usually—require a change to the contract. No project changes should ever be approved without an attendant change to the contract.

Even if the customer decides to change the baseline configuration and it is determined that there is no impact on the budget or schedule, a no-cost contract modification should be requested by the project manager. Usually the customer will automatically issue one, but the experienced project manager will always insist on having the modification prior to instituting the changes. These contract modifications are necessary because one of the actions at project completion is to determine whether the goals, objectives, and specifications have been met. Without a contract modification, there is no way to track whether or why a change was made.




Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net