Change Control Process. Impact Analysis first or Submit the Change request first?

Mohammad Bozorgzadeh
Great question — and a common dilemma in project practice.

The PMBOK Guide (both 6th and 7th editions) does not prescribe a rigid sequence between impact analysis and the formal submission of a change request, because this depends largely on the project's governance structure and the change control system adopted by the organization.

However, there’s a key best practice principle:
- No change should be approved or implemented before its impact is understood.

In mature environments, the process typically unfolds in two stages:
- Preliminary logging of the change request — either informally or via an initial form, simply to document that a change has been proposed and needs evaluation.
- Impact analysis conducted by the PM or technical team — assessing effects on scope, time, cost, quality, risks, etc.
- Formal submission of the request to the CCB (Change Control Board) — now based on solid data and well-founded recommendations.

So, impact analysis occurs before any formal decision to approve the change — but it can be done after the initial registration of the request, even if that request hasn’t yet been formally submitted for approval.

This is also consistent with agile and hybrid governance approaches, where change may emerge iteratively, but is only incorporated into the baseline if it adds value and proves feasible.

Practical Summary:
- First: someone proposes the change →
- Then: PM analyzes impacts →
- Finally: formal submission for decision-making.

Thanks for raising this — it opens space for improving clarity and robustness in how change control is executed in many project environments.

Thanks Luis for clarifying.

In practice, can we consider it as this?

1. if the change need arises from PM or project team, first, PM must do the assessment and then submit the change request.

2. if the change need arises form different stakeholders (internal or external), they must first formally submit change request, then PM do the assessment and submit the result to the CCB, so they can decide.

Mohammad Bozorgzadeh, your clarification helps refine the scenario — and your distinction is valid as a practical heuristic.
Let me offer a slight refinement that may help generalize the approach while preserving flexibility:

1. When the change originates within the project team or PM:
Yes, in such cases, the PM (or delegated technical lead) usually does a preliminary assessment before escalating the change request.
This ensures that only viable, value-adding proposals are submitted formally.
The impact analysis may be light at this stage, depending on complexity, but it’s often enough to filter out noise or unjustified ideas.

Note: In most cases, the impact analysis is a collaborative effort.
The PM coordinates the assessment, but relies on input from technical leads, financial controllers, schedulers, or other subject-matter experts, depending on the nature of the proposed change.

2. When the change originates from external stakeholders (client, sponsor, users, etc.):
Correct — stakeholders typically must submit a formal or semi-formal change request, especially if it affects contractual scope, cost, or timeline.
Then the PM leads or coordinates the impact analysis, feeding this information into the change control process for decision-making (e.g., via the CCB).

Key Consideration:
What matters most is not who initiates the change, but when the impact analysis happens in relation to the decision.
The impact must precede any approval — even if the initial request was logged earlier for tracking purposes.

Suggested Practice:

Initial Logging: Any proposed change — internal or external — should be captured in a change log or register, even informally.

Impact Analysis: Performed before any decision is made, but can occur after logging and before formal submission.

Formal Submission: Occurs once the impact is known and the request is ready for evaluation by the appropriate governance body (e.g., CCB).

This logic also supports agile and hybrid governance, where change proposals are frequent, but only make it into the product or project baseline after validated learning and impact understanding.

Thanks again for moving the discussion forward — change control is a subtle but powerful discipline!