An article by JoelSpolsky at
 http://www.joelonsoftware.com/articles/fog0000000245.html .  

(The previous link, http://joel.editthispage.com/stories/storyReader$31 , appears to be dead.)

The scheduling process Joel describes is similar to the ExtremeProgramming PlanningGame, although it presumes WaterFall-style development.  A few of the ideas presented are:

	* Only the programmer who is going to write the code can schedule it
	* Pick very fine grained tasks ("Your tasks should be measured in ''hours'', not days.")
	* Keep track of the original and current estimate
	* Never, ever let managers tell programmers to reduce an estimate

And finally:

	 :	'''A schedule is like wood blocks.''' If you have a bunch of wood blocks, and you can't fit them into a box, you have two choices: get a bigger box, or remove some blocks. If you thought you could ship in 6 months, but you have 12 months on the schedule, you are either going to have to delay shipping, or find some features to delete. You just can't shrink the blocks, and if you pretend you can, then you are merely depriving yourself of a useful opportunity to actually see into the future by lying to yourself about what you see there.
----
For those who'd prefer not to use Excel (as decribed in Joel's article) here is an XML/XSL version that can render in a web browser (Firefox/Opera/IE/Safari)
http://willcode4beer.com/design.jsp?set=sched
The idea is to spend less time playing with the schedule and more time working. Using a browser to render makes it more accesible and can simplify document control.
----

There is always the question of whether the blocks are of the right size. Many BigProjects seem to define one gigantic block of wood the size of an office building. No-one has a box that big.

If you can chop the blocks up small enough, you can be very clever about which ones go in this release's box, and which wait until the next. And if you make sure that each block represents a HorizontalStripe across the application, you can actually package up meaningful releases that real people can use.

Then, of course, there is always the option of grinding the blocks into sawdust and using an industrial press to force them to fit. <g> -- BillBarnett

----

My secret to scheduling in a government contract environment.

	1. Schedule the writing, review, and delivery of the required documentation.
	1. Identify the key features for a release.
	1. Do a rough estimate of the time for each key feature.
	1. Lay out the key features linearly and cut the key features falling after the end of the documentation schedule.
	1. Add a handful of low priority fill in features.

This provides your schedule.  Now to meet it

	1. Starting coding and documentation in parallel.
	1. Implement the key features in parallel as much as man power permits.
	1. Add or remove low priority fill in features to deliver the schedule on time.

''Someone noted that making documentation and coding parallel seems highly inefficient.  Some might argue that it's much more efficient to document that which is already coded, and which the documenters can see and use.''

The environment I am in requires much sequential formal documentation, and each document has its own review and approval cycle.  In theory, we are to produce a Functional Requirements Document, Test Plan, System Design Document, then begin coding, then produce a Test Analysis Report, a Release Contents Document, a User Manual, and then turn over the software for independent test.

The documentation takes 4 - 6 months to generate and get approved, assuming no development time.  The documentation effort really requires 1 - 2 people (3 in a pinch), and with a total staff of 9, I would have a lot of people sitting around surfing the web while the documentation is being produced.  My projects are tracked and funded based on the document deliveries; strangely, the software is not a contract deliverable.  

I don't claim this is the most efficient method of producing software, nor defend it, but this is the environment I must produce for.  I am sure there are a significant number of managers and developers in similar environments.