Change Management Kickoff Checklist

How to start a change initiative when the organization is already changing

A change management kickoff checklist helps leaders connect a proposed initiative with the organization that must implement it. Before the initiative begins, its sponsor may understand what the project is expected to deliver. Operational teams, however, often face a different question:

How will this fit alongside everything else we are already carrying?

That question gives the change management kickoff a broader purpose.

A change kickoff is more than a meeting where leaders explain the project, introduce the team, and confirm the timeline. It is the point at which a proposed initiative enters the organization’s existing change system and becomes a governed enterprise commitment.

A useful change management kickoff connects four perspectives:

• The outcome the initiative is intended to achieve
• The operational conditions under which it must be implemented
• The other changes already affecting the organization
• The enterprise decisions required to begin responsibly

A change management kickoff cannot guarantee success. It can expose capacity conflicts, dependencies, unclear responsibilities, and competing assumptions before commitments become difficult and expensive to change.

Why a change kickoff is an enterprise decision

Organizations do not stand still while project teams prepare new initiatives.

Employees continue serving customers, operating systems, meeting regulatory requirements, resolving problems, and supporting other projects. Departments may already be adapting to new processes, leadership expectations, technologies, restructurings, or market conditions.

A new initiative therefore enters an organization already in motion.

Consider a distributor preparing to launch a customer portal. The sales operations team will support system testing, process design, and customer onboarding. The same team is also helping implement new pricing and preparing for an enterprise resource planning system upgrade.

Each project has allocated a modest amount of sales operations capacity. Viewed separately, the estimates appear reasonable. Taken together, the projects require more capacity than the team can provide during the busiest weeks.

A change management kickoff focused only on the portal’s milestones will miss the collision.

The resulting problem may not appear immediately. It may emerge later as:

• delayed testing;
• rushed customer onboarding;
• increased errors;
• managers working excessive hours;
• unresolved customer exceptions;
• declining support for one of the other initiatives;
• employees creating workarounds to keep normal operations running.

These are not simply project-planning problems. They concern enterprise priorities, shared capacity, operational risk, and the combined consequences of several initiatives.

Build the wider change picture before the meeting

The work required for an effective kickoff begins before participants enter the room.

The organization should first establish how the proposed initiative relates to the wider change environment.

This does not require a perfect enterprise dashboard. It requires enough connected information to identify the questions that must be answered before significant commitments are made.

The preparation should examine:

• Which teams and departments will experience the change
• Which active and planned initiatives affect the same areas
• When different demands will occur
• Which processes, technologies, customers, and resources are shared
• Where dependencies cross project or departmental boundaries
• Which operational risks could increase
• Whether the initiative supports current strategic priorities
• What previous organizational experience should influence the approach
• Which assumptions remain uncertain
• Which decisions require enterprise authority

Capacity should include more than the hours assigned to formal project work.

Operational units may also need time for:

• preparation;
• testing;
• training;
• practice;
• local process adjustment;
• communication;
• employee questions;
• exception handling;
• performance stabilization;
• customer support;
• correction of early implementation problems.

These activities often continue after the official launch date.

For a deeper discussion of combined change demand, see Change Saturation: When Change Demand Exceeds Capacity.

How the Change Office prepares the kickoff decision

A Change Office can help connect a proposed initiative with the organization’s wider change picture.

Before the kickoff, the Change Office may:

• identify the affected Change Units;
• review active and planned initiatives;
• surface capacity pressures and dependencies;
• identify customer and operational consequences;
• compare the proposal with enterprise priorities;
• examine previous experience and current signals;
• identify missing or conflicting information;
• prepare management questions and decision options.

During the kickoff, it can help participants:

• distinguish local implementation issues from enterprise questions;
• connect the initiative with related projects;
• recognize cross-unit dependencies;
• clarify which questions require governance authority;
• document assumptions, risks, and unresolved decisions.

After the kickoff, it can:

• integrate relevant signals into the wider change picture;
• track decisions affecting multiple initiatives;
• connect new operational information with leadership;
• support reflection and recalibration.

