You have a schedule but find it is unreasonable


Schedules are necessarily based on incomplete knowledge, and estimate the time it will take to complete work.  Earlier estimates are expected to be less accurate than later estimates.  With any inaccurate estimate, there will be a problem trying to fit work into that schedule.


It is traditional for customers to want to fix times of delivery and cost before they reasonably can be fixed.  It is not reasonable to fix both of these until scope and functionality are fixed, and until the architecture has been proved against its hardest challenges.  In addition to this, the process of development uncovers new requirements and the customer tends to add to the list of desired features (q.v. UndefinedScope).  It is rare for the schedule to be too lax, here it is assumed the schedule will be too tight.  A lax schedule can lead to complacency in the developers (q.v. ComplacentWorkers ). 


Brooks’ classic book “The Mythical Man Month” established limits to the approaches we can apply when faced with an unreasonable schedule, and since then, throwing more people onto a project has been regarded as an antipattern.  There is some hope that XP’s DevelopingInPairs (aka Pair Programming) may ameliorate (but not cure) this effect, but that remains to be proved.

Prevention, Amelioration, Cure


Traditional approaches arise from the fixed price problem where the Iron Triangle of resources, functionality and time cannot be broken.  It is common to push the resources to the limit by working excessive overtime, and still find the need to slip the schedule.  Competitive tendering on fixed price contracts makes this worse, because entering a realistic bid would often fail to secure the contract.  One of the few reasonable preventative approaches from the traditional school is to work time and materials until the architecture is completely specified, then fixed price thereafter.  This frequently leads to a split in responsibilities where the customer, or a specialist representative for the customer, produces a technical specification from which the developers work.


A measure of the fit to schedule can be obtained by the CompletionHeadroom pattern.  Where problems are foreseen, a WorkSplit may be made.  Where bad fits to schedule are discovered, thrashing over rearranging the schedule can be avoided by the TakeNoSmallSlips pattern.


The WorkSplit pattern comes from a relatively traditional background, but espouses a modern approach – prioritise the functionality and do the work on which high priority functionality depends first.  The WorkQueue develops this idea into something suitable for use with IterativeDevelopment, removing the need for detailed scheduling of anything but the immediate future.  The PlanningGame of XP takes this further.  Modern approaches allow for changing requirements, and deal with this by close contact between developer and customer.  Working from a Technical Specification is regarded as an antipattern.


Traditionally, adding more people to a project to correct a bad fit to schedule does not work because the bad fit is detected too late and the time needed to assimilate new people is too great.  There is some hope that both these causes can be addressed by, for example, a combination of the PlanningGame and DevelopingInPairs.