Editorial review: · Kalenderwoche.info
Project planning by week: use a rolling horizon
Week numbers make a project plan easier to scan, but they do not replace a deliverable or an explicit commitment. A useful weekly plan shows what should exist by the end of a week, what it depends on and who can accept it. A rolling horizon makes near-term work specific without pretending that distant weeks are equally predictable.
Connect each week to a verifiable deliverable
Describe the result before listing the activities. “Design phase” names a period, not a delivery someone can check. “Submit a design with three options for a decision” identifies what the recipient will receive. Agree who reviews it and which criteria determine acceptance.
Avoid assuming complete availability. Regular meetings, parallel work and absences reduce capacity. When a deliverable requires knowledge held by one person, that person's availability may be more important than the length of a bar on a weekly chart.
Plan the near term in detail and label distant assumptions
For the coming week, identify concrete actions, owners and expected results. Further ahead, milestones, dependencies and explicit assumptions may be sufficient. The appropriate level of detail depends on how quickly information and available capacity change.
Move the horizon forward regularly. Replace assumptions with known conditions rather than simply adding another week to an old plan. Distinguish a committed date from an internal target or a date that still depends on an outstanding decision.
Treat handover and acceptance as real work
The next person cannot necessarily use an output as soon as its creator considers it finished. Allow for handover, questions and acceptance. If a review must begin on Monday, agree which version of the material has to arrive beforehand.
Work backwards from the result that is needed. At each handover ask what input is required, who provides it, when the reviewer is available and who can decide in their absence. Adding another calendar appointment does not resolve a missing owner.
Include the ISO week-year at a year boundary
Use an identifier such as 2026-W53 rather than just “week 53”. The following ISO week is 2027-W01. In this fixed example, 2026-W53 runs from 28 December to 3 January and 2027-W01 begins on 4 January. A calendar-year change during a week does not create another project week.
Record the acceptance date separately. “Ready in 2027-W01” does not specify Monday, Friday or Sunday. Check weekends, public holidays and organisational closures independently: the ISO number does not establish that people are available to work.
Record the cause and impact of a change
When an input arrives late, do more than move the bar on the chart. Identify the downstream deliverable, whether its scope or date changes, and who confirmed the decision. Retain a trace of the previous commitment so that replanning is not mistaken for progress.
This short record is enough for an individual deliverable. Link to it from a weekly report instead of maintaining a second, potentially conflicting schedule in the report.
Deliverable and acceptance criterion:
Planned ISO week and specific date:
Owner / reviewer / decision-maker:
Required inputs and promised arrival:
Date status: commitment, target or assumption
Change: cause, impact and decision