When you’re starting up a new warehouse, change control may be the last thing on your mind. After all, you’re probably thinking about the conveyors, hiring, and forklift delays. It’s understandable because change control is often considered as administrative distraction, and–let’s be real–it’s not the most exciting part of the PMBOK. But managing change is essential to for tracking and keeping the team aligned on of project activities, cost, and schedule.
What is change control?
Change control is the management of new circumstances or requirements as they arise in the project. Changes have many causes. Some are discretionary, like making a decision to use a different piece of equipment. Some may be due to new information or requirements that are discovered. Some might happen because of circumstances entirely outside of the control of the project team, like, say, shipping delays due to a global pandemic.
Changes often impact what will be delivered, when it will be delivered, and how much it will cost.
Whatever the reason for the changes, they must be identified and controlled.
Why have change control?
Changes must be controlled for management visibility, responsibility, and overall control of the project. If you don’t control and make deliberate decisions about the scope, schedule, and cost of the project, how will you tell if it is successful? How will the project team manage accountability and responsibility?
Tracking changes is also useful for bridging where a project started to where it is. When you close the project it’s important to know what the team achieved.
The Client’s Point of View
There are a couple points of view to understand changes from.
Let’s say you’re running a warehouse startup project for a F500 company and are managing multiple vendors for systems, racking, and material handling automation. You may be asking the vendors to do extra work to improve something. For example, you may ask the automation vendor to add a run of conveyor to the dock. Or you may ask the IT systems vendor to add a trailer auditing feature.
These requests could have originated from an executive or an hourly associate. But whatever the request is, you’re now asking for more work.
At this point, it’s very important to understand who has decision-making authority on a project. If there is no change control, project team members interacting with vendors could make decisions that affect delivery of the entire project. If you don’t want an operations supervisor approving hundreds of thousands of dollars of construction or automation changes or asking for something that delays the entire project, then you need a process in place to manage the decisions and their associated spending and schedule impacts.
Further, changes usually consume budget. While workstreams may have their own budgets with some ‘sand’ or contingency in them, the main project budget contingency is controlled at the project level. Someone with proper authority to release the contingency needs to understand and approve the changes.
The Vendor’s Point of View
Now let’s switch our point of view. Perhaps now you are a third-party logistics provider working for the F500 company client.
Changes also add work to the project. If your client starts giving you extra things to do, you want to make sure they’re understood as changes by both of you. Since you’ll be doing more work, you probably want to get paid for the work. This means you want the client to understand and agree that more work means more time, complexity, and that these things can affect the original agreement for cost, scope, and schedule.
So we see that it’s important to track changes, estimate them, and get documented agreement to do them.
Areas of change
Most changes happen in the longest-lead work. This means construction, IT systems, and IT infrastructure are usually where to look for changes. This is because the design is often done before the team has full knowledge of the operation’s needs. As a result, things get developed, ordered, or built before the full requirements and scope are understood.
Then changes are needed to complete the solution for all the discovered requirements.
Using Contingency
Let’s consider changes and how they relate to budget contingency. Budgets for projects often include contingency funds for unanticipated circumstances or events. This set of purposes includes both variances to budgeted items and changes.
While variances–perhaps due to material price spikes, higher than expected shipping costs, or other–are unwelcome, they are not changes because they were planned into the budget scope. Many times workstream budgets have their own contingency buckets to deal with variances and can make up a loss on one line with a favorable other line. For example, say that Facilities was over budget on forklifts but under budget on racking – no problem! Or that Facilities consumes a General Contractor contingency amount that was in the contract. No problem.
However, if the variances are systemic in a workstream, then additional budget can be requested as a change. This can be authorized and paid for out of contingency with approval of the contingency-holder, usually the project owner or sponsor.
Other smaller changes may consume contingency from a workstream budget. But changes may get funded from the project contingency if they can’t be handled at the workstream level. At this point two sets of stakeholder demands need to be managed:
- the business counterparty
- the project workstreams
If you’re a 3PL starting a site, the business counterparty may include your client or the GC. This just means anyone “upstream” or “downstream” in the project. It’s important to clarify whether the contingency is available for their use in the project or whether it is your discretionary contingency.
In the 3PL example, the client may see project contingency as available to them for extra trim or equipment in the warehouse. The 3PL may see it as required to fill systems development resource gaps or add functionality for efficiency. Who is right? This depends on what you have agreed at the start of the project about who owns contingency, what it’s for, and what the release process is.
Managing priorities within the project is also important. The project workstream leads may have needs during the project. But the project contingency is finite. If IT gets requests from Operations to add functionality, and the construction team needs to add more parking, who gets the funds? Ultimately the decision to release contingency, reject the changes, or get more budget should go through a decision-making process to the owner.
Level of Changes
All changes are not equal. The addition of another chair to a furniture order is easily handled by the facilities lead who is ordering the furniture. But adding 5 more reach trucks to the site equipment list is different. Adding automation for tens of millions of dollars is another level still.
Handle this complexity by:
- Identifying spend authority at the beginning of the project
- Classifying known purchases according to spend approval needed. Pre-approve purchases based on initial budget, perhaps with a design and quote review to align all the stakeholders before issuing the purchase.
- Communicating the levels of approval to workstream leads.
- As changes are identified, classify and manage them according to the approval level required.
Changes within workstreams should be handled and approved within those workstreams. You don’t need executives approving extra column protectors. On the other hand, large project-level or high visibility scope changes should be handled at the project level. And sometimes you may need to go above the project to a board or other executive team to get approval for major changes.
Change Process
Change control can be administrative and intimidating. Project teams hate writing up complex justifications and going through interminable reviews. They think, why not just make decisions? Let’s look at an easier way and think of the fundamentals.
First, understand levels of authorization. Who can approve how much money? This will dictate the reviewers & approval process needed.
Next, assign responsibility for developing the change justifications to the workstream leads. While any project member should be able to propose a change, the workstream leads should be the champions and owners of the changes. This ensures buy-in and vetting of change requests.
Then define, communicate, and set the actual change review cadence. Often reviewers want to understand and ask questions about changes, especially expensive changes. So a standing meeting is useful to have a regular venue for review and approvals.
Workstream leads should prepare for the meeting by updating their change request decision support materials and submitting them to the Project Manager. The project manager should collect them and prepare an agenda.
The actual meeting with the change review board. Change review boards should include the project owner or decision-maker(s) needed to make decisions on changes. The project manager should attend as well as the workstream leads who have changes to present. Other subject-matter experts can attend as needed.
A simple flow is below.
The agenda is at the review board is:
- Workstream leads or SMEs present changes ready for decision
- Review Board or approver makes decisions. Decisions can include approval, rejection, or deferral (usually a request for more information or waiting until a situation develops more).
- Review newly submitted changes
After the meeting the PM should capture and send notes or otherwise memorialize the meeting for reference.
And that’s it. A weekly review with preparation by the change owners, administration by the PM, and decisions by the project owners.
Preparing A Change Request
Workstream leads should expect that the level of effort to justify and approve changes is proportionate to the impact of the requested change.
I recommend putting together the following for large changes:
- Business need for the change
- Full costs, both capital and operating.
- Idea of payback period
- Contingency plans or alternate options to the change. Other quotes if appropriate.
- Timeline of implementation
The idea is to help put the change in context and help the decision-maker with an informed decision. There is not a specific format for this information. It can be a text document, a slide, or a spreadsheet.
Logging the changes
The last part of all this is tracking the changes. The project manager should maintain a log of the changes. This log should include the change name, identifying number, owner, opened date, closed date, and decision at a minimum. Other information can be maintained at the change request documentation.
After the change board makes a decision the PM should memorialize the decisions in a document artifact, email, or other repository tool. Then the PM should communicate decisions to the project team.
Conclusion
Change control is less exciting than many part of the project. From reading this far you can tell that it is another administrative requirement. But it is absolutely critical to have change control in place, and preferably a robust process that the project members and owners can rely on. This will help your projects proceed smoothly, with fewer surprises, and everyone confident in what they’re doing.