A three-stage process diagram for Organizational Change Management (OCM). Step 1: Document Review shows a professional analyzing a Project Charter and Strategic Plan with a magnifying glass. Step 2: Stakeholder Elicitation shows the same professional interviewing three stakeholders with speech bubbles representing process flows and gaps. Step 3: Validation shows the professional presenting a 'Scope Summary' to a group, where most stakeholders show green checkmarks and one has an amber question mark. At the bottom, a teal baseline labeled 'Foundation for Every OCM Deliverable' connects icons for Communications, Training, and Resistance Management plans.

Some Answers You Need About the Change Is Already Written Down Somewhere. Here Is How to Find It

May 02, 202612 min read

Introduction

Most change managers begin an engagement the same way. They schedule a meeting with the project sponsor, ask a set of well-practiced questions, take notes, and leave with a general sense of what the change involves. The conversation was useful. The sponsor was engaged. And the change manager now has enough to begin drafting a plan.

What they often do not have is the complete picture. The sponsor's account of the change is accurate but partial. It reflects their vantage point, their priorities, and their level of detail. It does not reflect the operational complexity sitting in the project charter, the strategic constraints embedded in the annual plan, or the scope gaps that will only surface when a department head who was never in that initial meeting hears what the change will actually mean for their team.

The project charter acts as the tool necessary to clarify the reasoning behind a project, the expected challenges, the associated authority to deal with those challenges, and some description of the escalation process. It is a lifeline for the change professional helping to guide the change journey. A change manager who reads and interrogates that document before they sit in front of their first stakeholder is not doing preparation work. They are building the foundation that every subsequent conversation will stand on.

Identifying the scope of change is not a single conversation. It is a three-step process that begins with documents, moves through structured elicitation, and is completed only when the data gathered from both sources has been formally validated.

Key Takeaways

  • Documents Exist Before You Arrive and They Contain What Stakeholders Forget to Say: Reviewing existing documentation including business cases, contracts, and prior initiatives is a foundational step in establishing a clear purpose statement and ensuring project goals are aligned with broader organizational priorities. A change manager who skips this step arrives at every stakeholder meeting starting from zero.

  • Defining the change and its scope means clearly articulating what will change, why it matters, and which parts of the organization will be affected. This clarity helps stakeholders understand the change's purpose and boundaries. Without it, every plan built on top is guesswork.

  • Elicitation Without a Document Baseline Produces Inconsistent Data: When a change manager goes into a stakeholder meeting without having read the charter, they ask generic questions and get generic answers. When they go in having read it, they ask specific questions and surface the gaps that matter.

  • Validation Is What Converts Data Into Knowledge: Information gathered from documents and conversations is not scope understanding until it has been tested against the people who will be responsible for delivering and living with the change.

  • Scope Is the Starting Point of Every OCM Deliverable: The change plan must identify what is changing, for whom, and when it will change. Every communication, training program, and engagement activity flows from the accuracy of that foundational definition.

What Does Identifying the Scope of Change Actually Mean in Practice?

Defining the change and its scope means clearly articulating what will change, why it matters, and which parts of the organization will be affected. In the professional practice of organizational change management, this means treating scope identification not as a preliminary step to be completed quickly before the real work begins, but as the analytical foundation that determines the quality and relevance of every OCM deliverable that follows it.

Scope identification in an OCM context covers three distinct dimensions that must all be understood before any plan is built. The first is the strategic dimension: why does this change exist, what organizational problem or opportunity is it responding to, and how does it connect to the broader priorities of the business? The second is the operational dimension: which processes, workflows, roles, and systems will look different as a result of this change, and in what specific ways? The third is the human dimension: whose daily work will change, how significantly, and what will be required of them in the new environment that is not required of them today?

Cultivating support for change while eliciting requirements requires proactively identifying potential skeptics in order to engage them early and address their concerns, which can only happen when the change manager has a sufficiently detailed understanding of the scope to know which groups face the most significant transitions. The change manager who cannot describe the scope across all three dimensions does not yet have the foundation to identify which stakeholders are most at risk, which communications need to be sent first, or which training interventions are most urgent.

Why Starting With Documents Before Conversations Changes Everything

