A scope change chart makes one question visible: how far has the project moved from what was originally agreed?
A change log tells you what happened one request at a time. A chart gives you the project-level view. It can show work added, removed or replaced, and the effect those decisions have on effort, fee or delivery.
Scope change chart example
Imagine a website project with 40 hours of agreed work. During delivery, the client requests several changes. Some add work, one replaces existing work and one removes something that was originally planned.
Example — website project
- Original scope
- 40 hours
- Added
- +8 hours — case studies section and additional mobile states
- Removed
- −3 hours — newsletter integration removed
- Replaced
- 4 hours — original gallery work replaced by a simpler portfolio module
- Current planned effort
- 45 hours
- Net scope change
- +5 hours · +12.5% versus the original baseline
The useful signal is not the number of requests. It is the net effect on the agreed project. Ten tiny changes may matter less than one request that adds another day of work.
| Change | Type | Effort impact | Status |
|---|---|---|---|
| Add case studies section | Added | +5 h | Approved |
| Add mobile interaction states | Added | +3 h | Approved |
| Remove newsletter integration | Removed | −3 h | Approved |
| Replace gallery with portfolio module | Replaced | 0 h net | Approved |
How to build a useful scope change chart
- Freeze the baseline. Record the original agreed effort, fee, deliverables or another measurable unit before comparing changes.
- Give every meaningful change its own record. Do not calculate the chart from memory or from a list of tasks that has already been edited.
- Classify the direction. Mark work as added, removed or replaced so an increase is not confused with a trade-off.
- Record the impact. Use the unit that actually matters to the project: hours, fee, deliverables, story points or another consistent measure.
- Include approval status. Requested work should not silently become part of the approved current scope.
- Compare current approved scope with the baseline. That difference is the number the chart should make easy to understand.
What should a scope change chart measure?
There is no single universal scope-change unit. Agile teams may visualize issue or story-point changes during a sprint; service businesses may care more about hours, fees or deliverables. The correct measure is the one that exposes the consequence of change in your project.
| Measure | Useful when |
|---|---|
| Hours | You estimate and manage work primarily by time. |
| Fee | The commercial effect of approved changes is the main concern. |
| Deliverables | The project is defined by pages, assets, concepts, reports or other countable outputs. |
| Story points / issues | You are tracking scope movement inside an Agile sprint or backlog. |
| Delivery days | Changes primarily affect the schedule rather than the amount billed. |
Do not combine incompatible units into one meaningless score. If cost and time both matter, show them as separate impacts tied to the same change record.
How to create a scope change view in Notion
A simple Changes database is enough. Each row represents one request or approved change. Relate it to the project, then store its type, status and impact.
| Property | Purpose |
|---|---|
| Change | Short description of what changed. |
| Project | Relation to the affected project. |
| Type | Added, removed or replaced. |
| Status | Requested, reviewing, approved, declined or completed. |
| Effort impact | Positive, negative or neutral change in estimated work. |
| Fee impact | Additional or reduced commercial value when relevant. |
| Schedule impact | Effect on the delivery date. |
| Decision date | When the change was approved or declined. |
From that database, create a project-filtered view and group records by Type or Status. The database remains the source of truth; the chart or grouped view is only a way to read the accumulated change faster.
If you need the detailed record behind each point, use a scope change report alongside the chart rather than trying to make the visualization carry every decision detail.
Common scope change chart mistakes
Moving the baseline
If the original estimate is edited every time the project changes, the chart will always make the current project look normal. Preserve the starting point.
Counting requests instead of impact
Five requests do not automatically mean more scope than one request. Measure the consequence, not just the activity.
Mixing requested and approved work
A client asking for something does not make it part of the current approved scope. Keep decision status visible.
Using the chart as the record
The visualization is a summary. The underlying change record should still preserve what was requested, its impact, the decision and the approval.