The change request arrives on a Thursday. Field 7, “Schedule impact,” reads Minimal — about two days. The requester filled it in honestly, measured against the release plan as they remember it from kickoff. The form is complete, the business case is sound, and it goes through. Across the hall, a developer drops three “while we’re in there” stories straight into the Fix Version. Those never become a change request at all.
Six weeks later the release is eleven days past its committed date, and the change log only accounts for two of them.
What a change request is for
A change request is a formal proposal to alter the scope, schedule, budget or deliverables of a project after the plan is agreed. A typical change request form asks for the requester, a description, a justification and an impact assessment. The change request process then runs submission, review, analysis, decision and implementation. In ITIL shops the same document is a request for change, routed through change enablement.
It is the front door of scope management, and it does that job well. Nothing walks through it unrecorded. The trouble is what the form asks a single person to know.
The schedule impact field asks the wrong person the wrong question
When your team committed to the release date, that commitment was a confidence vote: expert engineering judgment pricing a specific scope, against specific capacity, with specific dependencies in view. It was sound on the day it was cast. A change request reopens one of its assumptions, and the form then asks the requester to say what that does to the date.
Three things go wrong with that answer:
- It is measured against a baseline that already moved. “Two days” against the kickoff plan says nothing about where the committed date stands today, after every earlier approval.
- It is judged alone. Each request is small on its own form. Eleven small forms are not small, and no single form carries the total.
- It ignores the knock-on effects. A new scope item often brings a dependency on another team, or pulls the one person who knows the code off other committed work. Those are the other two of the three things that erode a committed release date, and the form has no field for them.
Most scope never files a change request
The bigger gap is the scope that never reaches the form. Stories split in refinement. Bugs found in testing get tagged to the release. A “small ask” is folded into an existing ticket. None of it is dishonest, and none of it is governed. The change control board sees the requests that were filed. The release absorbs everything else.
So the change log and the release drift on separate tracks. The log says two days. The date says eleven.
Price the change against the date, not the form
Advanced Release Planning for Jira keeps the committed date next to a live forecast. Monte Carlo simulation runs on your team’s own Jira delivery history and draws a 50/85/95% confidence band around the release. The team still owns every assumption: which throughput window is representative, whose capacity counts, what belongs in scope. The app does the arithmetic at a scale no meeting can, and keeps it current.
For a change request, that changes what goes in the schedule impact field:
- Before the decision: add the candidate work item to the release and the forecast re-runs. The movement shows in days, at the confidence level the team committed at, attributed to scope.
- Across decisions: the change history against the committed date accumulates every approval, so the twelfth request is priced on top of the first eleven.
- For the side door: the forecast reads the Fix Version, not the change log. Scope that arrived without a request is counted the next time the forecast runs and shows up in the same scope attribution.
“Minimal — about two days” becomes “four days at P85, eleven days cumulative since commitment.” That is a number the requester, the board and the delivery team can all read the same way. It feeds straight into a change impact analysis without anyone re-deriving it.
An illustration, not customer data: a release committed for 14 November at P85. The one filed change request adds two days. Side-door scope adds nine more. The release moves from on-track to attention once the committed date falls inside the P50–P85 range of the band. That status change, not a missed milestone, is the cue to renegotiate: trade lower-ranked items below the MoSCoW cut-line, adjust capacity, or re-commit to a new date with its confidence stated.
Keep the form. Change the field.
The change request process is worth keeping. It records who asked, why and who agreed. What it cannot do is hold a live date. Replace the free-text schedule impact with the reading from the forecast, and every request arrives with its real price. The team can still say yes. It just says yes knowing the cost in days. The renegotiation and change-request reference doc lists which change request fields the app can supply and which it cannot.
Key takeaways
- A change request records a proposed scope change. Its schedule impact field is usually one person’s view against an outdated baseline.
- Requests are judged one at a time, and much scope enters a release without one.
- A live forecast prices each change in days at the team’s committed confidence level, and counts unrequested scope the same way.
FAQ
What is a change request in project management? A formal, documented proposal to change agreed scope, schedule, budget or deliverables, reviewed and approved or rejected before the change is made.
Does Advanced Release Planning replace our change request form? No. It has no change request form or approval workflow, and it does not assess cost, quality or risk. It supplies the schedule reading for the form: the committed date’s position with and without the change, in days.
Give the next change request its real price
Before the next request is approved, see what it does to your committed date. See the committed date and its live confidence band in Advanced Release Planning, or try it on your own Jira data from the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.