Change control and baseline management

0:00 Change is normal. Uncontrolled change is fatal

Every project changes. Clients change their minds, designs develop, sites surprise you and markets move. Change itself isn't the enemy. Uncontrolled change is. It's what turns a clean baseline into a rubber band, where the budget quietly stretches to fit whatever happened and performance measurement becomes meaningless. In this lecture you'll learn the different types of change and how each is treated, a simple five-step change process, how to write a change request that gets a fast decision, how to set up delegation of authority, and how to spot scope creep before it's cost you weeks. By the end you'll be able to design a change process light enough that people actually use it, and strong enough that the baseline always tells the truth.

0:54 Why it matters

Why does it matter? First, integrity. Earned value, forecasts and every variance you report are measured against the baseline. If the baseline changes without approval, or approved changes never make it into the baseline, your numbers stop meaning anything. Second, timing. The later a change is decided, the more it usually costs, because work has to be undone or re-sequenced. Showing that clearly encourages faster decisions. And third, scope creep. It rarely arrives as one big request. It arrives as dozens of small 'can you just' requests, none of which seems worth raising formally, and together they consume weeks.

1:37 The concept: types of change

Here's the key idea: different kinds of change need different treatment, so classify them first. A client-directed scope change, like an additional floor or a new feature, becomes a variation or change order, with budget and schedule adjusted. An internal change without scope change, such as a method change or re-sequencing, gets an internal record and may transfer budget between accounts. Design development, where details evolve within the agreed scope, is usually covered by contingency, but watch it carefully, because hidden scope growth loves to masquerade as design development. A contingency drawdown moves money from contingency to a control account when a risk occurs. And a trend, or early warning, is logged and assessed before it becomes a formal change. Think of trends like a weather warning: better to hear about the storm before it arrives.

2:36 The process

The process has five steps. First, identify and log: anyone can raise a change request or early warning, and it gets an ID. Second, assess impact across scope, cost, schedule, risk, quality and the contract. And please, run schedule impact through the actual schedule, not a guess. Third, decide: the right authority approves, rejects or defers, according to the delegation matrix. Fourth, implement: update the scope, schedule and cost baselines, communicate the decision and issue instructions. Fifth, record and track, including rejected changes and the reasons, because the same idea often comes back three months later. Keep the process as light as you can. A change process so heavy that people bypass it is worse than none, because it gives the illusion of control.

3:30 Worked example one: a change request that gets decided

Here's a change request from the lesson that's built to get a quick decision. Change thirty-one: the client wants a rooftop solar canopy over the car park, to meet a sustainability target. Scope impact: a new WBS element, one point seven. Cost impact: plus four hundred and ten thousand, a class three estimate, with a range of three eighty to four sixty. Schedule impact: plus three weeks to handover if it's approved by the twentieth of June, plus six weeks if it's approved later. A new risk on structural loading, and an opportunity from energy savings. Contract basis: a variation under the relevant clause. Recommendation: approve with a three-week extension of time. Notice that time-sensitive line. It turns 'let's think about it' into 'let's decide by the twentieth'.

4:26 Worked example two: ERP creep in Lahore

Now a realistic scenario. A fictional ERP implementation for a distribution company in Lahore accepted forty small configuration requests informally over four months. None was more than two days of effort. Nobody thought any of them worth a change request. Together, they consumed about seventy person-days and pushed go-live by five weeks. The fix was simple. The team introduced a trend log. Every request was logged, estimated and batched for a weekly decision by the product owner and project manager. About a third were deferred to a phase after go-live. Nobody said no to the business. They just made the trade-off visible, and let the people accountable for the date make the call.

5:15 Watch me do it: change log with authority routing

Let me show you the change log I'd set up. One row per change request: ID, description, type, cost impact, schedule impact, status and date raised. Then an approver column calculated from the delegation of authority. Say under twenty-five thousand with no milestone impact goes to the project manager; up to two hundred and fifty thousand and under two weeks goes to the project director; anything bigger, or touching a key milestone, goes to the sponsor or change board. A nested IF or an IFS formula does it, so routing is automatic and consistent. Next, a days-open column: anything undecided for more than fourteen days turns amber. And finally, a total of pending changes by likelihood, linked straight into the forecast sheet, so the EAC never forgets what's in the pipeline.

6:12 Baselines, creep and common mistakes

Every approved change creates a new baseline version, with a note of what changed. Keep the original baseline too. Performance against the current approved baseline measures how efficiently you're executing. Comparison with the original shows how much the project has grown. Leadership needs both stories. Watch for scope creep signals: hours rising with no new change requests, design reviews adding features, and people working on items that aren't in the WBS dictionary. The common mistakes: implementing changes before approval, updating the baseline without a change record, assessing cost impact but not schedule, and losing pending changes from the forecast. On AI: tools can compare requests with the WBS dictionary to flag likely scope growth and draft impact summaries. Final assessment and approval stay with accountable people.

7:07 Recap and try this now

Let's recap. Change is normal, and change control keeps the baseline honest. Classify each change, then follow five steps: identify and log, assess impact across scope, cost, schedule, risk and contract, decide at the right level, implement and re-baseline, and record everything, including rejections. Make time-sensitivity visible so decisions happen quickly. Batch small requests in a trend log so creep becomes visible. And link pending changes into the forecast. A quick self-check: compare last month's booked hours with the WBS dictionary, and count requests older than two weeks without a decision. Your try-this-now: design a delegation of authority table and a one-page change request template tailored to a project you know.