On a Project Management website, a member asked this question: “In case of project scope change, is there a need to revise Project charter?” To answer this question properly, one needs to understand (1) the difference between product scope and project scope, and (2) the different types of changes that could happen on a project.

The difference between product scope and project scope

Before we can answer the question, we must understand the different types of changes. Further, before we talk about changes, we need to under the difference between product scope and project scope.

Product scope

Product scope is about what the team will be producing at the end of the project; the objective; the output; and maybe the outcome. The product scope, or what the PMBOK Guide calls a Statement of Work, will be highlighted in the document that authorizes the project. Again, in the PMI world, this is the project charter.

Project scope

Then, what is the project scope?
The project scope is the project work; as Bill Duncan[1] likes to call it.  In other words, project scope is the work that the team must perform to deliver the product scope. Deliver the product per the objectives identified in the charter. Think of the charter as the high-level specifications.
To learn more about the difference between product scope and project scope, please refer to a past article and a video.

The different types of changes

First, we must clear the obvious, which is, in the context of this article we are talking about changes on projects and not organizational change.
One of the challenges, often among PMBOK Guide “students”, is that the guide does not clarify this point and talk about change as an absolute concept. Therefore, and with the above in mind, what are the different types of changes?

Contract changes

This type of changes is clear from the name. These are changes to a contract, which is typically between two parties. It is when “a buyer” issue a change to “a seller” to alter a contract. The change could be addition or deletion of work; change in schedule; or any other contractual clause.

Objective changes

On a project, the team might encounter the need to change, alter, modify the final product. Any change to the final product is an objective change. The final product is defined in the Project Authorization Document (Project Charter). In addition to the product scope, the Project Charter includes other key parameters, such as the target completion date. Without getting too much into a sideline, the project charter should be BRIEF, and include only the main objectives in term of product, initial budget and schedule. Therefore, any change in the objectives is an objective change and must result in a revision or amendment to the charter. Some organizations do not revise the document itself but consider a formal change form as the amendment. In these situations, there will be justifications to request an adjustment to the cost and schedule, up or down, depending on the impact of the change.

Project change

There are changes that might modify the “work” on the project, without touching the product scope or the project charter.
There are changes required because the team discovers an error in the early work. This error might require a change in the plan that is necessary in order to meet the original objective of the project. These are performance matters; variances; defects; etc.
In some situation, we might have an item that is ambiguous, no clear details, but as the design progress, the team will need to modify the scope of work; again to meet the objectives. We call these design development; or progressive elaboration.
In all of the above three cases, we have changes that do not result in a change to the project charter and their impact will be part of the project variances; or contingency.

Knowledge Area Change

In practice, there is no such a thing as a knowledge area change. Basically, any change related to a knowledge area would be one of the above categories. In other words, a “scope change” if it is mostly project work (scope) and maybe a design development item, then it would be a project change. If the scope is product scope then that will be an objective change.
The same thing is scheduling modification to the schedule would normally be within the objective. However, changing the completion date is an objective change. In other words, on a project, it does not really matter if the change is related to scope, time, quality, or anything else it would be classified as a project or an objective change.

Examples

We will discuss one example here that would be easy to visualize, the project scope is to deliver a residential tower. Consequently, the product scope is the building and the project scope is the work to deliver it; which would cover many stages, such as concept design, architectural design, engineering, procurement, construction, etc. Within each of these stages, there will be specific work to be done.
The tower will have different sizes of apartments but in total, it would be about 10,000 square meters (about 108,000 ft2).

Scenario 1

1. If the owner decides to make this tower 9,000 or 11,000 m2; about 10% up or down on the total capacity. This type of change would be an objective change.
2. Based on market demand, the owner decides to change the location; again, this is an objective change.
3. With the advancement of technology and sustainability, the owner decides to make the tower a smart and green building, instead of a regular building; yet again an objective change.

In all of these cases, good project management practice would require a change in the project charter. Such a change will also justify adjustments to cost & schedule. Finally, such a change will have an impact on many things on the project, including quality, risk, procurement but in the end, all of the impact manifest itself in the form of cost or schedule, hence the need for adjustments.
Why do we need formal adjustments?
Formal adjustments are necessary for (1) organizational learning, (2) historical records, (3) performance assessment, (4) measuring success, and many other reasons. The ultimate reason is we need to be able to reconcile the final results with the plan and objectives. It is necessary to document the reasons for any deviations. We need to know if the difference between actual and plan is due to project management performance or organizational (business) drivers.

Scenario 2

We are on the same residential tower.
Let us say in the conceptual design, the team forgot to include (enough) space for certain equipment. That would be an error and the team must fix it; if these equipment items are necessary. In this case, the space required is 300 m2. The team will either have to:

1. Add the required space (making the building 10,300 m2).
2. Alternatively, convert some of the existing residential units, or parking space for this purpose.

In project management, we define this scenario as a project change, but not an objective change; it does not impact the project charter.

Scenario 3

Let us stay with the same tower, and the same scope, but the team had to make some design changes to the layout or arrangements. As long as these adjustments do not alter the objective; this is not a charter change.
I can give more examples from other industries but I think the above is enough for now.

Closing Comments

We often joke that the best answer to any project management question must start with “it depends.” However, this is not a joke. Reality dictates on us to determine the context before we can answer any question. What I presented in this article is in line with the leading practices in project management, in particular, the capital project industry. However, the concept should be used in one form or another on many, if not most project types. Sure, the details and actual processes might vary from one organization to another. In the end, if we want a higher level of organizational project management maturity, we need a formal process.
Further, as you would have noticed, before we could answer the question on the need to change the charter due to scope change, we need to understand the context. We need to understand the different types of changes and the differences between product scope and project scope.
Now, in the Agile world, is change management important or is it as some presents, no problem. Well, even in agile, the concept of change management is misunderstood, but that is for another time, another article.
For additional readings on change management, please consider:

1. Article 1: How to manage project changes and why is it important?
2. Article 2: How to discover the hidden project changes and scope creep?
3. Article 3: How to manage project changes in the fog?
4. Article 4: How to manage project changes, closing comments!

Until next time
[1] Bill Duncan is the primary author of the original PMBOK Guide and a active project management thought leader.