How Can a Project Schedule Move Forward One Condition at a Time?

A project schedule can fill up quickly.

Prepare in week one, execute in week two, finish in week three. Every row has a date, and every task has an owner. It looks as though the project already has a clear rhythm.

The work becomes more concrete when we ask a few more questions. What information is needed before execution? How far must the previous step progress before the next one can start? Who decides whether a deliverable is complete? If a critical condition is missing, does the original date still hold?

Without answers, a schedule can become a list of hopes. The dates get closer and everyone stays busy, while the project may have made little real progress.

I think a useful schedule needs to bring together target dates, conditions for progression, and evidence of completion.

Dates help us organize work. Conditions explain why we can move to the next step. Evidence allows everyone to check whether the current step is actually complete.

Connecting these three gives a schedule a practical management role.

1. Define “complete” before assigning a date

When planning, it is easy to begin with activities: prepare documents, discuss the proposal, arrange testing, and work toward delivery.

Those activities matter, but performing them does not yet define completion.

Does “documents prepared” mean the files have arrived, or that the relevant people have checked them and they support the next decision? Does “testing complete” mean someone opened the product, or that the agreed critical workflows were checked and the results recorded?

Different people can read the same task name differently.

My suggestion is to describe each important milestone in one verifiable sentence: what result should exist at the end of this stage, which conditions must it meet, and who confirms it?

For example, replace “finish the requirements discussion” with: the service scope, essential workflows, and exclusions for this stage are documented, and the designated owner has confirmed the version.

Define “testing complete” as well: check the critical workflows against the confirmed scope, record results and outstanding issues, meet the trial conditions agreed in advance, and obtain confirmation from the reviewer.

The date then refers to a deliverable that can be checked, rather than merely an activity that has taken place.

2. Make prerequisites visible so the sequence becomes clear

Whether a milestone can progress often depends on earlier conditions.

Some work needs a confirmed scope, some needs information, some needs resources, and some requires a decision by someone with the necessary authority.

If these relationships remain in a few people's heads, the schedule can show a great deal of “parallel work.” During execution, the people downstream discover that they have been waiting for something upstream all along.

For each important milestone, I would work backward with three questions:

• What inputs are needed to start this work?
• Which conditions are still missing for this stage to meet its completion standard?
• Who provides those inputs and conditions, and who checks them?

Then draw the dependencies.

Distinguish work that must happen in sequence, work that can run in parallel, and work that can begin after only part of an earlier task is complete. Condition-driven planning does not mean putting every task into one long queue. Independent work can continue, while blocked work makes its constraint visible.

Also distinguish “we have a document” from “this document supports this work.” If its subject, scope, date, or version does not match, more files may still leave the condition unmet.

Figure 1 shows the basic relationship behind stage progression. Dates remain under review, while actual conditions and deliverables must be checked before moving on. Define the relevant standards before the corresponding work begins.

Download Figure 1 as SVG

3. Keep three kinds of dates separate

Dates have different meanings too. I suggest recording at least three:

These dates may coincide, or they may diverge over time. The difference itself deserves attention.

If the current forecast is later than the target, the owner should explain which condition changed, what it affects downstream, and who needs to decide what happens next. Simply moving the old date leaves the underlying problem in place.

The actual completion date should not be entered solely because “the file was sent.” For stages that require review, submission and confirmation are different states, and the schedule should distinguish them.

When an external collaborator or another condition is not yet confirmed, record a reasoned forecast range, its assumptions, and the next review time. If there is no basis for an estimate, mark it as awaiting confirmation. Do not invent a date just to make the table look complete.

Established deadlines still need serious management. When the project is likely to miss one, promptly report the impact and address resources, scope, communication, and any proposed changes. “The conditions are not ready” must point to a specific issue and action, rather than remain an indefinite explanation.

4. Put a verifiable gate at important milestones

Reviewing every small activity through multiple approval layers can also slow a project. I would place checks at milestones that genuinely affect the next stage.

Five things can make the gate clear:

Prerequisites, deliverable, supporting evidence, owner, and reviewer.

The owner moves the work forward; the reviewer checks it against standards defined in advance. A small team can keep the arrangement simple, while still recording who confirmed completion and on what basis.

