Best Practice 2: Sequencing All Activities
Key Questions
Have the activities and logical relationships been determined by those executing the program?
Are the majority of the relationships within the detailed schedules finish-to-start?
Are predecessor links (with the exception of the start milestone) or successor links (with the exception of the finish milestone) missing?
Are any predecessors or successors dangling?
- Does each activity (except the start milestone) have an F-S or S-S predecessor that drives its start date?
- Does each activity (except the finish milestone and deliverables that leave the project without subsequent effect on the project) have an F-S or F-F successor that it drives?
Do summary activities have predecessor or successor links?
Do activities have start-to-finish links?
How much convergence (that is, several parallel activities converging at one major event) is there in the schedule? For activities that have many converging predecessors, do those predecessors have adequate float?
Does the schedule contain date constraints other than “as soon as possible”? Is each one justified in the schedule documentation?
Are lags or leads specified between the activities? Can these be more accurately characterized by improving logic or adding activity detail?
Key Documentation
Documentation justifies using hard and soft date constraints instead of activities’ duration and logic.
Documentation justifies using lags and leads instead of activities’ duration and logic.
Documentation justifies any activity that has no F-S or S-S predecessor or no F-S or F-F successor.
Likely Effects If Criteria Are Not Fully Met
The logical sequencing of events is directly related to float calculations and the critical path. If the schedule is missing dependencies or if activities are linked incorrectly, float estimates will be miscalculated. Incorrect float estimates may result in an invalid critical path and, thus, will not be reliable indicators of where resources can be shifted to support delayed critical activities.
That all interdependencies between activities are identified is necessary for the schedule to properly calculate dates and predict changes in the future. Without the right links, activities that slip early in the schedule do not transmit delays to activities that should depend on them. When this happens, the schedule will not allow a sufficient understanding of the program as a whole, and users of the schedule will lack confidence in the dates and the critical path. Finally, when activities are not correctly linked, the program cannot use the IMS to identify disconnects or hidden opportunities and cannot otherwise promote efficiency and accuracy or control the program by comparing actual to planned progress.
Logical sequencing promotes a realistic workflow. If logic between activities is missing, program team members can misunderstand one another, especially regarding receivables and deliverables.
For scheduling software packages that include the option, summary activities should not have logic relationships because their start and finish dates are derived from lower-level activities. Summary logic hinders vertical traceability by obstructing the logic of lower-level activities.
A start-to-finish (S-F) link has the bizarre effect of directing a successor activity not to finish until its predecessor activity starts, in effect reversing the expected flow of sequence logic. The use of S-F logic is counterintuitive and overcomplicates schedule network logic.
The presence of “dangling activities” reduces the credibility of the calculated activity start and finish dates and the identity of the critical paths. The slip or elongation of an activity that has no logical successor will not reflect its effect on the scheduled start dates of successor activities.
- If an activity—other than the start milestone—does not have an F-S or S-S predecessor that drives its start date, the activity will start earlier if its duration is projected to be longer than originally believed. An earlier start may be illogical.
- If an activity—other than the finish milestone or deliverable that leaves the project—does not drive a successor by an F-S or F-F link, the implications of its running late or long are not passed on to any successor activity.
The ability of a schedule to forecast start and finish dates of activities and key events is directly related to the complexity and completeness of the schedule network. Unless complete network logic is established, the schedule cannot predict the effects on the program’s planned finish date from, among other things, misallocated resources, delayed activities, external events, and unrealistic deadlines.
Because a logic relationship dictates the effect of an on-time, delayed, or accelerated activity on following activities, any missing logic relationship is potentially damaging to the entire network.
Path convergence issues can represent an unrealistic plan by implying that a large number of activities must be finished at the same time before a major event can occur as planned. An excess number of parallel relationships can indicate an overly aggressive or unrealistic schedule.
Hard date constraints that restrict activities to starting or finishing on a specific date must be justified by referring to some controlling event outside the schedule. Date constraints prevent activities from responding dynamically to network logic, including actual progress and availability of resources. They can seriously affect float calculations and the identification or continuity of the critical path and can mask both progress and delays in the schedule.
Hard and soft constraints interfere with the results of a schedule risk analysis because they prevent activity dates within the schedule from dynamically responding to changes in predecessor dates.
A customer-mandated date is not a legitimate reason to constrain an activity. A schedule is intended to be a dynamic, pro-active planning and risk mitigation tool that models the program and can be used to track progress toward important program milestones. Schedules with constrained dates can portray an artificial or unrealistic view of the program plan.
Constraints should be used only when necessary and only if their justification is documented because they override network logic and restrict how planned dates respond to accomplished effort or resource availability. The presence of a large number of activities with constraints is typically a substitute for logic and can mean that the schedule is not well planned and may not be feasible.
SNLT and FNLT constraints prevent activities from starting or finishing later than planned, essentially restricting the ability of any predecessor delays to affect their start and finish dates.
Applying constraints to represent the availability of resources requires constant manual upkeep of the schedule.
Mandatory start and finish constraints are the most rigid of all constraints because they do not allow the activity either to take advantage of time savings by predecessor activities or to slip in response to delayed predecessors or longer-than-scheduled durations.
The time to produce an external product should be represented by a reference or schedule visibility activity rather than a constrained milestone representing receipt of the product. By modeling vendor or contractor production as an activity, the program office can track the contractor’s high-level progress and apply risk to the external production activity.
Lags must be justified because they may represent work or delay that may be variable while the lag is static. Lags should not be used to represent activities because they cannot be easily monitored or included in the risk assessment and do not take resources. Activities represented by lags are not, in fact, risk free.
Constantly updating lags manually defeats the purpose of a dynamic schedule and makes it particularly prone to error.
Using a lag with F-S logic is generally not good practice because it is generally not necessary. When it is, every effort should be made to break activities into smaller tasks and to identify realistic predecessors and successors so that logic interface points are clearly available for needed dependency assignments.
Leads are generally not valid. As negative lags, leads imply the unusual measurement of negative time and exact foresight about future events.
Using lags as buffers or margin for risk between two activities should be discouraged because the lags persist even as the actual intended margin is used up.