Although there is a much cruder way to put this, change happens.

Given that our project plan is nothing more than a series of estimates and forecasts, reality will inevitably take us in any number of different directions once we start executing our plans and delivery gets underway (and uncertainty reduces).

Therefore, in project-land, change management is identifying, reporting, and authorizing updates to our project plan.

These updates may take the form of changes to our baseline scope, schedule, or budget, and also include amendments to our stakeholder and risk registers, human resource plan, and other related documents.

Yet project change management should not be confused with organizational change management, which in many respects is all about creating the business case for projects.

Now that is a somewhat simplistic distinction, and, as you will see, project and organizational change share several common features.

Nonetheless, we will not explore in detail factors such as the cultural implications of change in this Unit – they are more appropriately considered in the context of business-as-usual.

As with all things project management, we have tools to assist us in identifying change requirements, as well as a process to follow to ensure that change is efficiently approved and effectively communicated to all stakeholders.

We will also address the hot potato of project scope creep, a condition known elsewhere as the project managers’ curse.