The Change Office supports the decision process. It does not replace leadership authority or centrally control every change initiative.

The function also does not require every organization to establish a separate department called a Change Office. Existing functions may already perform parts of this role, including:

• project or program management offices;
• transformation offices;
• portfolio management functions;
• organizational development teams;
• strategy functions;
• enterprise architecture teams;
• operational excellence functions.

The appropriate structure depends on the organization. What matters is that someone connects initiative-level planning with operational evidence and enterprise decisions.

For more detail, see The Change Office: Connecting Change Activity with Enterprise Decisions.

Connect the initiative to the complete GLCM Enterprise Architecture

The GLCM Enterprise Architecture connects the design of an individual initiative with operational implementation and enterprise decision-making.

At kickoff, four parts of this architecture become relevant.

1. The GLCM Model structures the individual initiative

The GRIFFOX Layer Cake Model™ helps leaders examine the initiative through five connected layers:

1. Foundation and Experience
2. Framework
3. Implementation
4. Recalibration
5. Goal

The kickoff begins primarily with the first two layers.

The Foundation and Experience Layer considers the context into which the initiative will enter:

• organizational culture;
• previous change experience;
• current capacity;
• existing systems and processes;
• leadership conditions;
• customer expectations;
• other initiatives;
• change readiness.

The Framework Layer establishes how the initiative will proceed:

• roles and responsibilities;
• methods and principles;
• decision rights;
• governance;
• evidence and measures;
• tools and resources;
• escalation and review arrangements.

The kickoff does not need to finalize every element. It should establish a workable starting framework and make unresolved assumptions visible.

2. Operational Integration connects the initiative with Change Units

A Change Unit is an organizational area that implements or experiences change within its own operating context. It may be a team, department, business unit, location, process area, or another meaningful part of the organization.

At kickoff, leaders should identify:

• which Change Units will be directly affected;
• which units will receive indirect consequences;
• where local adaptation may be necessary;
• which dependencies connect the units;
• where shared capacity is required;
• how operational experience will become visible.

The GLCM already connects change with operational units. Operational Integration makes dependencies, interactions, capacity pressures, and consequences across units and initiatives visible and manageable.

3. The Change Office integrates the wider picture

Information from projects and Change Units is often fragmented.

The Change Office can connect information about:

• priorities;
• capacity;
• dependencies;
• risks;
• customer effects;
• operational performance;
• acceptance;
• progress;
• unresolved decisions.

Its task is to identify patterns and prepare a coherent picture for leadership. This picture helps management see where an initiative fits, where it conflicts with other work, and which decisions must be made before proceeding.

4. Enterprise Change Governance decides

Enterprise Change Governance addresses questions that cannot be resolved within the authority of one project or operational unit.

These questions may concern:

• strategic alignment;
• organizational capacity;
• prioritization;
• sequencing;
• shared resources;
• risk exposure;
• customer consequences;
• decision rights;
• boundaries between initiatives.

Leadership can then decide whether to:

• start the initiative as proposed;
• narrow the initial scope;
• begin with selected Change Units;
• change the sequence;
• provide additional capacity;
• resolve a dependency before starting;
• combine the initiative with related work;
• delay the initiative;
• reconsider whether it should proceed.

The GLCM Enterprise Change Architecture connects operational signals with these enterprise decisions and returns strategic direction to projects and operational units.

Establish the business question and intended outcome

The kickoff should explain what problem the initiative addresses and what organizational outcome would justify the effort.

For the distributor, the business question might be:

How can customers place repeat orders with less effort while the organization maintains service quality and manages exceptions reliably?

This question directs attention to the entire customer and operational journey.

It invites discussion of:

• customer access;
• portal usability;
• pricing;
• credit control;
• order exceptions;
• fulfillment;
• customer service;
• operational capacity.

“Launch the customer portal” describes a deliverable. It does not establish whether the portal improves the customer experience or creates sustainable operational value.

The intended outcome should be specific enough to guide decisions but broad enough to include consequences outside the immediate project boundary.

Clarify the boundary without ignoring dependencies

