Configuration baseline¶
A configuration baseline is "the approved version of a work product that can be changed only through formal change-control procedures" (PMI, 2021, PMBOK Guide 7th Edition).
In plain language: it's the snapshot of "what we agreed on at this moment" plus an audit trail of every change since. Together, they let you answer questions like:
- Who decided this?
- When did the scope change?
- What was the original effort estimate before three rounds of revision?
- Who was on this project last quarter?
Without a baseline, those answers are guesses. With one, they are facts.
Why this matters¶
A project without a baseline is a project where:
- People remember the original deal differently.
- The estimate keeps going up and nobody can say when or why.
- New requirements appear with no record of who asked for them.
- The team can't tell what's scope creep vs what was always there.
A project with a baseline doesn't argue about history. It looks it up.
How dooer implements it¶
dooer's AuditLog table is your configuration baseline. Properties that matter:
- Immutable. You cannot edit an audit log row. Period. There is no UI for it.
- Per-change. Every meaningful mutation — task status change, reassignment, effort revision, brief edit — creates a row.
- Before/after. Each row stores
changes_json: what the field was before, what it is now. - Attributable. Every row has
actor_id— the user who made the change. - Timestamped. Down to the millisecond, in UTC.
You access it via Settings → Audit (T-1.8, S-3.3, T-3.2).
What counts as a baseline change¶
These actions write to the audit log:
| Action | What's recorded |
|---|---|
| Create a task | The initial values of every field |
| Change a task field | Before/after for that field |
| Reassign | old assignee, new assignee, original assigner (stays) |
| Propose / approve / reject effort | The effort number, the decision, the actor |
| Upload an attachment | File name, size, uploader |
| Approve / reject feedback | The decision, the actor |
| Create a project | Initial values |
| Change project status | Old status, new status |
Notice what is NOT in the audit log: comments. dooer treats comments as conversation, not as configuration. Comments are searchable in the task, but they don't create audit-log rows. (Comments do, however, fire notifications — see the causality map.)
How to use the baseline in practice¶
Monthly project review (T-2.8): filter the audit log to the project + last 30 days. Look for: scope additions (new tasks late in the project), effort revisions upward, repeated reassignments.
Quarterly portfolio review (T-3.4): filter by quarter. Pull the headline stats per project — number of state changes, fanouts of reassignment, count of feedback closed. These become the slides.
When something goes wrong (any tier): open the audit log filtered to the affected task. The before/after for each field tells you exactly what changed and when. Most "what happened?" investigations become a 5-minute look at the audit log.
What it can't do¶
The audit log captures facts about state changes. It does not capture:
- Why a decision was made (use comments or meeting decisions for that).
- Intent (was this a scope addition, or a clarification?).
- External context (the sponsor changed their mind in a phone call).
So the audit log is necessary but not sufficient. You pair it with comments + meeting decisions + the Feedback Register to get the full picture.
The relationship to lessons learned¶
A baseline tells you what changed. The lessons learned register tells you why + what we'll do differently.
PMBOK 7 treats them as a pair. Together they form what PMOs call the project record — the durable artefact that outlives the project itself, available for the next project to learn from.
In dooer, the lessons-learned register is the Feedback tab on a project (S-3.2, T-2.5).
Where to read more¶
- PMI (2021). PMBOK Guide, 7th Edition. Performance domain #8: Uncertainty. Configuration baseline definition.
- Heagney, J. (2016). Fundamentals of Project Management, 5th Edition. AMACOM. A more readable on-ramp.
- ITIL 4 (AXELOS, 2019). Service Configuration Management practice. The IT-flavored treatment.