Change Request

A project starts with an agreed plan, and new information can make a different design or delivery date desirable, so a change request brings that proposal into a review process. A fictional client asks a developer to add a reporting feature, and the team records the request instead of treating a conversation as immediate approval, then estimates effort and impact.

A useful request says what will change and why, including the current position, proposed outcome, requester, affected deliverables, any deadline and supporting evidence. A request is not itself an approved change, since the right decision-maker should accept, reject or defer it under the project's process and the approved baseline is updated only after that decision.

A fictional project manager receives a proposed design change and the sponsor declines it after reviewing the delay, so the original scope remains in force. A fictional operations team requests a new handover step because tests found an error, and it links the test evidence so reviewers understand the reason.

Impact analysis considers cost, schedule, resources, quality, legal duties and connected work, and a small-looking change can affect several teams, so ask the people who will deliver it. A fictional construction client asks for a different finish; the visible item is inexpensive, but late procurement moves the completion date, and the estimate captures both.

Change control does not mean refusing all change, because it makes tradeoffs visible and decisions traceable, PMI guidance emphasises scope definition, impact analysis and approval, and in a service setting a request may change a process or service level with the same questions applying. Some projects have a change board while others use one named sponsor, and approval authority should fit the contract and governance, so a team member should not assume authority from job title alone.

A fictional vendor's manager agrees verbally to extra work, but the signed contract requires customer approval by a named representative, so the vendor follows that process before treating the change as billable. A request may lead to a variation, new purchase order or amended contract, which is separate from the initial proposal, and a fictional consultant prepares a request for added workshops and schedules the new paid scope only after the client signs an approved fee variation.

Urgent safety work may follow a special procedure, but even then the reason, immediate action and later authorisation should be recorded so urgency does not erase the audit trail; a fictional facility finds a dangerous wiring issue, secures the area under emergency rules, and the contract team later processes the change under the agreed procedure. A change log tracks status, owner, date, impact and decision, which prevents requests from disappearing or being mistaken for approved tasks, and outcomes should be communicated to affected teams.

A fictional designer who sees a request marked "under review" does not replace the approved drawing yet, and a later decision changes the specification and version number. Version control matters after approval, so update requirements, budget, timeline and acceptance criteria together; a fictional project approves a new integration but does not update the test plan, and the manager catches the mismatch in change closeout.

A request can be rejected without being useless, as the recorded analysis may inform a later phase, but avoid quietly implementing rejected work through another channel. Measure the cumulative effect of approved changes and reforecast the whole project periodically, since a fictional programme that approves ten minor additions sees their combined test burden become significant, and a fictional startup that changes direction after customer feedback documents the revised target and the work it will drop.