Scope remains essential.

Recognizing a wider dependency does not mean that the project must absorb every connected problem. It means that the dependency must be understood and assigned.

For each significant dependency, the kickoff should determine whether it:

• belongs within the initiative;
• requires coordination with another project;
• needs an operational owner;
• should be monitored as a risk;
• requires an enterprise decision;
• should change the initiative’s timing or scope.

This prevents two common problems.

The first is uncontrolled scope expansion, where the project attempts to solve every organizational issue it encounters.

The second is artificial isolation, where important consequences are declared out of scope and then left without an owner.

A clear boundary explains both what the project will address and how connected issues will be handled.

Invite the people who can reveal consequences

A useful kickoff requires more than sponsors and project workstream leaders.

Include people who understand:

• the operational process;
• ordinary work and important exceptions;
• customer experience;
• shared systems and data;
• connected initiatives;
• resource and capacity constraints;
• compliance or risk implications;
• decisions affecting implementation.

Participation should be purposeful.

Some contributors need to join the central discussion. Others may provide information beforehand, attend one section, or review a specific decision after the meeting.

A large invitation list is not a substitute for the right perspectives.

Ask concrete questions:

• Which customer situations are currently hardest to handle?
• What manual work keeps the process functioning?
• What would fail if that work disappeared?
• Which other team receives the consequences when this process changes?
• Which employees or managers are already supporting other initiatives?
• Where do we depend on another system, process, or decision?
• Which assumptions are least certain?
• What are we likely to discover only during implementation?

These questions bring operational reality into the design while there is still room to adjust it.

Clarify change governance and decision rights

A project sponsor, project manager, operational owner, Change Office, and enterprise leadership carry different responsibilities.

The kickoff should make those differences understandable.

Project sponsor

The sponsor provides direction, organizational support, and accountability for the initiative within the approved enterprise context.

Project leadership

The project manager and project team manage delivery within the agreed scope, timeline, resources, and constraints.

Operational owner

The operational owner is responsible for the process, service, system, or capability that will continue after temporary project structures end.

Change Units

Affected teams and departments adapt and implement the change within their context. They observe operational effects and contribute relevant information.

Change Office

The Change Office integrates information, identifies patterns, analyzes dependencies and capacity pressures, and prepares decision options.

Enterprise Change Governance

Authorized leaders decide questions involving strategy, priorities, organizational capacity, risk, sequencing, and cross-unit boundaries.

The principle is straightforward:

The Change Office supports and prepares. Enterprise Change Governance leads and decides.

Unresolved decisions should be recorded with:

• the question requiring a decision;
• the accountable decision-maker;
• the information still required;
• the deadline;
• the effect of delay;
• the assumptions that apply until the decision is made.

An item labeled “escalated” can remain unresolved while teams continue under incompatible assumptions. A usable governance route must connect escalation with an actual decision.

Use evidence, signals, and previous experience

A kickoff should not depend only on confident presentations and stakeholder opinions.

Relevant information may include:

• operational performance;
• customer complaints and feedback;
• employee experience;
• capacity and workload information;
• lessons from previous initiatives;
• project and portfolio data;
• system constraints;
• quality and risk indicators;
• market or regulatory developments;
• information from related Change Units.

The GLCM Knowledge Architecture supports a disciplined approach to this information.

A metric, interview, observation, complaint, or project update becomes a useful signal when it is interpreted in relation to a management question, context, baseline, objective, or risk.

For example:

• A high workload measure matters when it affects a unit needed for implementation.
• Customer complaints matter when they reveal a process dependency the project may change.
• Previous project delays matter when they indicate a recurring approval bottleneck.
• Employee concerns matter when they challenge an assumption about the proposed workflow.

The purpose is not to create a large reporting exercise before every kickoff. It is to ensure that important decisions are supported by connected evidence.

The kickoff should ask:

• What do the numbers show?
• What are employees and customers experiencing?
• Where do these perspectives agree?
• Where do they conflict?
• Which information is missing?
• What does this mean for the decision to begin?

