How to Handle a Label Services Scope Change During a Release
Use a written change card to decide whether to add, swap, defer, or decline work after a label services campaign starts.
The short answer
Before approving a label services scope change, compare the request with the work already agreed. Ask what the change adds or replaces, what it costs, and which release dates, assets, or approvals it affects. Decide whether to add, swap, defer, or decline the work, then record the decision through your agreed approval process.
Three things to know
- 01
Keep the original scope and describe the proposed difference in one sentence.
- 02
Test the change against booked work, approval time, and the next release decision.
- 03
Give pending requests an owner and a decision deadline so nobody schedules them by assumption.
What goes on the release change card?
Fill this in before moving an approved deadline or adding a task to the release calendar.
- 01
Baseline and request
Link the approved scope and state the exact task that would be added, removed, or revised.
- 02
Release reason
Name the audience action or release decision the proposed work would support.
- 03
Impact and alternative
List changed cost, dates, files and approvals, then show the option that preserves current work.
- 04
Decision and authority
Record add, swap, defer, or decline, and who can confirm it through the agreed channel.
- 05
Update and handoff
Record the affected tasks, updated versions and who has been told to work from them.
What has actually changed?
Start with the latest approved scope. The Records guide to scoping label services separates deliverables, exclusions, artist inputs, and approvals. Use those fields to describe the difference. A corrected title on the agreed artwork, another review round, and a new video format are three different requests. Ask how each maps to the written scope and revision terms before treating it as a new purchase.
How do you trace the effect on the release?
List the people, files, and decisions the new task needs before it can be useful. Work back from the actual handoff. An extra clip might need a fresh edit, collaborator approval, and time for the partner to check the final export before posting. Ask what would move if the same person is already booked to deliver the release assets. Get a revised fee and schedule together so you can judge the real tradeoff.
When should you add, swap, defer, or decline?
Add work when it serves a specific release goal and you can accommodate the extra cost and time. Swap when the new task is more useful than a named item you can remove. Ask for the net cost and confirm which commitments still stand. Defer when the idea has value after launch or needs inputs that are not ready. Decline when the change has no clear use or would crowd out a more important commitment.
What does a constructed scope swap look like?
Constructed example. A duo requests a short live-performance clip after the release plan has been agreed. The editor can fit it in before launch only if a second teaser comes off the schedule. The duo asks for a swap option with a revised fee and approval time, and a separate option to post the live clip later. Their venue already has a handoff date for the original teaser. They keep that teaser and defer the live clip rather than relying on an unconfirmed edit and review window.
How should you record the decision?
Use one change card beside the approved scope. In its scope change control paper, the Project Management Institute connects changes in scope to cost, schedule, and risk. For a small release team, a short card can keep those consequences visible. Mark the request pending, approved, deferred, or declined. When approved through the agreed channel, update affected tasks, budgets, owners, and dates. Share the new version with the people whose work changes.
What should continue while a request is open?
Confirm which approved tasks can safely continue and whether any task depends on the new decision. A pending clip request need not stop distribution checks. It may affect a post that would use the clip. Name who will resolve that dependency and by when. If the teams disagree on what is included or who can authorize a change, bring the written scope and approval history to the designated decision makers. Ask qualified music counsel about disputed terms or obligations.
Frequently asked questions
- Can the artist propose a scope change?
- Yes. Describe the requested change and ask for its effects on the agreed work, timing, and cost before scheduling it.
- What if the proposed replacement costs the same?
- Still check dates, approval load, and which output disappears. A cost-neutral swap can change what your release team receives.
- What if a new request arrives in a group chat?
- Capture the request in the shared record. Confirm the approval method in the agreement before treating a chat reply as authorization.
- Should the change card replace the original scope?
- Keep the original scope and the approved change together so the team can see what was revised and what still applies.
- What if the work was already due before the change came up?
- Track the original delivery issue separately, then decide whether a proposed replacement needs its own scope and approval review.