1 Change Request Intake and Evaluation

Purpose and process

A Change request is a documented proposal to alter an approved project requirement, deliverable, design, process, schedule, budget, or other controlled item. Intake and evaluation help ensure requests are clear, traceable, and assessed consistently before a decision is made.

The process moves from recording a request, through preliminary screening and impact assessment, to an authorized disposition and ongoing tracking. A request should be recorded promptly, even if it is incomplete, so it remains visible and can be followed through closure.

Receive and document requests

Provide stakeholders with a defined submission route, such as a form or project-management system. Assign each request a unique ID and record it promptly, including when clarification is still needed.

A useful request record captures:

• Identification: ID, submission date, title, and current status.

• Origin: requester, organization, contact information, and affected users or stakeholders.

• Requested change: what should change, where it applies, and, when relevant, the current and proposed states.

• Reason: the need, problem, opportunity, or obligation behind the request.

• Context: affected requirements, deliverables, documents, components, versions, assumptions, and constraints.

• Requester’s view: desired timing, urgency, priority, and expected benefit. Treat these as input, not as the project’s final assessment.

• Attachments: supporting evidence, mockups, issue reports, or other material.

A request such as “Improve the report” is too vague to evaluate. “Add a CSV export for the monthly report so finance staff can reconcile it with the accounting system” identifies a proposed capability, where it applies, and its rationale.

Screen for completeness and suitability

Screening is a preliminary check, not a decision about whether a change is worthwhile. A designated coordinator or screener checks whether the request:

1. Is understandable: the requested outcome and reason are clear enough to investigate.

2. Is in scope: it concerns an item or outcome controlled by the project.

3. Is distinct: it is not a duplicate of an existing request or an issue already handled through another process.

4. Has enough information: affected items and context are identified, and there is a contact for clarification.

5. Has the right route: urgent incidents, safety concerns, defects, policy changes, or operational requests may need a separate or expedited process under project rules.

If information is missing, return the request for clarification or mark it pending information. If it is out of scope or a duplicate, record why and route it appropriately or link it to the relevant item. A requester’s urgency label does not authorize bypassing required review.

Assess impacts against criteria

Compare the proposed change with the Approved baseline: the controlled version of the relevant project plans, requirements, or products. Assess the effects of both making and not making the change. Match the depth of analysis to the change’s scale, uncertainty, and risk; a minor wording correction does not need the same study as a change to a safety-critical interface.

Use criteria established in the project’s change-control procedure. An Impact assessment commonly considers:

• Need and alignment: whether the request addresses a demonstrated need, supports approved objectives, or is required by a contract, regulation, or other obligation.

• Scope and requirements: which requirements, deliverables, interfaces, or controlled items would change, and whether dependencies or conflicts exist.

• Schedule and resources: the work, skills, sequencing, and availability needed, and whether milestones would move.

• Cost and value: estimated implementation and ongoing costs, expected benefits or savings, and how certain those estimates are.

• Quality and technical feasibility: whether the change can be implemented and verified, and possible design, performance, compatibility, or maintenance effects.

• Risk, safety, and security: new risks, reductions in existing risks, possible hazards, and effects on security or privacy.

• Stakeholders and operations: who would be affected and whether training, support, testing, or operational procedures need revision.

• Alternatives: whether a smaller change, workaround, or later release could meet the need.

Record evidence, assumptions, uncertainties, affected items, and the analyst’s recommendation. When estimates are uncertain, state a range or confidence rather than giving an unsupported precise figure. Requirements traceability, cost and schedule information, and risk records can help reveal consequences across the project, not only in the component where the change first appears.

Example of impact analysis

For a request to add CSV export to a monthly report, analysis might find that the feature supports reconciliation, requires a report-interface change and export testing, and can be completed within the current release if a lower-priority enhancement is deferred. It might also identify data-format and access-control questions that need answers before approval. Document these findings and uncertainties; the apparent benefit alone does not establish that the request should be accepted.

Prepare and record a decision

Prepare a decision-ready record so the designated authority can understand the proposal, its consequences, and available choices. Summarize:

• the request and its reason;

• the screening outcome and affected baseline items;

• impact findings against the project’s criteria;

• alternatives, assumptions, and unresolved questions; and

• a recommendation to approve, defer, reject, or request further analysis.

The Authorized decision-maker—not the requester or analyst alone—disposes of the request according to the authority defined by the project. Record the decision, its rationale, the decision-maker, and the date.

Maintain a traceable change log

Maintain a central Change log so the team can find each request and understand its history. At minimum, link its ID to the requester, submission date, brief description, affected items, screening or analysis owner, current status, decision and rationale, and key dates.

Use defined status values, such as received, screening, awaiting information, under analysis, submitted for decision, approved, deferred, or rejected. Update the record as the request moves through the process, and retain prior decisions and status dates rather than overwriting history.

Link the log entry to the detailed request and impact assessment so reviewers can find supporting evidence. The log provides traceability but does not replace those detailed records.