Another article (without video this time) in the “It Depends” educational series. Today we discuss the common confusion on project variances and project changes. We will also discuss corrective actions, preventive actions, and the different types and categories of change. Further, we will discuss whether variances are changes or not.
Variances
Variance Definition
Variances are things that happen as a result of doing work. In other words, as we work on an activity or a work package, the actual could be different from the plan. Typically, variances are related to productivity or market conditions. For example:
Schedule Variance
The plan for a work package is 7 days of work. However, the actual was 6 days, which is a favorable variance of 1 day. Also, it is possible that the work took 8 days, and that would be a negative variance of one day. Consequently, one would ask about the cause of the deviation or variance. The team can investigate if the cause is not apparent. Further, once the team knows there is a variance, they can take corrective action, IF applicable or necessary.
Cost Variance
Another example would be a cost variance. In this case, let us say that the plan is to buy X for $100. The actual cost was $110. Therefore, there is a $10 negative variance or 10% in this case, on this given gadget. In other words, this is market condition variance.
Other Types of Variances
In addition to cost or schedule, there could be other types of variances.
For example, there are variances related to the team, quality, or risk. In the end, the impact of these variances will translate to time or money. Therefore, the impact will be to cost, schedule, or both.
Are Variances, Changes?
First and foremost, how you label them is up to you and your organizational preferences. It may also seem that it is a matter of semantics, or the differences are “in the gray.” Let me not finish the answer here; I will come back to that later.
Changes
Definition of Change
Changes are conscious decisions to change the plan. In other words, the plan states that we should do A, but the team decided to do B. In this case, we must elaborate on some of these terms.
Plan
When practitioners hear the term “plan,” many would think it refers to the approved Project Management Plan. That is not always the case. In our framework[1] and practice, the term “Plan” refers to any formal control document. This can be the Project Brief[2], the Project Authorization Document, The Project Requirements Document, or any other stage deliverable. Therefore, any decision to alter one of these approved documents (approved at the Stage Gates) could be considered a change.
Team
We use the term team here to represent the project team, including the project manager and the sponsor. Therefore, when we say “the team decides,” it could be a project manager, sponsor, or someone else decision. The decision-maker is a function of the organizational policies and guidelines.
Types of Change
The change could be related to cost, schedule, quality, or anything else. For example:
- Deciding to change the warehouse area from 10,000 square meters to 9,000 is a scope change.
- Management asks the team to accelerate (or slow down) the work, which is a schedule-related change.
- Changing the specifications on a gadget can be classified as a “Grade” change, i.e., quality-driven change.
Categories of Changes and Who Can Approve What
In SUKAD, we recommend three categories of changes:
Contract Changes
Contract changes are changes to a given contract. These changes will alter the scope of the contract. However, they are probably within the plan and objectives of the project.
Who can approve it?
If this change does not affect the project objectives, then either the project manager or the contract administrator would have the authority to approve. However, this depends on organizational policies and guidelines.
Project Changes
Project changes are changes to a “plan.” However, these changes DO NOT alter the project objectives. Most likely, these would be necessary to ensure the achievement of the project objectives. Therefore, they could be things related to corrective or preventive actions. The trigger for the change could be anything that the team sees would be good or necessary for the project.
Who can approve it?
Please note that we already stated that this change DOES NOT affect/change the objectives. Therefore, our recommendation is that this category of change should be within the project manager’s authority. However, in some organizations, the authority could be restricted to the Sponsor or a Change Control Board.
Objectives Changes
Objective changes are changes to the project objectives. Organizations with sound OPM Systems would typically have established definitions for what constitutes an objective change. A general criterion would be changes to the product’s capacity, quality of the product, change of location, and so on. For example, the change in the warehouse-size (mentioned earlier) is an example of objective change.
Who can approve it?
Whoever authorized the project. In other words, it would be the sponsor or a steering committee.
Back to The Question: Are Variances Changes?
It is time to finish the answer that we started earlier.
First, many variances are things that happened and cannot be changed. Therefore, all we can do is reflect the deviation, positive or negative, in our forecast.
However, if this variance could happen again, there may be a need for a “change.” In this scenario, the “change” would be to take preventive actions to avoid repeating the deviation.
On the other hand, the variance may require corrective actions, which some organizations would treat as a “change,” while others would just document it as a variance (not a change).
Consequently, are preventive and corrective actions classified as changes?
Once again, It Depends 😊 on the organizational policies and guidelines. In all cases, variances, corrective actions, and preventive actions must be documented. In some organizations, they would have “a form” to document these things and label them as “Variances,” while others classify them as “Changes.” Here, it is essential to reflect on what we said earlier; we have suggested three categories of changes. In this case, Variance-driven changes would be categorized as “Project Change.”
How to Reflect the Above in the Cost Report?
In response to a LinkedIn question recently, I had developed this graphical presentation.
Objective Changes & the Control Budget
The third column, labeled Change Orders (Objectives Changes), reflects the third category of changes that we identified earlier. These are what some practitioners like to call “Scope Changes.” However, since some view the term scope to mean different things, we prefer the term objective change.
What we did not say earlier is that this category of change is NOT covered by contingency. These changes would typically require an adjustment to the approved funds or schedule. As a result, the project manager would not be accountable for these changes. Consequently, we have the Revised Budget or Control Budget Column. That is what the PM is accountable for.
The Variances & Changes
Another column of interest to us is the “Variances & Project Changes.” It should be clear from the title that we are treating (documenting) variances independent of project changes. If you want to combine them, that is an organizational preference.
Consequently, the forecast is based on
[Forecast = Control Budget + Variances + Project Changes + X]
What does X represent?
X represents the project manager and PMT judgment based on things they expect, foresee, have insights about but cannot quantify yet. By the way, these items (Variances and Project Changes) are covered by contingency, which we are not showing here. How to handle and manage contingency is a separate discussion.
Closing Remarks
This article is part of the “It Depends” Series for a reason. How you define and manage variances, changes, and how many categories of changes depends on the organizational project management system. This is why “It Depends.”
What we offered in this article is in line with our perspective and the SUKAD Way™ Project Management Framework, including the concept of the Four Control Reference Points.
[1] The SUKAD Way™ Project Management Framework
[2] These are the terms we use in CAMMP™ and are the outputs of the stages, i.e., stage deliverables.