Evidence need not be a lengthy report. A confirmed scope list, reproducible test records, an acceptance note, or a delivery version agreed by both parties may suit a particular task. What matters is what the evidence establishes and whether it matches the completion standard in question.

Review itself also needs a response time. After submission, who checks it and when? How are issues returned? Who handles an overdue review? Without these arrangements, “waiting for delivery” can become endless “waiting for confirmation.”

I suggest using plain status labels first: not started, in progress, awaiting review, blocked, and complete. If a pause is needed, record the decision and what follows.

“80% complete” can also be useful, provided we explain what the percentage measures. Completing several easy tasks does not mean a critical condition is nearly satisfied. The project owner needs to see which remaining items will actually prevent the next step.

5. Separate the gap, its impact, and the required decision

When review finds a problem, do not immediately reschedule the whole project.

I would first distinguish three situations.

First, information or a deliverable is missing.

Describe the gap precisely: who fills it, to what standard, and when it will be checked again. Missing test records call for records; a defective critical workflow calls for a corrected deliverable. An explanatory note cannot replace work that still needs to be completed.

Second, the original approach or scope needs to change.

Assess the effects first: downstream dependencies, resources, costs, and external arrangements. After the authorized owner confirms the change, update tasks, conditions, and forecast dates, retaining the relationship between the previous and revised versions.

Third, a critical condition cannot currently be met.

A clear decision is needed: continue working toward the condition, redesign the route, pause, or stop. Each choice has different consequences. Submit the rationale and impact to the person authorized to decide.

For conditions that cannot be bypassed, a new date or an internal statement cannot replace the condition itself. Where scope can legitimately change, obtain confirmation through the appropriate authority and restate the applicable completion standards. Do not quietly lower the requirement and relabel the work “complete.”

Some blocked dependencies do not prevent other work from continuing. Identify that independent scope to reduce needless waiting, while avoiding further commitments built on an unconfirmed critical assumption.

Figure 2 presents one way to handle blockers. Evidence gaps, changes, and pauses have different routes. Updating a date does not automatically remove a blocker, and revised conditions still require review.

Download Figure 2 as SVG

6. A booking-service pilot shows how the schedule changes

The following hypothetical example was written to explain the method. It does not describe a real organization or project.

A small team is preparing a booking service and hopes to begin an external trial by the end of week three.

If its schedule only says “development in week two, launch in week three,” a completed interface can make the project appear almost finished.

Once the trial conditions are spelled out, several checks become visible: whether the trial scope is confirmed, the demonstration environment is ready, the booking and cancellation workflows meet the pre-agreed standards, and someone is assigned to receive and handle exceptions.

Testing reveals that canceling a booking does not correctly release the time slot. That directly affects subsequent bookings, so the original external-trial conditions have not been met.

The response can become a specific set of actions:

1. The development owner fixes the issue and submits a new version.
2. The reviewer retests the relevant workflows and records the results.
3. The project owner explains the target date, current forecast, and downstream effects.
4. Independent work, such as trial instructions and staffing preparations, continues.

If the team wants to begin with a smaller trial and manual handling, separately assess feasibility, limitations, and responsibilities. Obtain confirmation from the authorized person, then review the newly approved scope. A date arriving does not mean the original issue has been accepted.

In this process, “development submitted,” “retesting,” and “ready for trial” are three different states. Recording status separately from evidence lets collaborators know whether they can start their next step.

7. Start a stage-acceptance record with these fields

A schedule need not be complex at the outset. Make one critical stage clear first, then connect the stages before and after it.

For unresolved matters, record what needs confirmation and who will obtain it. If evidence is insufficient, identify the gap first and make the judgment once the basis is available.

A useful progress update tells collaborators where the work stands, why it is blocked, who acts next, and how the previous arrangements need to change.

Closing

I think the most useful part of a project schedule is the basis for progression behind each date.

Keep the target, assign responsibility, and address changing conditions promptly. Connecting prerequisites, delivery evidence, and confirmation makes the sequence easier to understand and gives adjustments a basis for discussion.

Next time you review a schedule, follow one critical milestone and ask: what is still missing before the next step, who will provide it, and who will confirm it?

Clear answers make it easier to move the work forward.