Chapter 1: Projects Drift After Kickoff

A controlled start solves a specific problem. It gives a project a truthful beginning.

It does not create a permanent condition.

After kickoff, the environment changes quickly. A client sees the first real work and forms new opinions. A subject-matter expert introduces a requirement that was not visible during intake. A vendor date moves. A promised approval takes longer than expected. A team member becomes unavailable. A harmless clarification reveals a material scope question. Work that looked independent turns out to depend on one decision that nobody has made.

None of those events proves that the project was badly started. They prove that delivery is dynamic.

The mistake is treating the controlled start as if it were a sealed container that can be placed on a shelf once work begins. The final Client Start Position is the first controlled version of the delivery truth. Book 3 is about keeping that truth current as evidence changes.

The First Delivery Failure Is Often Loss of the Current Position

Teams tend to notice failure through visible outcomes: a missed deadline, a rejected deliverable, an angry client, an unexpected invoice dispute, a backlog that suddenly looks impossible. Those outcomes usually have earlier signals.

A decision was requested but never assigned a due point. A client said “we may also want” and the statement quietly became work. An action remained open for two weeks because it had no consequence. A risk was discussed repeatedly but never given a trigger. A status update remained green because the milestone had not yet been missed, even though the inputs needed to hit it were already late.

In each case, the immediate problem is different. The control failure is similar: the project no longer has one reliable current position.

A current position does not mean one giant document. It means the team can quickly answer the control questions that define the project state:

What outcome and scope are currently authorized?

What work is active, next, and waiting?

What commitments and dependencies affect the near-term plan?

What risks and issues require monitoring or action?

What decisions and approvals are outstanding?

What changed since the last agreed position?

What does the client need to know or do next?

What is the current acceptance state for material deliverables?

What is the current commercial and financial position of authorized work?

The Current Delivery Position

The product of the control system is not a tracker, a dashboard, or a weekly meeting. It is a reliable Current Delivery Position: a controlled representation of what the project is authorized to do, what is happening now, what is likely to happen next, and what requires a decision.

For Workflow Lift, the Current Delivery Position combines the minimum evidence needed to manage the engagement: authorized scope, active work permission, current forecast, open commitments and dependencies, risks and issues, pending decisions and approvals, approved changes, acceptance state, client actions, delivery capacity, and the commercial/financial position of the work.

The important word is current. A record can be perfectly accurate and still be operationally dangerous if it is no longer current enough to support the decision being made. That is why later chapters add evidence freshness, forecast credibility, and explicit update triggers rather than treating a saved record as permanent truth.

Every recurring control in this book should either read from the Current Delivery Position or write a meaningful state change back to it. Status reports read from it. Working meetings test it. Change decisions modify it. Escalations challenge it. Recovery reconstructs it. Closeout readiness confirms that it is stable enough to transfer into the next operating system.

This framing also creates a useful design test for tools: if a field, meeting, report, or approval does not improve the team’s ability to know or change the Current Delivery Position, its administrative cost should be questioned.

If those answers exist only in different people’s memories, the project is already harder to control than it appears.

Activity Can Hide Drift

Project drift is especially dangerous when the team looks busy.

A stalled project is easy to see. A drifting project may generate a constant stream of tasks, messages, drafts, meetings, and comments. Because work is moving, nobody wants to interrupt the momentum to ask whether the work still matches the authorized plan.

That produces four common illusions.

The progress illusion

The team completes tasks, but the tasks do not reduce uncertainty or move a controlled deliverable toward acceptance. Output increases while confidence in the outcome stays flat.

The agreement illusion

Stakeholders are friendly and responsive, so the team assumes they are aligned. In reality, different people are approving different aspects of the work or using different definitions of “done.”

The schedule illusion

The milestone date has not changed in the project tool, so the plan appears stable. The inputs required to hit that date are already late, and the forecast has become less credible even though the baseline has not moved.

The scope illusion

