A baseline is a snapshot of your plan at a specific point in time - scope, schedule, and budget, frozen and agreed upon. Change control is the process that protects that baseline from being eroded one 'small adjustment' at a time. Without a baseline, you have no way to measure progress. Without change control, your baseline is a suggestion.
The baseline: your project's original sin
At the end of planning, you freeze your scope, schedule, and budget. That frozen version is the baseline. From that moment forward, every deviation from it is a change that needs to be evaluated, approved, and communicated. The baseline is the truth. Everything else is a departure from the truth that needs justification.
A common beginner mistake is treating the baseline as permanent. It's not - it's the starting point. Changes happen. The baseline should be updated when approved changes occur. But the key word is approved. If the schedule slips by two weeks because someone didn't plan for a dependency, that's not a change - that's an error. If a stakeholder adds a new feature, that IS a change, and it requires a formal change request.
The psychological trick: stakeholders respect a baseline they helped create. Involve them in the planning process and get explicit sign-off on the baseline. A stakeholder who signed the baseline is much less likely to demand additions without understanding the consequences - because they know you have a signed document that says otherwise.
A change control process that doesn't collapse under pressure
Every change control process needs four things. First: a change request form - simple, one page, asking what the change is, why it's needed, what it impacts (scope, schedule, budget, quality, risk), and who's requesting it. If someone can't fill out one page, the change probably isn't that important.
Second: a change review board (or at least a designated approver). For small changes, the PM may have authority. For medium changes, the sponsor signs off. For large changes that reshape the project, the steering committee decides. The key is knowing which threshold triggers which approval level before the first change request lands on your desk.
Third: a log. Every change request - approved or rejected - goes into a change log. This is your audit trail. When someone asks at the end of the project 'why did this take so much longer than planned?' the change log is your evidence. 'We approved 12 change requests that added 6 weeks of work.' Hard to argue with documentation.
Fourth: communication. When a change is approved, everyone who needs to know should know. Not just the person who requested it - the team, the stakeholders, the finance department. An approved change that nobody acts on is a meeting that should have been an email, except with more disappointment.
Summary & next steps
The baseline is your frozen plan - scope, schedule, budget. Change control is the process that manages deviations from it. Four components: a change request form, a clear approval authority, a change log, and communication. A baseline without change control is a new year's resolution. Change control without a baseline is arguing about whether something changed when you never agreed where you started.
Next: Working with Stakeholders - because projects fail more often because of people problems than spreadsheet problems.