A web project plan often looks like a tidy Gantt chart: coloured bars, a go-live date in red on the right, and everyone nodding at the kick-off meeting. Three weeks later the copy has not arrived, the supplier is waiting for access they never asked for in writing, and the date on the document stays the same because nobody dares to touch it.
I learnt to hold a schedule in television production, where the broadcast date does not move: you adjust everything else, never the date. Today I run short engagements on my own, designing and building things myself, and I build my plans the other way round: dependencies first, then durations, then dates. Here is the method, what it owes to the project management literature, and what it will not solve for you.
01What a web project plan should show before the dates
A plan answers three questions, in this order: who is waiting for what, from whom, and what moves if it does not arrive. Dates come afterwards, as a consequence. A plan that starts from dates answers a different question (when would we like to be done?), and it becomes wrong as soon as a single wait has been missed.
On a web project, the waits are many and rarely technical. Development waits for the approved mock-up. The mock-up waits for the content, or at least its structure. Go-live waits for acceptance testing, the domain name, the legal pages, sometimes a third-party service that has to open an account. Each of these arrows has an owner, and it is often someone outside the project team.
So what I want to see in a plan is a network rather than a list: tasks, arrows between them, and a name on every arrow. The Gantt chart can come later. It almost draws itself from that network.
02List the dependencies, including the ones that are not tasks
Managing project dependencies starts with one question, asked task by task: what must be finished before this one can start? It is the exercise Charles Jones describes in a Project Management Institute paper on moving from the work breakdown structure to the critical path. He stresses a distinction I find very useful in meetings: mandatory dependencies and discretionary ones, which are only the "normal way" of doing things. Many teams mistake the second for the first and stop themselves from running two workstreams in parallel.
On a website, the classic example is mock-up, then content, then development. Nothing forces you to wait for final copy before building the templates, as long as you know its structure and length. Nothing forces you to wait for the end of development to write the legal notices either.
Then come the dependencies that do not look like tasks. They are the ones that break the plans I see:
- a sign-off, because someone has to say yes and that someone has a diary;
- access: DNS, a hosting account, an analytics tool, a partner's back office;
- a document, such as an integration specification, brand guidelines or a redirect list;
- a decision between two options, or a budget call;
- a third party: a supplier, a software vendor, a legal team.
In my content machines I have a status for this: "on hold". It means a human decision is needed, and the machine never processes a topic in that state. I do the same in a plan. A task waiting on a decision carries the name of the person who has to make it and the date I need it by. Without that name, the wait stays invisible until the day it blocks.
03From backward planning to the critical path, step by step
Backward planning starts from the date that cannot move and works back in time. It is the right way to begin when the date is imposed on you: a launch, a trade show, a campaign already booked. But a backward plan on its own does not show where the danger is. For that you need the critical path.
Step 1: set the fixed date and what must be true on that day
I write in one line what has to be live on the date, and what can wait for a second release. This is the moment to cut, not three days before.
Step 2: list the tasks and their predecessors
One row per task, a verb and an object ("write the services pages", "set up the redirects"), and for each one what must be finished first. A spreadsheet is enough, with four columns: task, predecessors, owner, duration.
Step 3: estimate the durations
I come back to this in the next section, because this is where plans lie to themselves.
Step 4: find the critical path
The critical path is the longest chain of dependent tasks. Jones defines it simply: the activities with zero or negative float, which cannot slip without moving the end of the project. Scheduling software will calculate it, but on a web project of reasonable size you can find it by hand by following the arrows.
Step 5: work back from the fixed date
I place the critical path tasks starting from the date and working backwards. If the first one lands before today, the plan does not work as it stands: you have to cut scope, run a discretionary dependency in parallel or move the date. Better to know on day one.
04Estimate durations you can defend
A duration announced in a meeting is almost always too short. HM Treasury says so plainly in its guidance on optimism bias: project appraisers tend to be over-optimistic, and estimates of duration should be adjusted explicitly using data from past or similar projects. Bent Flyvbjerg, in his overview of behavioural biases in project management, lists the planning fallacy and optimism bias among the top ten, and identifies neglect of how comparable projects went as a primary reason projects underperform.
In practice, I do four things.
I ask for three estimates instead of one: if everything goes well, if the usual problems turn up, if almost everything goes wrong. The PERT method, which Jones goes through, combines the three into a duration that is usually a little longer than the most likely value. The real benefit is in the conversation: the person estimating can state their uncertainty without looking as if they are padding.
I convert hours into days using real availability. Jones's paper gives a telling example: 60 hours of work, for someone available 50% of the time, at 6.5 productive hours a day, comes to about 18.5 days, not the "week and a half" people quote off the cuff.
I pin down the unit. Is "ten days" ten calendar days, ten working days, or ten days of effort spread over a month? Until that question is settled, the number means nothing.
Finally, I keep slack separate from the estimate. Crispin Piney, in a PM Network article on critical path and critical chain, distinguishes float, which results from the dependencies, from a buffer, time deliberately allocated to absorb variation. I prefer one visible buffer, placed before the fixed date and checked every week, to margins hidden in every task that nobody can manage.
05Holding the plan when a dependency slips
There is always one dependency that slips. What matters is seeing it early and knowing what to do about it.
My first reflex comes from my content machines, where a check that did not run counts as a failure, never as a pass by default. In a plan, an unconfirmed dependency is late. "The copy is coming next week" with no date and no name is not a delivery.
Second reflex: check whether the late task is on the critical path. If it has float, I note it and carry on. If it is critical, the delay moves the end date, and a choice has to be made: use the buffer, cut scope, add someone, or announce a slip. That choice is not always mine. When it goes beyond my authority, it goes to the project steering committee, with the options written down.
Third reflex: version the plan. The calendar of my content machines is a versioned file, and changing the cadence means changing the planned dates, not rewriting the machine. For a plan it is the same idea as for an integration specification that changes at every meeting: a new dated version, with what changed, so everyone is talking about the same document. A plan changed quietly loses the team's trust within two rounds.
06What this method does not solve
It does not make an impossible date possible. It makes it visible sooner, which already counts for a lot, but someone still has to choose between scope and date. If you expect a plan to make that choice for you, it will disappoint you.
It does not replace scoping. If the site's goal or scope is unclear, the dependency network will be wrong from the start. That is why I do a short project scoping phase before drawing any plan.
It also has a cost: half a day with the right people around a spreadsheet, then regular chasing of external dependencies. On a very small site, built by one person in a few days, I do not run it in full. A list of the access and sign-offs to obtain is enough.
Last, the bottleneck is not always where you look for it. On one engagement, it was not production that slowed everything down, it was publishing, done by hand. The critical path showed me where to look. It did not tell me what to change.
07Where to start on Monday
Take your current plan and, for each task, write down what it is waiting for and from whom. Mark the waits that are not tasks: sign-offs, access, decisions. Find the longest chain, then compare its duration with the time you have left before the date that cannot move. If the gap is negative, you will know on Monday rather than the day before go-live, and acceptance testing before go-live will keep its place in the calendar.
If you would like an outside view on a plan in progress or one still to be built, it is part of the project direction work I do. Happy to talk it through.