No formal change request exists, so scope appears unchanged. The team has accepted five “small” additions in meetings and chat. Each addition seems too minor to challenge, but together they alter the work and the review burden.

Control is the discipline of replacing those illusions with observable evidence.

Delivery Control Is Not a PMO in Miniature

Small teams often resist project controls because they associate them with enterprise governance: large schedules, complex risk matrices, mandatory templates, long steering meetings, and a reporting layer separated from the people performing the work.

That is not the model used in this book.

The Association for Project Management describes project controls as the practices used to manage scope, time, cost, risk, change, reporting, performance, decision-making, information, and associated communication. It also notes that on a small project the project manager may perform those controls directly rather than relying on a specialized controls team (Association for Project Management [APM], n.d.-e).

That observation matters. Control is a function, not an organizational department.

For a small client engagement, the control system may be one workbook, one project board, one weekly client status, and a disciplined meeting rhythm. For a larger engagement, the same control objectives may require separate logs, a schedule, financial reporting, and multiple owners. The amount of structure should change with the consequence of being wrong.

The minimum system must still be complete enough to expose material truth.

Seven Ways Projects Drift

Delivery drift tends to appear through recurring patterns.

1. Scope accretion

The project gains work one sentence at a time. “Can you also…” requests are accepted because each one looks small. The problem is not client curiosity. The problem is failing to classify the request before it changes the plan.

2. Decision debt

Questions requiring authority accumulate faster than they are resolved. The team keeps working around them until a late decision invalidates earlier effort.

3. Commitment decay

Actions are recorded but not controlled. Owners are vague. Due dates move without explanation. No one distinguishes a late action that is inconvenient from one that invalidates the next milestone.

4. Dependency blindness

The plan tracks the provider’s tasks but not the external inputs, access, reviews, or third-party events that make those tasks possible.

5. Risk normalization

The team repeatedly mentions the same concern until it begins to feel normal. A risk that should trigger a response becomes background conversation.

6. Reporting lag

Status communicates what happened last week rather than what is likely to happen next. By the time the report turns red, the decision window has already closed.

7. Recovery by optimism

When the project slips, the team promises to “make up the time” without changing scope, sequence, capacity, decision timing, or quality expectations. The recovery plan is therefore not a plan. It is a hope statement.

The Delivery Control Loop

The system in this book uses one recurring loop:

1. Establish the Current Delivery Position.

2. Authorize and release work within explicit permission.

3. Execute and observe evidence, variance, and acceptance signals.

4. Detect variance, risk, issue, change, and decision needs.

5. Preserve options and route the right authority.

6. Decide and record the authority/evidence.

7. Update scope, forecast, commitments, permissions, and commercial position.

8. Communicate the Current Delivery Position and repeat.

Figure 1.1 - The Workflow Lift Delivery Control Loop

The loop is deliberately circular. Delivery control is not a gate that the team passes once. It is the repeated work of keeping authorization, evidence, forecast, decision, and communication synchronized as conditions change.

Good Controls Preserve Options

The business value of a control is often the option it preserves before the option becomes expensive. An early scope classification preserves the option to decline, defer, phase, or price a request before the team performs it. An early decision warning preserves the option to resequence work before the milestone is blocked. A risk trigger preserves the option to act before the event becomes an issue. A credible forecast preserves the option to change course before the promised date becomes impossible.

This is a more useful test than asking whether the project has enough documentation. Good project control preserves choices while choices are still inexpensive. Weak control discovers the same facts after the project has already spent the time, money, goodwill, or capacity that would have made the decision easier.

Forecasting research provides a related warning. Optimism and the inside view can cause teams to over-weight the specifics of their own plan and under-weight the actual outcomes of comparable work. Lovallo and Kahneman (2003) and Flyvbjerg (2006) both argue for using an outside view or reference-class evidence to challenge optimistic forecasts. For a small service team, this can be as simple as comparing a new review cycle, migration, or launch against the last ten similar ones rather than assuming this project will be the exception.

