change request
Also called: change requests, scope change request
A short written request to change what the project delivers, when or for how much, stating the reason and what it costs in days, money or other scope. It turns "can we also…" into a decision someone makes on purpose.
A change request is a short written request to change what the project delivers, when, or for how much. Its job is not bureaucracy; it is to make sure every change is decided by someone who sees what it costs. Without it, changes arrive through side doors (a hallway chat, a message to one developer) and the plan quietly stops matching the work.
Lightweight change control needs four things. One door: every request, whoever it comes from, the sponsor included, reaches the project lead in writing. An impact note of a few lines: what changes, how many days, how much money, what else moves, and a recommendation; the numbers come from the people who would do the work, not from a guess. A named decider: the brief says who decides changes to the date, budget, scope boundaries and success criteria, and an agreed threshold lets the project lead decide small changes and report them. And a record in the decision log.
No committee is needed. A change board that meets monthly is too slow for a project measured in weeks; a single decider with a deadline for answering (say, two working days) is faster and clearer. If the answer does not come, chase it: silence is neither yes nor no, and waiting lets the calendar decide.
Not every request deserves the full route. Swapping the order of two tasks inside the same week is the lead's call. Anything that touches the fixed date, the money ceiling or the agreed scope goes through the door, however small it sounds.
Example
First week of January 2027, Klasna's physics launch. The marketing lead asks for a free trial physics lesson for every family on the waiting list. The project lead asks the people who would do the work and writes the impact note:
- What changes: about 100 free trial lessons before opening, plus a "trial" booking type.
- Money: each lesson still pays the tutor 430 UAH and costs 31 UAH of video and AI: 430 + 31 = 461 UAH. 100 × 461 = 46,100 UAH, out of 52,000 UAH left under the 600,000 UAH ceiling, leaving 52,000 − 46,100 = 5,900 UAH.
- Days: 4 of Danylo's days in January, which the schedule doesn't have.
- What else moves: the contingency for checkout problems almost disappears.
- Recommendation: no trial before opening; look again in March with real booking data.
The agreed threshold lets the lead decide changes up to two days of buffer and 10,000 UAH from the reserve. This request breaks both, so it goes to Leo, the sponsor, who answers in writing within two working days. Leo's own hallway idea, a progress page for parents, goes through the same door and gets the same note.
Common mistakes
- Side doors. A request that skips the written note enters the work with no one having seen its cost, sponsor requests included.
- Guessing the impact. Ask the people who would do the work for days and money.
- A committee for everything. Agree a threshold below which the project lead decides and reports.
- Treating silence as a yes. Chase an overdue decision; the calendar should not decide.
- Forgetting the record. Without a decision-log entry, the same request comes back as new in a month.
Learn it in the course
- Changes without a committee, and a decision log · Route every change through one door, write a short impact note in days and money, let a named person decide, and record each decision in a few lines.
- Case: the sponsor changes priorities every week · Leo wants a mobile preview one week and group classes the next. Find what is behind it, show each change's cost in days and money, and ask him to decide in writing.