The 12-point change management kickoff checklist

Use this checklist to prepare and conduct the kickoff.

1. Define the business question

What organizational problem or opportunity is the initiative intended to address?

2. Define the intended outcome

What should become measurably or observably different for the organization, employees, operations, or customers?

3. Confirm strategic alignment

How does the initiative support current priorities, and which leadership commitment authorizes it?

4. Identify affected Change Units

Which teams, departments, locations, or business units will implement or experience the change?

5. Map concurrent initiatives

What other active or planned changes affect the same people, processes, systems, customers, or resources?

6. Test capacity

Can the affected units support preparation, implementation, practice, exception handling, and stabilization alongside normal operations?

7. Identify dependencies and consequences

Where does the initiative rely on other units, projects, systems, suppliers, or decisions? Where might it create additional work or risk?

8. Review evidence and previous experience

What do operational data, customer experience, employee input, prior initiatives, and leadership perspectives indicate?

9. Clarify scope and assumptions

What is included, what is excluded, and which uncertain assumptions influence the plan?

10. Assign responsibilities and decision rights

What belongs to the sponsor, project leadership, operational owners, Change Units, Change Office, and Enterprise Change Governance?

11. Establish signals, reflection, and escalation

How will the organization recognize progress, strain, changing conditions, and issues requiring a wider decision?

12. Record the first agreement

What has been decided, what remains open, who owns the next steps, and what conditions would require reconsideration?

Leave with a governed first agreement

A productive kickoff should leave participants able to explain:

• the business question and intended outcome;
• the initiative’s boundaries;
• the affected Change Units;
• the material dependencies;
• confirmed capacity commitments;
• roles and decision rights;
• open decisions and their owners;
• relevant assumptions and risks;
• the first implementation sequence;
• evidence and review arrangements;
• escalation routes;
• conditions that could change the agreement.

This agreement should be brief enough to use and specific enough to reveal disagreement.

Where information is incomplete, an explicit assumption is more valuable than vague consensus.

For the distributor, the first agreement might limit portal onboarding to one customer group while leadership resolves the overlap with the enterprise resource planning program.

That is not a universal rollout rule. It is an evidence-based management decision that protects capacity while testing the initiative under real operating conditions.

Reopen the agreement through reflection and recalibration

A kickoff establishes a starting agreement. It should not freeze assumptions that later evidence contradicts.

Conditions may change because of:

• new customer requirements;
• staff turnover;
• delayed dependencies;
• an acquisition;
• new regulation;
• technology problems;
• shifting enterprise priorities;
• unexpected operational consequences;
• another initiative requiring the same capacity.

GLCM’s recursive logic keeps reflection active throughout implementation.

Operational experience should return to the project, the Change Office, and enterprise leadership. At the Recalibration Layer, leaders can consider whether to:

• continue as planned;
• adjust the current approach;
• reduce or resequence activity;
• wait for a dependency or decision;
• return to an earlier layer;
• request an enterprise governance decision.

The original kickoff agreement remains useful because it shows what was assumed and why the initiative began as designed. New evidence can then be compared with that starting point.

Begin the initiative as part of the organization

A change management kickoff should accomplish more than launching project activity.

It should connect the initiative with:

• the organization’s current experience;
• the operational units that will carry the change;
• other initiatives already underway;
• the evidence needed for later decisions;
• the Change Office function;
• enterprise priorities and governance;
• the reflection cycles that will guide adjustment.

Before announcing the next project, ask the receiving organization what it is already carrying.

Then ask whether leadership can see how the new initiative fits into the complete change picture.

The quality of that conversation may change the timing, scope, sequence, or support the initiative needs. That is precisely why it belongs at the beginning.

About the Author

Harald Lavric is the founder of GRIFFOX Consulting and the creator of the GRIFFOX Layer Cake Model™. His work focuses on the connections among leadership, strategy, organizational change, operational responsibility, and enterprise decision-making. Drawing on more than three decades of experience in the German health-insurance system and work across public- and private-sector environments, he helps leaders make overlapping change more coherent, visible, and workable.