A project kickoff should settle what happens when things change

A kickoff can produce a room full of agreement while leaving the difficult decisions untouched. Everyone supports the objective. Nobody has settled who can move the date, what the supplier is entitled to assume or which team will absorb the work when a dependency slips.

I would spend less of that meeting presenting the plan and more testing it. The plan will change. The useful outcome is an agreement about how people will respond when it does, without making every adjustment an executive emergency.

Name the decision, then the authority

A sponsor's name on a slide does not describe decision rights. Separate the authority to recommend a change from the authority to commit money, accept operational risk or change a business process. Those decisions may belong to different people.

Write the boundaries in ordinary language. A delivery lead might be able to resequence tasks within the approved window, but not remove a control to recover lost time. A business owner might change a form's wording, but need finance approval before adding a paid integration. Delegation is useful when the person receiving it knows where it ends.

Include an alternate. If an approval depends on someone who is away, the project needs either a deputy or an agreed pause. Silence should not become consent because a supplier has booked its development team. Record the response time the plan relies on and the action taken if that time expires.

Make the boundary visible through an example

Consider a fictional project replacing an equipment request form. The agreed scope covers submission, manager approval and notification to the purchasing team. During the kickoff, someone asks whether it could also compare prices across suppliers.

That is a reasonable idea. It also introduces new data, commercial rules and a different maintenance burden. Calling it a small enhancement says little about its cost. The team should be able to describe which agreed outcome it supports, what work it displaces and who will operate it.

I would keep a short scope boundary beside the deliverables: purchasing decisions remain with the existing team; automated price comparison is excluded; requests still enter the current purchasing system. The boundary should identify what people can rely on, not provide a long list of reasons to refuse useful changes.

This is where acceptance criteria become helpful. If the original outcome was vague, almost any addition can be argued to have been implied. Observable acceptance conditions make that conversation less personal.

Agree how a change becomes a commitment

A change request does not need an elaborate form. It does need enough information to stop a suggestion becoming unpaid work or an invisible deadline extension. I would ask for:

• The problem the change solves and the consequence of leaving it out.
• The affected deliverables, dependencies and operating responsibilities.
• The available choices, including deferral and substitution.
• The estimated effort, uncertainty and decision deadline.
• The person authorised to accept the resulting trade-off.

Separate discovery from approval. A supplier may need paid investigation before giving a credible estimate. Agree a limit for that investigation rather than asking for certainty the team cannot yet provide. Conversely, approving an investigation must not be interpreted as approving the whole change.

When an estimate is provisional, say what could move it. An integration dependent on undocumented behaviour deserves a different confidence level from a label change. The decision record should preserve that distinction, especially when the budget later comes under pressure.

Put the organisation's work on the plan

The supplier's schedule is only part of delivery. Staff must provide sample data, explain exceptions, test outputs and approve process changes. Those activities compete with their ordinary jobs.

At kickoff, ask managers to confirm the capacity they are committing. If a business representative can only attend a short session each week, design the review cycle around that constraint. Do not leave a nominal full-time allocation in the schedule because it makes the dates fit.

Dependencies also need owners outside the project team. A network change, contract review or data cleanup should have a named decision route and a required date. Listing a dependency without checking its owner's plan merely records something to worry about later.

There is a trade-off here. Excessive detail at kickoff can slow useful discovery. I would settle the decisions that could create expensive commitments now and leave implementation choices to the people doing the work. The purpose is controlled flexibility, not a complete prediction of the project.

Leave with a record people can use

Finish by reading back the unresolved items. Give each an owner, a decision date and a statement of what cannot proceed until it is resolved. Circulate a short record that distinguishes agreed decisions from assumptions and open questions.

The next delivery meeting should test that record against reality. Has a promised reviewer become unavailable? Did a dependency change? Has a new request consumed the contingency? These are ordinary project events, but they need explicit consequences.

A useful kickoff leaves the team able to handle the first awkward request without reconstructing the agreement from memory. The sponsor may still need to make a hard choice. At least the choice will arrive with options and consequences rather than a surprise invoice or a date nobody can defend.