Managing Changes
Changes are inevitable. A set of procedures for the tracking and control of changes is the final essential mechanism for the management of project scope. Ramsaur and Smith propose that, as a matter of principle, changes should be kept to a minimum on a project.[81] This is a debatable principle, since the incorporation of changes may be crucial to project success and may be the correct decision in the client's business interest. The operative management policy, perhaps, should be to minimize the disruptive impact of changes through early identification and thorough evaluation before implementation, as Ramsaur and Smith themselves recommend.
McCoy's first commandment of baseline management is that change does not just happen; it happens by permission.[82] Thus, project management has a duty to be in control of changes.
Bellows and Osborne, in their description of a management plan for a nuclear waste isolation pilot plant project, were concerned with the risk that the project could fail if changes aimed at project improvement became so costly or numerous that pursuing them would consume all of the project's resources. To counter the risk, they established a set of seven criteria that defined the conditions under which a change request would be entertained. If the criteria were not met, a proposed baseline change would be rejected out of hand as a matter of project policy.[83]
A change means any amendment to a baseline that has previously been authorized or frozen. Smythe emphasizes that a clear distinction must be made between scope changes and design changes.[84] Scope changes are amendments to the requirements statement and represent a change in project objectives. A change in scope is grounds for an accompanying change in deadlines and budgets. A design change, on the other hand, is a modification to the planned configuration of the end product needed to produce a workable result. For a design change called an "internal scope change" in some organizations the client should not be expected to provide additional funding or an extension of time.
The authority to accept or approve a change must be the same authority that established the baseline in the first place. Thus, scope changes require the approval of the sponsor. Smythe advises that the request for a scope change, typically initiated by a user, should be stated in writing, and that no action should be taken to implement the change without written approval from the client. The client's approval, in turn, should be granted only with a knowledge of the cost and schedule impacts.[85] McCoy offers, as a project commandment, the rule that consistency among the cost, schedule, and scope baselines must always be maintained.[86] Thus, the authorization for a scope change must be accompanied by the approval of commensurate budget and target date changes.
Design changes are typically proposed by members of the project team, either to overcome a problem or to respond to new knowledge about the project environment. Conditions that give rise to design changes include errors, omissions, or incorrect assumptions in the design; or unexpected field conditions, procurement difficulties, or new technology. The project manager and the panel of team members that authorized the design baselines affected by a change are the authority for acceptance. Again, the impacts of a potential change, both on configuration and on cost and schedule, should be analyzed prior to the decision to accept or reject.
The information system and administrative procedures required to support change control on a project should provide for the following, in addition to the review and approval mechanisms described above:
- The early detection and communication of potential changes so that all team members are alerted to them, and so that responsibility may be assigned for analyzing and implementing the changes.
- The incorporation of the changes in all affected baselines in a timely fashion, so that all team members work to a uniform set of requirements and specifications.[87]
The writer has observed a marked absence of forms, procedures, and flow charts that describe change control mechanisms in the general literature of project management. The most promising source of such information and experience appears to be in the literature on configuration management.[88] Randall, et al., provide a reasonably detailed description of the change control procedures they employed for the design and construction of multi unit, nuclear power plants.[89]
81. Ramsaur, W.F, and Smith, J.D. Project Management Systems Tailored for Selected Project Management Approach. Proceedings of the 1978 Seminar/Symposium. Drexel Hill, PA: The Project Management Institute, 1978, pIV A.1
82. McCoy, F.A. Measuring Success. Establishing and Maintaining a Baseline. Proceedings of the 1986 Seminar/Symposium Drexel Hill, PA: The Project Management Institute, 1986, p49
83. Bellows, J.L. and Osborn, S.L. The Development of the Project Management Plan. Proceedings of the 1980 Seminar Symposium Drexel Hill, PA: The Project Management Institute, 1980, ppIII B.l. 6-7
84. Smythe, E.B. The Project Management Process Copies of overhead transparencies used in a seminar, Vancouver, B.C.: Executive Programs, the University of British Columbia, 1981, pp53-56
85. Ibid, p54
86. McCoy, F.A. Measuring Success. Establishing and Maintaining a Baseline. Proceedings of the 1986 Seminar/Symposium Drexel Hill, PA: The Project Management Institute, 1986, p49
87. Ibid.
88. Stephanou, M.S., and Obradovitch, M.M. Project Management Systems and Development and Productivity. Malibu, CA: Daniel Spencer Publishers, 1985, pp313-319
89. Randall, E., Boddeker, C., McGugin, H., Strother, E., and Waggoner, G. Controlling Engineering Project Changes for Multi unit, Multi site Standardized Nuclear Power Plants. Proceedings of the 1977 Seminar/Symposium Drexel Hill, PA: The Project Management Institute, 1977, p265
|
Design
Reviews 