Control Has a Cost

A control system consumes delivery capacity. Every field must be maintained, every meeting consumes attention, every approval adds latency, and every report creates preparation work. The objective is therefore not maximum control. The objective is sufficient control at a justified cost.

Use a practical principle: Control Value = decision and visibility benefit minus administrative cost. This is not a literal accounting formula. It is a design discipline. If no one uses a field to decide, authorize, forecast, communicate, or learn, remove it. If one shared register can preserve the evidence reliably, do not create five. If a meeting only repeats what the status already says, redesign or cancel it.

This principle becomes especially important when the toolkit is introduced. The tools in this book are modular. A small engagement should use the minimum complete set that exposes material truth, while larger or higher-consequence work may separate those controls into more specialized records.

The loop is intentionally approach-neutral. A predictive project may use a baseline schedule and change log. An adaptive team may use a prioritized backlog, short planning horizons, and frequent review. PMI’s current PMBOK Guide recognizes governance, scope, schedule, finance, stakeholders, resources, and risk as interconnected performance domains and emphasizes tailoring rather than one required lifecycle (Project Management Institute [PMI], 2025). ISO 21502 similarly applies across predictive, incremental, iterative, adaptive, and hybrid delivery approaches (International Organization for Standardization [ISO], 2020).

The Client Delivery System does not replace those methods. It defines the minimum control questions that should remain answerable across them.

Keep Six Control Questions Continuously Answerable

A delivery-control system is useful only if it reduces the time required to understand the current position and choose the next management action. The test is not whether the project has a board, register, meeting cadence, or status template. The test is whether the people responsible for delivery can answer the questions that govern work permission and consequence.

At any meaningful point in delivery, the control owner should be able to answer six questions without rebuilding the project from email and memory:

What work is currently authorized to proceed?

What outcomes or milestones are forecast next, and how credible is that forecast?

What commitments and dependencies can change that forecast?

What decisions, approvals, risks, or issues are constraining progress?

What has changed since the last accepted position?

What action, decision, or communication is required now?

These questions form a practical completeness check. A project may have hundreds of tasks and still be poorly controlled if one of these answers is unclear. Conversely, a small project may need only a handful of records if those records keep the six answers current.

The questions also prevent a common mistake: treating visibility as control. A dashboard can display twenty metrics and still fail to tell the delivery owner whether work may proceed, whether a decision is late, or whether a client commitment has become a schedule constraint. Useful visibility points toward a decision or action.

Distinguish Normal Variation From Delivery Drift

Not every variance is drift. Real projects contain ordinary variation: a task takes two hours longer than expected, a reviewer asks for a clarification, a dependency arrives one day early, or a team member rearranges the sequence of work. Control becomes expensive and distracting when every small variance is treated as an exception.

Drift is different. Drift occurs when the project position changes in a way that is not fully recognized, authorized, reflected in the records, or incorporated into the forecast. The danger is not merely that something changed. The danger is that the system still behaves as if the old position were true.

Use three tests when deciding whether a variance needs active control:

Consequence: could the variance affect scope, acceptance, cost, a material milestone, a dependency, or a stakeholder commitment?

Persistence: is the condition likely to continue, repeat, or consume remaining flexibility?

Authority: does the response require a decision or permission that the working team does not already possess?

A low-consequence, temporary variance within existing authority can usually be managed inside normal execution. A variance that crosses one or more of these tests should enter the appropriate control record. This proportionality prevents bureaucracy while keeping material changes visible.

Understand the Cost of Late Control

The later a delivery condition becomes visible, the fewer response options usually remain. An approval risk discovered two weeks before a review may be handled by moving the review, naming alternate authority, resequencing work, or protecting buffer. The same risk discovered after downstream work is blocked may leave only overtime, milestone movement, or scope tradeoffs.

