Controlling Changes in the Project

Micro Learning Unit

Changes in the project are inevitable. Nonetheless, all changes can and should be managed in a methodical and meticulous manner. Otherwise, these changes alone can determine the project’s fate (not always in a positive way).

The longer the project is, the higher the chance of changes occurring – either from within the project or due to changes outside the project.

Changes can be the result of several factors:

  1. Additional requirements or changes in existing requirements resulting from either incomplete scope definition at the beginning of the project due to the low level of certainty that characterizes the preliminary stages of the project or from defective scope definition due to insufficient resource allocation.
  2. Additional requirements or changes in existing requirements result from changes in targets or internal or external conditions that affect the project.
  3. Additional requirements or changes in existing requirements resulting from findings of various control systems and activities.
  4. Changes in the resources allotted to the project or the constraints on the project.

Whenever a change is made to the project, the following steps should be followed:

A change that is incompatible with the goals of the project must remain outside the scope of the project unless this change reflects appropriate project goals that were not identified earlier in the planning process. In this case, the project goals must be updated and additional requirements derived from these goals must be identified and added to the project scope.

Impacts on the schedule, resources and budget should all be considered, as well as eventual impacts on the quality of the final product. Additional factors that should be taken into consideration are the complexity of the project, any new risks that arise from making the change and any impact of the changes on external processes and systems.

Some changes simply are not feasible or cannot be made due to budgetary, technological, environmental or regulatory limitations. In such cases, an alternative to the desired change should be sought, or the change should be postponed—at least at this point in the project.

Even when the change is compatible with the goals of the project and is feasible, it is not always worthwhile. The question of profitability is all about alternative benefits that can be achieved using the resources required to perform the desired change. Since resources are always finite, it is possible that it would be better to invest them elsewhere and not in the requested change to the project. If that is the case, the change should be postponed—at least at this point in the project.

After examining the feasibility of the change and whether undertaking it is worthwhile or not, it is necessary to obtain either full or partial approval for it. Approval of changes to the project is typically given by the steering committee or another committee dedicated specifically to managing changes in the project. However, in order to avoid impeding the project with unnecessary bureaucratic processes, it would be best to give the project manager the authority to approve some changes—as long as this authority is defined clearly and takes into consideration things such as the effect the change will have on the budget and schedule of the project.

Particular consideration should be given to the time when the change was introduced. A change that pops up late in the project—regardless of how small it is—must be approved by the senior management team in order to ensure that its implications are clear to and approved by the client.

Regardless of whether the proposed change was approved or postponed, it should be publicized in order to ensure that all stakeholders and everyone involved in the project understand the change, the decision that was made regarding it and its implications. Distributing information about the change internally will be done in formal meetings and project reports. Disseminating information about changes in the project to the public will be done via the media.

After a change is approved, all relevant project documents should be updated including the work plan and risk management plan, as well as any deliverables that are affected by the change. If the change has a significant impact on the project scope, schedule and resources, a new baseline plan should be created as a reference for all further evaluation and control activities. In any case, all decisions regarding changes should be documented in a special Change Management Log and in the Project Log.

Sound project management requires enough flexibility to manage changes on the one hand and uncompromising preservation of the project boundaries resulting from its goals on the other. Given the fact that changes occur in all projects—if only because of the uncertainty inherent in them—an organized process to manage and disseminate information about these changes to various stakeholders should be introduced.

Many changes are an indication of a lack of stability in a given project, which might be the result of some of the following factors:

Defective definition of the project goals

Incomplete definition of the requirements or solutions offered

Insufficient focus and decisiveness on the part of management

Too few changes might indicate sound project management but could also indicate a lack of client or organizational involvement in the project. In such a case, silence from the client is not a positive thing; it is quite often nothing less than a serious threat to project success.

Therefore, as part of the control of project changes, pay attention to project stability indicators, whether these are in the form of too many changes or a suspicious lack thereof. Work proactively to verify that everything is moving according to plan and to avoid the tendency to hide one’s head in the sand or imagine that what is not explicitly stated does not exist.

Change Management Log

Download now an Excel report for managing and tracking project changes