The Project Begins Before the Kickoff Presentation
A signed Statement of Work creates a commitment. Mobilization creates the conditions in which that commitment can be delivered.
The difference becomes visible quickly. Workshops appear on calendars, but the process owners cannot attend. Consultants have joined, but they cannot access the project environment. The sponsor expects an early demonstration, while the delivery team is still trying to locate the accepted requirements.
Everyone is busy, yet the implementation has not established a dependable way of working.
Chapter 7 defined the agreement the delivery team must be able to use. Chapter 8 begins Part III by turning that agreement into an authorized, staffed and practical start to delivery.
Mobilization is the third stage in this book's end-to-end implementation lifecycle, following Strategy and Business Case and Presales and Commercial Definition. It prepares the team for Discovery and the work that follows.
Its success is measured by readiness to perform that work, not by the number of onboarding meetings completed. The examples and sample plans in this chapter are fictional illustrations.
8.1 Understand the Purpose of Mobilization
Mobilization connects commercial commitments with day-to-day execution. It brings together the people, authority, information, access and controls needed to begin the implementation coherently.
It should answer five practical questions: What are we trying to achieve? What have we committed to deliver? Who will perform and approve the work? What do they need to start? How will the project make decisions and control progress?
A kickoff can introduce those answers, but the meeting cannot create them by itself. Much of the useful work happens beforehand through handover, resource confirmation and readiness checks.
The depth of mobilization should reflect the implementation. A small release with an established team may need a short preparation period. A multi-entity transformation involving several partners may need staged mobilization and early attention to long-lead dependencies.
Avoid making mobilization a fixed ceremony that every project follows identically. Define the evidence needed to begin the next stage and work backward from that evidence.
8.2 Confirm the Authority to Begin
Before assigning delivery work, confirm the approved scope, funding route, sponsor and authorization to proceed. Verify that the team has the executed agreement and the applicable schedules.
The project manager should understand the commercial start conditions, resource commitments and any unresolved approvals affecting work. An enthusiastic email or a calendar invitation should not be treated as a substitute for the organization's required authorization.
Where limited early work is approved, record its boundary, owner and spending or effort limit. The team must know which activities can proceed and which remain dependent on further approval.
Confirm the customer sponsor's mandate and the delivery leader's responsibilities. Who can authorize scope changes? Who can commit customer resources? Who can resolve competing business priorities?
Mobilization should remove uncertainty about those decisions. It should also identify where authority sits outside the project, such as enterprise security, finance or a central platform team.
8.3 Complete a Structured Presales-to-Delivery Handover
A proposal explains the offer. A delivery handover explains the reasoning, commitments and risks behind it.
Bring the presales lead, estimator, solution architect and incoming project manager together. Review the business case, accepted requirements, SOW, estimate, deployment approach and negotiation history.
Pay particular attention to assumptions that made the proposed schedule possible. A commitment to customer-led data cleansing or rapid design decisions needs an operational owner, not just a paragraph in the proposal.
| Area | Evidence and discussion |
|---|---|
| Business intent | Approved outcomes, benefit ownership and material operating constraints |
| Scope and commitments | Executed SOW, accepted clarifications, exclusions and deliverable acceptance criteria |
| Solution approach | Proposed architecture, standardization principles and unresolved design questions |
| Estimate and capacity | Effort basis, role assumptions, customer contribution and risk allowances |
| Deployment strategy | Release boundaries, locations, sequencing and reasons for the chosen approach |
| Commercial decisions | Milestone triggers, approved concessions and authorization limits |
| Open dependencies | Required inputs, responsible owners, due dates and consequences if delayed |
Walk through an end-to-end business scenario as well as the documents. This can expose differences between what the supplier demonstrated, what the customer expects and what the estimate actually includes.
Record handover gaps as actions with owners and dates. The incoming team should acknowledge what it understands and what remains unresolved. Handover is complete when the delivery team can explain the commitment and its boundaries, rather than merely confirm that a folder was shared.
8.4 Reconfirm Outcomes and Create the Project Charter
The charter gives the project a concise statement of purpose, authority and direction. It should connect the business problem to expected outcomes, scope boundaries, leadership responsibilities and major constraints.
It does not replace the SOW or amend the contract. The documents serve different purposes and should remain consistent.
For a fictional distributor, a business outcome might be more reliable inventory availability across two locations. The charter could identify the operations director as benefit owner, the current baseline as awaiting validation and the date by which the measurement method must be agreed.
Do not invent a benefit baseline to make the charter look complete. Identify who will establish it and how it will be measured. The business case remains the reference for the investment logic.
Keep the charter short enough for the sponsor and workstream leads to use. A clear statement of the intended operating outcome is more useful than several pages of broad claims about transformation.
Review it jointly so that business and delivery leaders begin with the same definition of success.
8.5 Confirm People and Real Availability
A name on an organization chart does not establish delivery capacity. Confirm each role's responsibilities, start date, allocation, relevant skills and availability during critical activities.
Customer participation deserves equal attention. Process owners, data owners, testing representatives and change leads may be expected to support the project while retaining their operational responsibilities.
Suppose a process owner can provide eight hours in a week. Two three-hour workshops and two hours of preparation consume that capacity completely. There is no remaining time for reviewing the outputs or making follow-up decisions.
The plan therefore needs an adjustment: additional protected time, a qualified delegate, operational backfill or a different workshop sequence. Scheduling more meetings does not solve the capacity gap.
Confirm deputies for important approval roles and explain the limits of delegated authority. A representative may describe the current process without being authorized to approve a future operating model.
Chapter 9 will examine team construction in depth. During mobilization, the immediate test is whether the people required for the first delivery activities are available and empowered.
8.6 Map Stakeholders Beyond the Project Team
Some of the most important implementation dependencies belong to people who are not assigned to the project.
Identify business-unit leaders, regional teams, security, enterprise architecture, infrastructure, procurement, finance, support teams and owners of connected systems. Establish which decisions or inputs each must provide.
A stakeholder map should capture influence, impact, information needs and the best engagement route. It should help the team act, not simply produce a colorful diagram.
For example, a central identity team may need advance notice to approve external consultant access. A warehouse manager may need workshop dates aligned with shift changes. An integration provider may have a release calendar that controls when testing can occur.
Make those constraints visible in the plan. Ask the relevant stakeholder to validate them rather than relying on an assumption made by someone else.
Early engagement also reveals concerns about the future operating model. Record them while the project still has time to shape communication and readiness activities.
8.7 Establish the Minimum Governance Needed to Work
Governance should make decisions easier to reach and easier to trace. Start by defining decision types, accountable roles, escalation routes and the forums needed to resolve them.
A workstream discussion may resolve a configuration question. A design authority may need to assess a cross-process exception. A steering committee may need to decide a material change to scope, funding or deployment strategy.
Define the boundaries between those forums. Escalating every issue to the sponsor slows delivery, while leaving commercial decisions inside workshops creates unauthorized commitments.
Set a practical operating rhythm: team coordination, workstream reviews, integrated delivery reviews and sponsor decisions. The frequency should match the pace and risk of the project.
For each forum, identify its purpose, required participants, decision authority and expected output. A meeting that produces no decision, action or useful shared understanding should be reconsidered.
Chapter 10 will develop governance and decision-making further. Mobilization must put enough of the model into operation for the team to begin.
8.8 Prepare Access, Environments and Working Tools
Create an access and environment readiness list tied to the upcoming activities. Identify who requests, approves, provisions and verifies each item.
Separate account creation from usable access. A consultant may have an account but lack the correct environment, permissions, network route or license to perform the assigned task.
Verify readiness through a representative action. Can the user open the approved repository, access the relevant environment and perform the permitted activity? Record the result and any restriction.
Use role-appropriate access and the customer's security process. Keep credentials out of shared project documents and track who owns account removal or access changes when people leave the team.
Identify the permitted data for demonstrations, development and testing. Use approved synthetic or appropriately protected data where required; production information should not become the default because it is convenient.
Also confirm ownership of development, test and production environments, including requests, maintenance and release controls. The complete technical strategy may develop later, but the team should not begin with an uncontrolled shared environment.
8.9 Establish One Controlled Place for Project Information
A shared repository is useful only if people understand where information belongs and which version is authoritative.
Define locations for the executed agreement, scope baseline, plans, requirements, designs, decisions, risks, deliverables and acceptance records. Use document identifiers and version conventions that the team can apply consistently.
Separate working drafts from approved baselines. A design under review should not look identical in status to one approved for build.
Choose the systems of record for work items and project controls. If actions are maintained in a delivery tool, a presentation should summarize them rather than become a competing action register.
Agree how workshop outputs are reviewed, how decisions are recorded and where approvals are retained. Chat messages can support discussion, but material decisions need a durable record with the decision, owner, date and implications.
Test the structure with an ordinary team member. If finding the latest approved scope requires asking three people, the repository is not yet serving the project.
8.10 Build the Initial Plan Around Dependencies
Mobilization should produce a credible near-term plan and an understood high-level route through the implementation.
Detail the next activities sufficiently to execute them. Include preparation, customer review, decision lead times and dependencies rather than showing only workshop dates and development tasks.
Use the agreed deployment strategy from Chapter 3 and the resource assumptions from Chapter 6. Carry forward the deliverables and acceptance points defined in Chapter 7.
An initial plan may still contain uncertainty. Show it honestly and identify when discovery will allow further refinement. A detailed date on an unsupported assumption does not make the plan dependable.
Check the business calendar: financial close, peak trading, audits, holidays, operational shutdowns and other transformation initiatives may affect availability or deployment windows.
Where a dependency threatens the planned start, identify safe work that can proceed independently. Reordering work can preserve useful progress, but it should not disguise a missing prerequisite for the affected activity.
8.11 Activate Risks, Assumptions, Issues and Dependencies
In this book, RAID refers to Risks, Assumptions, Issues and Dependencies. Maintain actions and decisions alongside these records, with clear links where they relate.
A risk is an uncertain event that may affect the project. An issue is a condition already affecting it. An assumption is a planning premise that needs validation. A dependency is an input or condition required from another activity or party.
| Type | Mobilization example | Useful next step |
|---|---|---|
| Risk | A key business specialist may be reassigned during discovery. | Agree protected capacity and a qualified deputy. |
| Assumption | The existing customer extract contains the mandatory source fields. | Validate a representative sample with the data owner. |
| Issue | Consultants currently cannot access the agreed test environment. | Assign an access-resolution owner and verify the fix. |
| Dependency | Interface assessment requires a specification from the external provider. | Confirm delivery date, owner and review activity. |
Each record needs an owner, relevant date and clear next step. Risks also need an assessment of impact and an appropriate response; dependencies need a required-by date and evidence of fulfillment.
Do not copy an entire proposal risk list into the register and consider the task complete. Review which entries still apply, which have become issues and which have been resolved.
Use the register in delivery discussions. Its value comes from decisions and action, not from the number of rows maintained.
8.12 Mobilize Data and Integration Work Early
Data and integrations often require inputs from teams with their own priorities and approval cycles. Starting their coordination only when build begins can leave the project waiting.
Nominate data owners, identify source systems and request representative extracts through approved channels. Confirm who can explain field meanings, quality problems, duplicates and reconciliation rules.
For integrations, identify system owners, technical contacts, available specifications, access processes and test-environment constraints. Establish an initial inventory even if detailed design will follow discovery.
The objective is to make investigation possible, not to finalize mappings before the business process is understood. Preserve that distinction when reporting progress.
For example, “sample received and reviewed” is useful mobilization evidence. “Migration design complete” would overstate the position if the target process and cleansing rules remain undecided.
Bring security and data-protection owners into the access and sample-data decisions when needed. Resolving these arrangements early supports better discovery without bypassing controls.
8.13 Prepare Discovery Before Booking the Workshops
An effective discovery workshop needs a purpose, the right participants, useful evidence and a defined output.
Map the first workshops to end-to-end processes. Identify the process owner, subject-matter experts, upstream and downstream participants, facilitator and person responsible for documenting outcomes.
Request representative transactions, current procedures, reports, pain points and known exceptions in advance. Explain what information is needed and how it will be used.
Provide a short pre-read that states the questions to resolve. A three-hour session should not begin with everyone discovering that they are discussing different entities or different parts of the process.
Separate business evidence from solution proposals. Users should be able to explain why a process exists before the team assumes that a customization is necessary.
Confirm how unanswered questions will be tracked and when decisions are needed. Discovery should produce reviewed findings and decisions that support later design, rather than an expanding archive of meeting notes.
8.14 Use the Kickoff to Establish Shared Commitment
The kickoff brings the business and delivery teams together around an understood direction. It should be practical enough that participants know what changes for them after the meeting.
Ask the sponsor to explain the business purpose and the support expected from leaders. Ask the project manager to explain the immediate plan, responsibilities and decision routes.
Walk through scope boundaries, major dependencies and the first delivery activities. Explain how concerns can be raised and how updates will reach the wider business.
Avoid presenting every future date as settled when the plan depends on discovery. Distinguish approved milestones, working targets and open assumptions.
Close with specific next steps: who attends the first workshops, what inputs they bring, which access checks remain and when the team will review mobilization readiness.
Publish the agreed actions and key messages promptly. Attendance at the kickoff is not evidence that every participant has accepted a responsibility; confirm important commitments directly.
8.15 Use a Short Mobilization Plan with Visible Outputs
A mobilization plan should identify activities, owners, dependencies and evidence of completion. Its duration should match the scale and readiness of the project.
The following ten-working-day illustration assumes authorization is in place and the initial team can start. It is not a universal timetable. Procurement lead times, access approvals or complex multi-partner arrangements may require longer.
| Window | Primary work | Lead role and completion evidence |
|---|---|---|
| Days 1–2 | Confirm authorization and complete delivery handover. | Project manager: executed baseline available; commitments reviewed; gaps assigned. |
| Days 2–4 | Agree charter, role commitments and stakeholder dependencies. | Sponsor and project manager: approved charter; confirmed allocations and decision owners. |
| Days 2–6 | Prepare repository, access and initial environments. | Platform and delivery leads: representative access checks passed; information locations published. |
| Days 3–7 | Build the near-term plan and prepare discovery inputs. | Workstream leads: workshop purposes, participants, inputs and dependencies confirmed. |
| Days 4–8 | Activate governance, RAID records and reporting. | Project manager: forums scheduled; records assigned; first decisions documented. |
| Days 7–9 | Hold kickoff and resolve remaining readiness gaps. | Sponsor and project manager: shared messages, confirmed actions and escalation outcomes. |
| Day 10 | Review readiness for the first discovery activities. | Designated gate approver: recorded proceed, conditional proceed or hold decision. |
Several activities can run in parallel, but their outputs still have dependencies. A workshop schedule cannot be considered confirmed until the required people have accepted their availability.
Track the plan by completed evidence. “Access requested” and “access verified” are different states. “Charter circulated” and “charter approved” also mean different things.
When a task slips, show which upcoming activity is affected. This helps leadership decide whether to provide support, change the sequence or move a commitment.
The plan should make the start manageable without becoming an administrative project of its own.
From the Delivery Floor
A fictional manufacturing customer and implementation partner hold an energetic kickoff on Monday. By Thursday, the team has discovered three problems: the production planning lead is assigned to a plant audit, external consultants cannot reach the test environment and the sample inventory extract has no confirmed business owner.
The status report still says “mobilization complete” because the kickoff occurred and the delivery team joined.
The project manager reviews the position against the first discovery activities. The planning workshop cannot achieve its purpose without an authorized business representative. The environment-dependent assessment cannot proceed without verified access. The data sample can be received, but its meaning and quality cannot be validated without ownership.
The sponsor assigns a qualified planning deputy and protects the lead's time for the decisions that cannot be delegated. The platform owner arranges access verification. The customer nominates an inventory data owner and agrees a date for the reviewed sample.
The team continues process-document review and other independent preparation. It reschedules the blocked activities and records the impact openly rather than reporting them as completed.
The recovery does not require a larger kickoff or a new set of slides. It requires the project to distinguish an announced start from an executable start.
That distinction is the central discipline of mobilization.
8.16 Review Readiness Before Moving into Discovery
Use a proportionate readiness review to confirm whether the next stage can proceed. It should examine evidence against agreed prerequisites, not reward the team for reaching a calendar date.
| Readiness area | Evidence to examine |
|---|---|
| Commitment | Authorized work boundary, current SOW and understood handover |
| People | Named roles, confirmed availability and appropriate approval authority |
| Process | Agreed decision routes, reporting rhythm and change-control responsibilities |
| Data | Named owners and approved access to the samples needed for initial discovery |
| Technology | Verified access to the tools and environments needed for upcoming activities |
| Plan | Executable near-term activities, dependencies and business-calendar constraints |
| Discovery | Prepared workshop inputs, required participants and defined outputs |
| Remaining conditions | Owned actions, dates, impact assessment and explicit approval of any conditional start |
The decision may be to proceed, proceed with explicitly accepted conditions or hold the affected activities. A conditional start needs a named owner, due date, impact assessment and clear boundary on what can proceed.
Do not use an overall percentage to conceal a critical blocker. Nine completed items out of ten may still leave the project unable to begin if the missing item is an authorized process owner for the central workflow.
Conversely, an incomplete low-impact administrative task does not necessarily justify stopping unrelated work. Apply judgment to the activity and its dependency.
Record the decision and remaining actions. Mobilization ends when the team can begin the authorized work responsibly, while carrying forward any accepted conditions visibly.
8.17 The Delivery Leader's View
The delivery leader looks for the gap between apparent readiness and operational readiness.
Can the team explain the business outcome? Are customer representatives available in practice? Can decisions be made at the required level? Have access and information been tested? Does the first week's plan produce useful evidence?
They also watch for early working habits. Problems hidden during mobilization are likely to remain hidden later. A team that can raise a constraint without blame is better positioned to address risks before cutover.
Mobilization establishes the tone for the implementation. Clear commitments, honest status and practical collaboration should be visible from the start.
The next chapter, Building the Implementation Team, develops the role and capability choices that sustain this readiness throughout delivery.
Chapter 8 Implementation Checklist
- Is the project authorized to begin within a clear scope and funding boundary?
- Does the delivery team have the executed SOW and controlled supporting schedules?
- Has presales explained the commitments, estimate assumptions and material concessions?
- Are business outcomes, benefit owners and baseline-validation actions understood?
- Are the sponsor, project manager and approval authorities confirmed?
- Have named team members and customer specialists committed realistic availability?
- Are deputies and delegated decision limits clear?
- Have stakeholders outside the core team validated their dependencies?
- Are the initial decision forums, escalation routes and reporting rhythm operating?
- Has required access been verified through representative actions?
- Are environment ownership and permitted project data defined?
- Can team members find current documents and distinguish drafts from approved baselines?
- Does the near-term plan include preparation, reviews and customer dependencies?
- Are risks, assumptions, issues and dependencies assigned to owners with next steps?
- Have data and integration owners begun providing the inputs needed for discovery?
- Do the first workshops have a purpose, prepared participants and expected outputs?
- Has kickoff communication resulted in confirmed actions and responsibilities?
- Has a readiness review recorded the decision to proceed and any accepted conditions?
If important answers remain uncertain, make the effect visible before promising that discovery is fully underway. Useful early progress depends on knowing which work is ready to begin.
Key Takeaways
Mobilization turns a signed commitment into an executable start to delivery.
A kickoff introduces the project; readiness comes from authority, people, information, access and working controls.
Presales handover must transfer the reasoning behind commitments as well as the documents.
Customer capacity and decision authority are as important as supplier staffing.
Project controls should establish a reliable way of working without unnecessary administration.
Data, integration and discovery preparation need attention before their dependencies become blockers.
Readiness should be demonstrated through evidence, with conditional starts managed explicitly.
Closing Thought
The quality of a project's start is measured by what the team can do after the kickoff.
When people understand their responsibilities, have the means to perform them and know how decisions will be made, the implementation has a foundation it can build on.
Mobilization creates that foundation—so that the promise made during presales can become disciplined delivery.