Michael Flanagan posted a comment about how a 15K to 20K line project contained "way too much detail." The number of items in a project plan should represent the appropriate amount of detail (granularity) for the problem at hand. The problem I'm working on is very large, so 15K to 20K line items is probably about right. At this same time I'm working in another domain where a 200 to 300 line schedule is about right. CONTEXT and DOMAIN are the watch words that drive appropriateness.
Michael mentions "rolling waves," which leads me to believe he works in aerospace - where rolling waves a common. This approach lays out the end-to-end schedule at one level of graunlarity and defines the deatails at the current rolling wave. The future waves are called "Planning Packages" in many organizations. These contain budget, macro level deliverables, and macro level dependencies. But they do not contain the fine grained planning needed to execute them. The Planning Packages are place holders for future work, subject to change (rebaselining) when the current rolling wave either runs into trouble, is changed by the customer, or the programs itself changes.
How big is too big? Good question. How can we know? Another good question? Where I work tasks longer than 40 working days are highly discouraged. They cross two accounting periods. Level of Effort tasks are discouraged as well. Tasks less than 20 working days in a planning package need to have a good reason for being short. Small tasks in the current rolling wave need to define the dependencies that impact progress. So how many, how long, how many rolling waves, etc. is very business domain and technical context sensitive.