This is why the system emphasizes triggers, decision windows, dependency dates, evidence freshness, and leading indicators. The objective is not to predict every problem. It is to notice changing conditions while the team still has choices.

When a control feels administrative, ask what option it is designed to preserve. A decision log preserves the ability to prove and act on authorization. A dependency record preserves the ability to intervene before waiting work stalls. A change record preserves the ability to choose among scope, time, cost, and priority. A forecast preserves the ability to act before a missed date becomes historical fact.

Controls that do not preserve an option, clarify authority, improve a forecast, or support a decision should be questioned. The goal is disciplined management, not paperwork accumulation.

Figure 1.2 - Six Questions of the Current Delivery Position

A healthy delivery system keeps these six answers current enough that the control owner does not need to reconstruct the project before acting.

Establish a Delivery-Control Rhythm

Delivery control works best as a rhythm rather than a set of records people remember to update when something goes wrong. The rhythm should be light enough to sustain and frequent enough to expose changes before they become expensive.

For a typical small or mid-sized client engagement, the rhythm may include a brief internal control scan early in the week, event-driven updates as decisions or changes occur, a client working checkpoint, and a weekly health/status review. Faster projects may compress the rhythm into daily checkpoints. Longer projects may use a two-week planning horizon with weekly control review.

The internal control scan should answer four questions: What changed? What is approaching a trigger? What decision or dependency could constrain the next seven to fourteen days? What record is stale enough to create false confidence? It should not become a meeting in which every task is read aloud.

Event-driven updates occur when the project state actually changes. A decision is approved. A risk trigger is crossed. A scope request is classified. A dependency is confirmed late. A client acceptance state changes. Waiting until the weekly status to record those events creates a gap between the real project and the recorded project.

The weekly health review then interprets the accumulated evidence. It is the moment to compare the current position with the prior position, evaluate trends, and decide whether normal control remains sufficient.

A useful rhythm creates multiple chances to detect drift without forcing the team to maintain everything continuously. The principle is simple: update facts when they change; review patterns on a cadence; escalate when a threshold is crossed.

Run a Current-Position Diagnostic When You Inherit a Messy Project

You may not always begin with a clean Client Start Position. If you inherit a project already in delivery, do not begin by creating every missing artifact. First reconstruct the current position.

Use a ninety-minute diagnostic if the project size allows. Gather the controlling agreement or scope record, current plan, latest status, open decisions, material dependencies, active change requests, and known risks/issues. Then ask the delivery owner and one or two key contributors the same questions independently: What is in scope now? What is the next material milestone? What could stop it? What are we waiting for? What has the client asked to change? What decision is overdue? What date do you actually believe?

Differences among the answers are themselves evidence. If the project manager says the launch is October 15 and the delivery lead says October 25, the first control problem is not the schedule. It is that the project has no shared current forecast. If the client believes six deliverables are included and the team believes five, scope control comes before task optimization.

After the diagnostic, create only the records needed to stabilize the highest-consequence gaps. The full delivery-control system can be built after the current truth is visible.

Know When Control Has Become Bureaucracy

A control system can become a source of delivery friction if it asks the team to maintain detail that no one uses. Watch for duplicate updates across several tools, fields that are completed only because the template contains them, meetings whose only purpose is to reconcile records, and approvals that do not correspond to real authority.

When that happens, do not abandon control. Remove duplication. Decide which record controls each subject. Reduce the level of detail. Automate transcription where appropriate, while preserving human verification for decisions and authorization. The objective is fewer, stronger control points.

A healthy system should make the project easier to explain and easier to manage. If the team spends more effort proving that the system was maintained than using it to make decisions, redesign it.

Figure 1.3 - Three Operating Modes of Delivery Control

Facts change on events, patterns are reviewed on cadence, and intervention increases when thresholds are crossed.

At the end of Harbor Home Services’ first week, Northline Studio’s client-start owner, Elena, closes the start phase. Marcus accepts ongoing delivery ownership.

