Managing Change

Change occurs whether we want it to or not. It is an inevitable part of life. In terms of managing a project we try to discourage it, but sooner or later we have to face the fact that changes have occurred or are about to occur. We therefore need a change management process to ensure that when changes do occur, they can be assimilated into the project baseline and will not cause the project to fail. Changes to the project baseline are not the only kind of change we should be concerned with, however. The project itself will bring changes to the organisation for which it is being commissioned. Hopefully these will be positive changes in the sense that it will provide long term benefits such as making the organisation more productive. Keep in mind, however, that organisational change is not always welcome. One of the tasks the project team should be prepared to embrace is that of persuading users of the positive aspects of the changes involved. Change can create anxiety, and may generate resistance if the ground is not carefully prepared in advance to ensure that the new product or system is not only a technical success but is accepted by users.

The kinds of changes that will have the most profound effect on the project baseline are changes to the project's scope, i.e. the set of deliverables that represent the end product or service to be produced. The client may decide, for example, that they require additional features or functionality. This can often occur as the client becomes more familiar with technical aspects of the project and becomes aware of new possibilities. Sometimes it is driven by project team members, who may have discovered a better way of carrying out a particular task or wish to implement design changes. If the project is taking place over an extended period of time, technological advances or improved equipment or materials can also provide an incentive to change some of the project parameters. Other drivers can include changes in the business environment or key personnel.

Baseline changes are not always client-driven or even directly related to scope. They may be the result of a range of external factors that impact on the client’s business, or internal factors that affect the project team. The client may find, for example, that their cash flow situation has been compromised due to unforeseen expenditure elsewhere. This can lead to a downsizing of the project’s objectives (and by definition a reduced project scope) or perhaps delays in completing the project (work may be shelved until the cash flow situation has improved). Legislative and regulatory changes may also force the client to review project specifications, and may necessitate changes. Other external factors that can affect the project and may induce changes include significant shifts in the economic, political or social environment. Internal factors for change include technical difficulties that may be encountered in meeting the project objectives. These could be caused by a lack of suitably skilled personnel, the unavailability of vital materials or equipment, or simply a failure on the part of project team members to perform as expected. Significant budget overruns (spending more money that you planned to) may also force changes to the baseline.

Obviously, some kind of change control mechanism is necessary to ensure that change occurs in a controlled manner, that the changes are documented, and that the project baseline is adjusted to reflect the changes made. A formal procedure must be established for requesting a change, and any changes requested must be evaluated in terms of their impact on the project baseline. The exact procedures will vary from one organisation to another, but usually involve the individual or workgroup wishing to implement a change submitting a change request form. Depending on the nature of the change, the project manager may need to be informed of the change and his or her approval sought before the change can be integrated into the project plan. This will normally only be necessary if the magnitude of the change will significantly affect the project baseline. Generally speaking, changes should only be authorised by project personnel with the requisite decision-making powers.

A typical change request form is illustrated below. The information requested includes the name of the person requesting the change, the date on which the change was requested, a description of the change, and a justification for the change. In the example shown, the requestor may also assign a priority to the change request and comment on the impact of not making the requested change. Once the change request form has been submitted, the impact analysis section will be completed by designated members of the project team, who will evaluate the effect of the change on the project's scope, resource allocation, budget and schedule. If necessary, a risk assessment will be carried out and the risk management plan will be amended accordingly. The change request resolution section of the change request form records the decision reached (i.e. whether or not the change is approved), the reasons for the decision, and the identity of the person responsible for the decision.

When the change request form is first submitted it is assigned a change request number, and the details of the request are entered into a change log. The log will be updated with the relevant information once a decision has been made as to whether to implement the change or not. The information recorded in the log includes the change request number, the name of the requestor, the date on which the change was requested, brief details of the changes required, and the outcome of the request. If the change is approved, the task of implementing the change is assigned to appropriate personnel.