Project Scheduling: Six Steps for Dependencies, Capacity, and Dates

Project scheduling turns deliverables, available capacity, and dependencies into a workable sequence of dates. A list of preferred deadlines can hide double-booked people or missing approval waits. Start with outcomes and fixed constraints, separate effort from elapsed duration, and preserve the difference between the agreed plan and the latest forecast. The fictional release example below shows how.

Define Scheduling and Its Inputs

A schedule states when work starts, when it finishes, and what must be true before the next activity begins. Inputs include scope, completion conditions, owners, effort estimates, predecessors, review durations, and working calendars. Mark missing inputs as unknown, with an owner and a date for resolving them, instead of inventing precise values.

Use six steps: identify deliverables, check fixed dates, confirm resource capacity, estimate durations, test dependencies and slack, and maintain the change record. These steps form a loop. If the resulting duration does not fit the deadline, return to scope, assignment, or the commitment owner. There is no need for a rule that forbids looking at deadlines until late in planning.

Keep baseline dates distinct from current forecasts. Show unresolved assumptions as unresolved. A detailed schedule is useful only if someone can explain which changed conditions would move its dates.

Check Deliverables, Hard Dates, and Resource Calendars

Define the exit condition for each deliverable. “Build the landing page” may mean submitting a draft or completing review, revisions, and a release decision. Those scopes require different activities. Identify externally promised dates, event dates, and material availability at the start, including why each constraint is fixed.

An apparently free date does not ensure that the person with the required skills is available. External reviewers also have leave, opening hours, and other commitments. Check resource calendars instead of assuming one shared calendar, and watch for the same person assigned to parallel activities.

Do not remove unresolved decisions from the schedule. A contract decision may require gathering information, identifying an authorized decision-maker, and obtaining an answer by a certain date. If the outcome changes the workload, record that branch as an assumption or risk.

Separate Duration from Effort and Waiting

Effort measures labor; duration measures the span over which the activity occurs. Sixteen person-hours performed by one person for four hours per working day imply four working days in a simplified calculation. A second person can reduce duration only if the work can be split and coordination allows it.

Treat an approval window as elapsed duration separately from actual review labor. A two-working-day review window can include waiting for a reviewer’s turn. If the producer works elsewhere during that window, it is not automatically two additional person-days of production effort. Estimate any resulting revision work separately.

Microsoft’s explanation of scheduling calculations distinguishes work, resource assignments, duration, and calendars. Convert working duration into dates using the relevant calendars. A division result is not automatically a number of calendar days or a confirmed external delivery date.

Test Dependencies, Milestones, and Slack

Specify predecessors as conditions, rather than relying on row order. If implementation cannot start before requirements approval, retain that dependency. For partial overlap, identify what must be decided first and who accepts the risk of later changes.

Give milestones an acceptance owner, a version, and evidence. Completed activities do not necessarily mean release is authorized. The Microsoft guidance on the critical path helps distinguish the sequence affecting completion from activities with available slack. Not every delay necessarily moves the project finish.

Place contingency where uncertainty, external responses, and rechecks occur. Adding a universal percentage only at the end may not protect an intermediate fixed handover. Build an earliest feasible sequence, then work backward from the hard date to test feasibility. Return impossible scope, sequence, dates, or staffing assumptions to the decision owner.

Worked Example: A Twelve-Working-Day Release Plan

This fictional plan assumes required resources are available and uses numbered working days, excluding nonworking days. Activity C represents elapsed customer review, not two person-days of labor. The release decision takes place at the end of working day 12, provided its evidence is ready before the decision time.

The sequential durations total 2 + 3 + 2 + 4 = 11 working days, leaving one working day before the day-12 decision. If C takes three working days, D moves to days 9–12 and consumes that slack. Check whether decision evidence will be ready before the decision time on day 12. If same-day completion is insufficient, the release forecast is affected.

The one-day allowance is an outcome of the example, not a recommended standard. Leave or competing work changes the dates. Partial customer responses may permit some earlier work, but only after checking the safety and rework implications of that overlap.

Update Impacts, Decisions, and Schedule History

When a delay becomes known, preserve the original plan, current forecast, changed assumption, affected successors, and authorized decision. Do not erase slippage by overwriting the original date. While approval is pending, communicate a proposed change as a proposal with a response deadline.

Options can include splitting scope, finding qualified support, handing over a safe portion earlier, or renegotiating the date. Assess quality and additional cost as well as duration. Reducing production work may not reduce an approval queue, so match the response to the actual constraint.

Repeated delays in one place should change future duration assumptions, required inputs, or response agreements. Review whether changes were recognized early, their effects communicated, and decisions recorded. The number of date changes alone does not establish the quality of the planning process.

Separate actual completion points from remaining-duration estimates. Starting an activity does not prove half its duration is consumed. Forecast from the remaining deliverable and review conditions, since a percentage alone cannot show response queues or leave. Date and version the updated schedule, identify its authoritative location, and retain activity references when copying dates to personal calendars. At the weekly review, focus on changed assumptions and decisions required rather than reading every row.

Related practical guides

• Build a Gantt Chart in Excel or Google Sheets: Worked Table and Formulas
• How to Set Project Milestones: A Template and Acceptance Criteria
• Project Effort Management: Estimate, Track, and Review Actual Work

If you need to connect task progress with marketing plans and approved budgets, explore Xtrategy’s project features. Xtrategy keeps task progress within each marketing project, shows monthly plans alongside approved budgets, and links to related budget, CRM, and approval information.