There has been some discussion on the New Grange forum about recognizing a "good" schedule. PMBOK provides some general purpose wording, but no real guidelines for building a "credible" schedule.
The assessment of a "good" schedule has several dimension, independent of the details of the project network:
- Is the Statement of Work (SOW) traceable to the activities in the network? If so, is each activity connected to one and only one SOW element?
- Is progress measured as the passage of time or with some maturity assessment process
- Are the resource requirement visible?
- Is the performance of the resources measurable?
- Is a funding and resource forecast assessable?
- Are risks identified and mitigated with risk buy down plans traceable to the technical and programmatic risks?
- Is the confidence in the activity durations known?
- Are cost and schedule connected at the deliverables level?
- Are the deliverables assigned to a single identifiable individual?
These are architectural attributes of the schedule. This is an activity network in our domain, which brings up another important point. Many project managers consider the "plan" to be a list of activities arranged in some sequence. Here are some additional attributes of a "credible" schedule:
- An assessment of the relationship types
- Number of Finish to Starts - this should 100% of the relationships
- Number of Start to Starts - has not real relationship, since the successor can start simultaneously with the predecessor. If there is a negative value on SS, something other than a predecessor/successor relationship is in place and a better model is needed for these activities
- Number of Finish to Finish - this says there is no effective relationship between the activities, since the successor can complete simultaneously with the predecessor
- Number of Start to Finish - don't do this!
- Any relationship involving a summary task should be avoided
- Lead and Lags
- In a well formed schedule there should be very few lead or lag relationships. This is not the common approach, but if schedule slack is made explicit, then leads and lags are not needed
- Explicit schedule slack means adding activities "in line" that represent slack. This slack can then be explicitly managed by the planner.
- Activities without predecessors or successors
- There is only one activity without a predecessor - the start of the project
- There is only one activity without a successor - the end of the project
- Float
- If slack is not explicit, look for activities with long float
- This usually means there is poor logic
This list is just a sample of what to look for in a "credible" schedule. The risk tolerance of the schedule, is ability to be decoupled from dependencies - "streamlined" is a term we use - is critical to responding to disruptions in the execution plan.
Planning is an Activity Not a Product
A credible schedule has integrity - the check list on relationships. It is also tolerant of disruptive events. But most important is has attributes that assure that the work can be completed in the presence of uncertainty.
One of the main targets of the traditional approach to planning by the agile community is the construction of a "plan" that represents a fixed execution order. Such a plan is not robust, risk tolerant or even credible. So of course it is an easy target. But it is an easy target in the traditional sense as well.
Learning to plan means learned how to think in the presence of uncertainty