It makes every stakeholder conversation more productive from the first minute. A change manager who arrives at a sponsor briefing having read the project charter, the business case, and the relevant strategic plan is not asking the same questions as one who arrives without that preparation. They are asking the questions that cannot be answered by reading, which are the questions that matter most: the human concerns, the organizational tensions, and the implementation realities that never appear in formal documentation. Reviewing existing documentation surfaces conflicts when they are easiest to resolve, and stakeholder alignment drives efficiency precisely because early involvement allows early course correction.

It surfaces the gaps between what was written and what is actually happening. Strategic plans describe organizational intent. Project charters describe approved scope. Neither document describes the gap between the two, and that gap is frequently where the most significant change management work lives. A change manager who reads both documents and then walks into a stakeholder meeting with specific questions about that gap will consistently surface material that would never emerge from a generic discovery conversation.

It protects the change manager's credibility in every subsequent interaction. Weak sponsorship, inconsistent communication, and lack of stakeholder buy-in remain among the most common barriers to sustained transformation results. A change manager who demonstrates in their first stakeholder meeting that they have done the foundational work, that they understand the strategic rationale, the approved scope, and the key dependencies, earns a level of credibility that accelerates every subsequent conversation. A change manager who asks questions that are answered on page three of the project charter loses it immediately.

It makes validation meaningful rather than performative. The final step in scope identification is validating the picture that document review and stakeholder meetings have produced. That validation is only as valuable as the quality of the data being tested. A change manager who brings a well-researched, document-grounded scope summary to a validation session is giving stakeholders something substantive to react to. A change manager who brings a collection of loosely organized meeting notes is giving them something to restate.

From Charter to Conversation: The 3-Step Framework for Identifying the Scope of Change

Step 1: Conduct a Structured Document Review Before Any Stakeholder Meeting

The document review is not passive reading. It is an active analytical exercise designed to extract specific information across the three scope dimensions and to generate a focused set of questions that the documents cannot answer.

  • What to do: Request and review the project charter, the business case, any relevant strategic or annual plans, and any existing process documentation for the areas the change will affect. Read each document with a specific lens: what is the stated rationale for this change, which organizational areas are in scope, what does the approved solution intend to change, and what are the known risks and assumptions documented by the project team?

  • Action: As you read, build a three-column working document. The first column captures what the documents say about the scope. The second column captures the gaps, inconsistencies, or ambiguities that the documents leave unresolved. The third column captures the specific questions these gaps generate for your stakeholder meetings. This working document is the bridge between your document review and your elicitation sessions.

  • Goal: Arriving at your first stakeholder meeting with a structured understanding of the documented scope and a prepared set of targeted questions that go beyond what any document could tell you. The process of reviewing existing documentation and aligning objectives with organizational strategy ensures that project goals support broader business priorities and that the scope boundaries established are realistic and defensible.

Step 2: Elicit the Undocumented Scope Through Structured Stakeholder Meetings

Documents describe the approved version of the change. Stakeholders carry the operational version, and the gap between the two is where the most significant OCM risks consistently live.

  • What to do: Structure your stakeholder elicitation sessions around the specific gaps your document review identified rather than around generic change management discovery questions. Each session should have a defined purpose, a prepared set of questions tied to a specific scope dimension, and a note-taking structure that captures responses in a format that can be directly compared to the document baseline.

  • Action: Use individual interviews to uncover implicit expectations, and collaborative workshops to stimulate alignment and surface latent needs. Surveys and structured questionnaires provide measurable input, particularly in large or multi-location initiatives where one-to-one interviews are not scalable across all impacted groups. In each session, ask specifically about the processes that will change, the roles that will be most affected, and the organizational dependencies that the project documentation did not capture.

  • Goal: A layered scope picture that combines the formal, approved version of the change captured in the documents with the operational, human, and cultural dimensions that only stakeholder conversations can surface. Every gap between the two layers is a potential OCM risk that needs to be incorporated into the change strategy before planning begins.

Step 3: Validate the Scope Definition With the People Responsible for Delivering It

