Schedule Work Packages First, Not Tasks

Many authors describe how to build a good schedule. Their advice is all over the web. But they are startin on the wrong end of the problem.

• Start with a Plan, a strategy for successfully completing the project
• Define the deliverables of the project and the Work Packages that produce them
• Define the end to end duration of the Work Packages through some kind of Kaizen process where the team responsible for the Work Package comes up with the work contained in the Work Package and the end to end duration for that Work Package. This is a first cut estimate and not the final baselined schedule.
• Sequence the Work Packages in the order of increasing maturity for the deliverables. This means put the deliverables in an order that allows the project to proceed along a path of "increasing maturity" of the business value. This is classic agile process
• Revisit the durations and activities within the Work Packages to get all the work to fit within the "time box" of the expected outcome for the customer. If it doesn't fit you either have to get more time, more resources, or less deliverables

By the way a Deliverable is not a feature. A deliverable is a chunk of capability.

Process the top 10% of our supply chain in the new system is a Capability
The deliverables needed to enable this capability will likely include:

• A supplier management system
• An accounts payable components for those suppliers
• Some kind of inventory control system
• Some kind of work flow for the supply chain progression

Each of these deliverables may have some or more Work Packages

Only then start to detail out the schedule for the work inside the Work Packages. But try as much as possible to connect the Work Package "nose to tail," Finish to Start (FS) so that fully complete deliverables are used as input to the next work package. If you fail to do this, you'll be building down stream work on partially complete upstream product. This is call "rework."
    Finding the sweet spot for how big a Work Package shoud be and how to put them in the right order requires some experince and some experimenting. One of the strenghts of agile is the notion of time boxing the delivery durations (the itertaions). This is possible ONLY if there are in fact "time boxable" deliverables.
    In the end, never ever start with the schedule until you have a good idea of the deliverables and how they are going to appear as the passgae time.