The project is Conditionally Ready for the next phase because the Services-page copy remains open under a revised control. Discovery, workflow mapping, and page structure may continue. Final Services-page layout remains restricted until the copy condition is resolved.

Northline also has a documented change candidate: Harbor asked whether the inquiry form can connect directly to the scheduling platform. Integration was excluded from the authorized engagement. Marcus did not reject the idea and did not promise it. The request exists as a candidate that requires assessment.

This is a healthy transition. It is also the exact point where drift can begin.

During the second week, Harbor’s operations manager sends examples of scheduling problems and adds, “It would be great if the new site could just push these into the schedule automatically.” The marketing lead asks whether Northline can create two additional landing pages using the new design. A designer begins building the four approved page layouts. Marcus is waiting for the client owner to confirm a proposed workflow priority before the team can finalize the inquiry architecture.

Nothing is on fire.

But Northline now has three different control objects: an unresolved decision, a change candidate, and a new possible scope request. If they are handled as ordinary messages, the project will become less clear even while work continues.

Marcus therefore opens the delivery-control view. The current scope remains five approved pages plus workflow analysis. The scheduling integration remains a candidate, not authorized work. The two landing pages become a new scope candidate. The workflow-priority decision receives an owner, due point, impact, and escalation trigger. Unaffected design work continues.

The project has not become bureaucratic. It has become explicit.

When the Control Breaks: Nobody Agrees on the Current Position

Suppose you join Monday’s review and hear three different answers to the same question. The project manager says the launch is still October 15. The design lead says October 22 is more realistic. The client believes an additional page is already included, while the working team believes it is still a proposal. Do not begin by debating whose memory is correct.

First, stop making new commitments that depend on the disputed facts. Identify the subjects in conflict: forecast, scope, and perhaps work permission. Then locate the controlling sources for each subject and the most recent authorized events that may have changed them.

Second, reconstruct a single Current Delivery Position. Record the authorized scope, current forecast, material dependencies, decisions, changes, and work that may proceed. Where evidence is missing, mark the uncertainty rather than filling the gap with a preferred answer.

Third, identify what operational behavior must change immediately. If the extra page is not authorized, remove it from active production. If the current evidence supports October 22 rather than October 15, report the forecast honestly while keeping the baseline separate. If a decision is needed to restore a shared position, route it with a deadline and consequence.

Finally, determine why the positions diverged. The source-of-record rule may be weak, an approved decision may not have been propagated, or status reporting may have stayed unchanged while the working forecast moved. Correct that system defect so the project does not split into multiple truths again.

The objective is not to make everyone admit they were wrong. It is to restore one current, evidence-based position quickly enough that the next work and client communication are consistent.

Operating Playbook: Reconstruct and Maintain the Current Delivery Position

Use this sequence whenever you start a new control cycle, inherit an active engagement, or suspect that the project record no longer matches reality.

What good looks like: the delivery owner can explain the project in a few minutes without reconstructing it from email. The explanation is consistent with the plan, scope, decisions, and status, and the next management action is obvious.

Reader Practice: Diagnose a Recent Delivery

Choose one client project that is already past kickoff. Do not select the cleanest example.

For the last two weeks of work, identify:

one scope question or addition;

one delayed decision or approval;

one external dependency;

one risk that was discussed more than once;

one action that became late;

one forecast that changed before the official plan changed;

one client expectation that had to be restated.

For each item, ask where the current truth lived. Was it in a controlled record, in a meeting note, in email, in chat, or in someone’s memory?

Then identify the earliest point at which the team could have acted differently. The goal is not to score the project. It is to identify where delivery drift first became visible.

Chapter 1 Takeaway

A good kickoff does not create permanent alignment. Delivery creates new information, and new information changes the control environment.

The first responsibility of a delivery system is therefore not to produce more reporting. It is to preserve a truthful current position as work, decisions, risks, changes, and client expectations evolve.