Organizational change scope is usually defined by identifying the business units, locations, roles and stakeholder groups affected by the transformation; assessing how processes, responsibilities, skills and ways of working will change; and translating those impacts into specific change-management deliverables such as stakeholder engagement, communication, role mapping, learning, readiness and post-go-live adoption support.
Change scope starts with implementation scope
The people-side work cannot be scoped independently of the solution. The project first needs a credible view of which processes, entities, applications, rollout waves and business capabilities are changing. That is why organizational change scope should connect directly to implementation scope and then become more detailed as design decisions stabilize.
A global finance rollout affecting twelve countries will not have the same change footprint as a limited technical upgrade. Even two projects with similar SAP modules can create very different impacts if one standardizes roles and approvals while the other largely preserves existing operating practices.
What is normally included in organizational change scope?
SAP’s organizational change management guidance covers a broad people-side lifecycle: change strategy, stakeholder and leadership work, communication, change-impact realization, enablement and adoption. SAP Learning also places detailed impact analysis, communication, organizational transition and training content across the SAP Activate phases rather than treating them as a single late-stage activity.
In a project scope, that commonly translates into six work areas:
- Stakeholder scope: sponsors, managers, process owners, key users, frontline users and other groups that can influence or experience the change.
- Change-impact scope: process steps, responsibilities, controls, organization structures, skills, behaviours and working methods that differ from today.
- Communication scope: audiences, messages, channels, timing, feedback mechanisms and ownership.
- Learning and enablement scope: role-based learning needs, content, delivery approach, practice, trainer model and user support.
- Transition and readiness scope: role mapping, local preparation, manager readiness, go-live communications and business-readiness evidence.
- Adoption scope: post-go-live support, adoption measures, reinforcement and improvement actions.
Change scope is not the same as “training scope”
A common under-scoping error is to assume that change management means creating training material shortly before go-live. Training is only one response to change. A new approval matrix may require sponsor decisions and manager communication. A redesigned shared-services model may require role mapping and organizational transition. A standardized process may create resistance that needs local stakeholder engagement before formal learning begins.
SAP’s framework explicitly separates change leadership, communication, realization and enablement, which reinforces this broader view. The project should therefore ask what business transition is required before deciding which interventions are necessary.
How consultants size the scope
The most useful sizing dimensions are breadth, depth and complexity. Breadth asks how many business units, countries, plants, roles and user groups are affected. Depth asks how materially work changes for each group. Complexity asks about language, culture, rollout waves, regulatory differences, union or works-council considerations, local leadership strength, prior change fatigue and the organization’s change capability.
Those dimensions should be reflected in deliverables, resource estimates and timing. A project with many countries may need localization and a distributed change network. A project with one location but a radical operating-model redesign may need intensive leadership and role-transition work.
Dependencies with other project workstreams
Change scope evolves with solution design, data, security and testing. For example, security scope can reveal new roles; data migration scope can create new ownership responsibilities; and testing scope identifies business participants who often become important readiness and adoption stakeholders.
For that reason, change-impact analysis should be refreshed as design decisions become concrete. SAP Learning describes detailed change-impact analysis in the Realize phase and uses the results to derive communication and support activities for affected user groups.
What a clear scope statement should answer
- Which organizational units, locations and rollout waves are included?
- Which stakeholder and user groups are in scope?
- What categories of change impact will be assessed?
- Which change-management deliverables will the project produce?
- What is owned centrally versus locally?
- Which languages and localization requirements apply?
- How will readiness and adoption be measured?
- What continues after go-live, and for how long?
- Which activities are explicitly out of scope or owned by the client?
Key takeaway
Organizational change scope should describe the business transition the project must enable, not just a list of communications and courses. Start with who is affected and how their work changes, then derive the stakeholder, communication, learning, readiness and adoption work needed to make the new solution usable and sustainable.