Almost every project Schedule I've seen in the commercial and sometimes in defense are horizontal "shop floor" schedules. This means work flows from left to right, progress is measured by the percent complete bar getting blacker, and the task bars organized by function - design, code, test, deploy.
This approach to scheduling has several issues:
- There is no way to see how the project's deliverables are maturity
- There is probably no specific statement of what the deliverables are
- The critical path is likely the simple path with zero slack
Here's the first step in move away from this approach and undesirable outcomes.
Build a sequence of the Work Packages that produce outcomes. These outcomes can be final outcomes or intermediate outcomes that are needed to produce the final outcomes.
The Work Packages produce a 100% completed outcome - even if this outcome is incomplete for the final outcome. It is 100% complete for the Work Package. This approach has the smell of an agile development approach. Except that there is a "plan" for all the Work Packages.
There are two kinds of Work Packages:
- Ones that are being worked on now - in the current "rolling wave." The notion of a rolling wave is that we can't see that far into the future, so why waste time trying to plan in detail. Instead plan at a level needed to see what work is needed to complete the project. The duration of the active Work Package will be finer than the Planning Packages. Remember these duration are statistical estimates, with a confidence interval.
- Ones that are in the future - the planning packages. Planning Packages still have 100% outcomes. The details of how these outcomes don't need to be very fine. But some sense of the work effort to produce the outcomes needs to be in place for the Planning Package to be credible.
With active Work Packages and Planning Packages in place, they can now be put in a sequence. The sequence will produce a Critical Path, the total labor estimate and of course a description of the outcomes from the project.
The result is directly beneficial to the project:
- You have a description of what "done" looks like
- You have some sense of the order that work needs to be performed in to get to "done"
- The path to getting to "done done" is made visible
- And most of all the team members - stakeholder, developers, funders - can all see the logical flow of the project through the Work Packages.
No What To Do With The Work Packages
The content of the Work Package must be developed by the person(s) accountable for delivering the outcome from the work. Notice two things here:
- One single point of accountability for the succcess of the Work Package.
- A single outcome from the Work Package
The Work Package Manager is accountable for the outcome from the Work Package. How the work effort is sequenced, in what order it is performed, who does the work, all the details of the Work Package is managed by the Work Package Manager,
This moves down the accountability and moves up the planning process. Both winner approaches.
