A project is set up to deliver a PDF guide. Someone asks for an HTML reading edition as well. Writing “add a web version” in the meeting notes leaves the team guessing which work, review and delivery records need to change. Put the request beside the current scope before anyone replaces the plan.
A useful change request form preserves the original commitment and makes the proposed difference inspectable. The completed fictional request below adds one HTML edition while keeping the PDF deliverable. It includes a document-impact list and an effort estimate; actual cost, dates and authorization remain blank.
Open the complete example · Download the full HTML source
Identify the version being changed
Start with a request ID, project name, requester, date and reference to the current scope. Attach or link the exact version under discussion. A link to a document that keeps changing may need a retained version or dated export so a later reader can reconstruct the request.
Our original teaching case is CR-07 for the Visitor Guide project. Scope-v1 describes one eight-page PDF, one consolidated review round and an estimated eight person-hours. Delivery-list-v1 lists the PDF only. Review-checklist-v1 covers the PDF. These are fictional source records, not an actual customer's approved plan.
The requester and date are unfilled. In your own copy, identify the maintained baseline and its actual approval reference. If the starting terms are still a proposal, say so rather than presenting them as authorized work. The project charter template helps establish who can decide; this form carries the particular change to that decision owner.
Write the requested difference as a deliverable
CR-07 requests one self-contained HTML reading edition using the same guide text, alongside the existing PDF. The stated reason is to let reviewers inspect the guide in a browser. No hosting, editable content service or ongoing maintenance is included in this proposal.
Keep “what stays” beside “what changes.” The PDF remains a deliverable. The source text remains the same. The additional file needs its own layout and review work. One review round remains the proposed allowance, with both formats included in that round. A reviewer can now question that allowance without guessing what “web version” meant.
The Association for Project Management's change-control guidance separates recording and evaluating a request from the later decision and plan update. Its evaluation considers effects on scope, time, resources, costs, quality and other relevant criteria. Use your organization's required process and fields when preparing the actual request.
Connect each impact to a record
The example identifies three records that would need revision if the request were authorized:
- Scope-v1: add the HTML file, its boundaries and review allowance.
- Delivery-list-v1: list both deliverables and their maintained file references.
- Review-checklist-v1: add checks for readable headings, working internal links and the agreed desktop and phone layouts.
These are proposed checks, not results from a completed guide. Record dependencies too: the guide text must be ready for layout, and someone must review both formats. Actual reviewer availability is unknown.
An extra three person-hours does not establish a three-hour delivery delay. This fictional estimate adds two hours for HTML layout and one hour for reviewing it. Eight baseline hours plus three additional hours gives eleven proposed person-hours. Calendar dates depend on availability and sequencing. Leave the delivery effect unresolved until those facts are supplied. No hourly rate is provided, so there is no calculated price.
Give the decision owner usable alternatives
Include the option to retain the PDF-only scope and defer the HTML edition, as well as the proposed addition. Explain the consequence of each: the first keeps the current deliverable set; the second needs the added effort and review arrangement. Do not mark either option accepted because it appears in the request.
The worked request's decision, decision maker, date and authorization reference remain empty. After a real decision, record what was decided and link the resulting document versions. Keep the original scope and request history available. For work already observed to be wrong, use an issue log to record the problem; connect a separate request when its resolution would change the plan.
Prepare your own request copy
Prepare a change request document from the supplied records.
Current scope/version and actual authorization reference: [PASTE]
Requested change, reason and requester: [PASTE]
Deliverables retained, added or removed: [FILL IN]
Affected documents and proposed revisions: [PASTE]
Effort estimates, units and assumptions: [PASTE]
Known cost, availability and schedule evidence: [PASTE]
Alternatives and decision route: [PASTE]
Show current terms beside proposed terms. Separate supplied facts,
estimates and unresolved fields. Calculate only from supplied inputs.
Preserve the original versions. Leave actual decision fields empty
unless a decision record is supplied. Return an editable Markdown
request and a self-contained HTML reading copy with the same content.
The example's Markdown files provide a filled request and an empty form; the HTML provides a readable comparison for a NOS review copy. Reviewers should be able to trace every proposed revision back to CR-07. Before sending your own request, replace the fictional source records and settle who will record the actual decision.
Download the filled change request · Download the blank change request