Over the last week I have written a couple of articles addressing Web development schedules and how they are impacted by many factors including client responsibilities (see Avoiding the ‘Forever’ Web Project and 10 Client Responsibilities for Any Web Agreement). Along these same lines, one method that seems to work well is the sliding schedule.
Determining When a Web Project is Due
Many times Web development projects are driven by a launch date or at least a date by which the client wants the project completed. However, there are many factors that go into hitting this mark, and not all are in the control of the Web developer who is often tasked with creating the schedule. Often the developer will simply take the due date and work backward, slicing the allotted time into weeks or days, giving project milestones specific due dates. Though this works, typically better on paper than in real life, it doesn’t convey any consequences for missing a milestone.
‘Consequences’… Sounds Scary
I’m not talking about a reduction in pay, a beating, or worse. I’m talking about what a missed milestone does to the schedule.
- Does it mean that the developer has to work twice as fast to meet the final deadline?
- Does it mean that the deadline is pushed back?
- Does it mean that some elements are stripped out so as help make up time?
It could mean any one of these, my argument is that any agreement and project schedule should address this so that it is understood by all parties.
The Sliding Schedule
In a sliding schedule, we do not place project milestones on specific dates. Instead, give each millstone an amount of time to be met from the previous milestone. The initial schedule can be set up to meet a specific launch date but the idea is that consequences are clear if a millstone should be missed and the schedule never changes, it simply slides. For example:
First round design due May 21, second round design due May 28
First round design due 1 week after project sign-off, second round design due 4 business days from receiving client feedback.
You see what we did here. We moved 100% of the project schedule responsibility from the developer to being shared between the client and developer, both parties have clear responsibilities to the schedule. It is clear to the developer how much time they have to complete tasks, while it is clear to the client that their responsibility is to provide feedback in a timely fashion. If any point of the project were to be delayed, then the consequences are clear.