You have a schedule but don't know whether it's reasonable


You have a schedule but don't know whether it's reasonable. At the start of a project, any schedule will be highly speculative, particularly before the scope has been settled. However, as more unknown factors become known, any schedule should become more firm and reliable. This may not happen.


There are a couple of general problems that can cause more uncertainty than necessary in the schedule. An UndefinedScope, or ChangingRequirements that dont impact scope, are dealt with elsewhere. Changing requirements that impact scope are probably best dealt with as for IncompleteRequirements. What we deal with here is the problem of scheduling accurately when the requirements are known. However, in many cases, the approaches developed for use with IncompleteRequirements can be applied with satisfactory results. The reasons for this are given when dealing with a BadFitToSchedule using modern approaches.

Prevention, Amelioration, Cure


Do not try to add detail to a schedule further forward than you can reliably predict, or this will result in excessive re-work of the schedule. Early in the project very little can be reliably predicted; predictions must be based on known requirements and on ComparableWork. This can be particularly tricky while the workers are on the early stages of a learning curve for any reason. Reasons include newly formed teams learning how to work together, new processes, new technology, new business domain, new architecture, new almost anything else.


Modern Agile approaches replace the traditional schedule with a WorkQueue; XP uses a particular variant of this approach in the PlanningGame. One still needs to base ones estimates on ComparableWork, but the limits of planning ahead are recognised and the future work in the queue is estimated for effort but not slotted into a given sequence or time period. Sequencing by priority allows us to estimate end-dates for given scopes, or estimate scope for given end-dates.