“The schedule model simulates distinct scenarios and situations that predict milestones and completion dates according to the project’s actual and future data input by the project team. It is an important tool used for communication and managing stakeholder expectations.”
From Practice Standard For Scheduling, third edition, PMI
What do you find better? An ordered stack (a backlog) or a sequence of actives of varied length (a schedule)? Agile advocates the former, with waterfall we got used to the latter.
It’s easier to move items up and down in a stack. Rescheduling takes more time as you have to maintain logic (dependencies). On the other hand, a schedule allows us to see how activities relate to each other. Based on estimates – which are part of any schedule by definition – one can easily tell when to expect what. Of course, with relation to time a schedule is only a prognosis. The sequence in a schedule, however, provides value by itself – allowing the involved to see how tasks refer to one another. A work organization tool. And a useful one at that.
Lists focus on work in progress.
Schedules focus on relations and dependencies.
Lists draw attention to the work at hand.
Schedules show us how late we are, in addition to the above.
For a one-man band a list is fine. That’s my view. Where there’s teamwork involved, I prefer a schedule. And so do my customers – when asked, I can instantly tell them not only how much work remains (same goes for backlogs), but what the estimated duration is, and what the key milestone dates are.
I am in favour of new approaches. Sometimes a new approach is just a stepping stone towards something better. Better than schedules.