Data gathered from documents and conversations is not scope understanding. It is scope hypotheses. Validation is what tests those hypotheses against the people whose cooperation the change depends on and whose daily reality will determine whether the scope definition is accurate enough to plan against.

  • What to do: Compile the scope picture developed through Steps 1 and 2 into a structured summary document that covers the strategic rationale, the operational changes by department and role, the key dependencies, the timeline, and the known risks. Present this summary to the project sponsor, the project manager, and at least one representative from each significantly impacted department.

  • Action: Assess organizational readiness by examining current workload, past change experiences, and cultural factors. This assessment reveals potential obstacles before they become problems and ensures the scope definition is grounded in the organization's actual capacity to absorb what is being planned. Treat every correction or addition that stakeholders make to the summary not as an error in your preparation but as evidence that the validation step is working exactly as it should.

  • Goal: A formally validated scope definition that every key stakeholder has reviewed, had the opportunity to challenge, and confirmed as an accurate foundation for the change strategy. The goals of this process are to define the change initiative clearly and communicate it to key leaders and stakeholders, creating the shared understanding that is the prerequisite for every subsequent OCM activity

Frequently Asked Questions

What if the project charter is incomplete or has not been finalized when I join the engagement?

Join the document review process anyway and work with what exists. An incomplete charter is still a source of valuable information, and the gaps it contains are themselves important data about the maturity of the project's scope definition. Document what you can confirm, flag what is missing, and make the incompleteness visible to the project sponsor as a risk to your ability to build a complete change strategy. An OCM plan built on an incomplete scope definition needs to be explicitly labeled as provisional until the scope is confirmed.

How do I handle a stakeholder who gives me information in an elicitation session that contradicts what the project charter says?

Treat the contradiction as a finding rather than a conflict. Contradictions between documented scope and stakeholder accounts are among the most valuable outputs of a thorough elicitation process because they surface misalignment that exists in the project regardless of whether it has been acknowledged. Document the contradiction accurately, present it to the project sponsor and project manager as a scope clarification requirement, and do not build your OCM strategy around either version until the discrepancy has been formally resolved.

How many stakeholders do I need to interview to have a sufficient picture of the change scope?

There is no universal number, but a useful principle is to continue elicitation until the sessions are no longer surfacing new information about the scope. When three consecutive conversations with different stakeholders across different departments produce the same picture with no new gaps or contradictions, the elicitation phase has likely reached sufficient coverage. In larger transformations, this may require a dozen or more sessions. In smaller ones, three or four well-structured interviews with the right people can produce a comprehensive scope definition.

What is the difference between scope identification for OCM and scope definition for project management?

Project scope definition focuses on the deliverables, milestones, and boundaries of what will be built or implemented. OCM scope identification focuses on the human impact of those deliverables: who will be affected, in what ways, with what implications for their awareness, acceptance, knowledge, and capability. The two are related but distinct, and a change manager who treats the project's scope documentation as a complete substitute for their own scope identification work will consistently build plans that address the technical change without adequately addressing the human one.

Final Thoughts

The change manager who understands the scope of change before they build a single plan is operating from a fundamentally different position than the one who builds plans while still discovering what the change actually involves. The three steps in this framework are not sequential tasks to be completed as quickly as possible before the real work begins. They are the real work, because everything that follows, every communication, every training program, every coaching conversation, every resistance management intervention, is only as effective as the scope understanding it was built on.

Read the documents first. Then ask the questions the documents cannot answer. Then validate what you have found with the people who will be responsible for making it real.

That sequence is not complicated. The discipline to follow it when the pressure to start producing deliverables is already building is where the professional development actually lives.

Reflective Question: Think about the last change engagement you joined. Before you produced your first deliverable, how many documents had you read and annotated? How many of the gaps your document review surfaced were then explicitly addressed in your elicitation sessions? If the honest answer is that you went to the meetings first and the documents later, you already know which step to reorder on the next engagement.

Get practical insights on change and business analysis delivered to your inbox. Join our mailing list

Pollard Learning is a professional training and consulting organization specializing in Business Analysis, Change Management, Project Management, and AI-enabled transformation.
We equip professionals and organizations with practical skills that drive measurable business outcomes.

Pollard Learning

Pollard Learning is a professional training and consulting organization specializing in Business Analysis, Change Management, Project Management, and AI-enabled transformation. We equip professionals and organizations with practical skills that drive measurable business outcomes.

LinkedIn logo icon
Instagram logo icon
Youtube logo icon
Back to Blog