The Gantt Chart is the most widely used [1] project scheduling tool. It visually depicts the project’s activities, when they will occur, and their interdependencies. When used correctly, it is powerful. Unfortunately, most Gantts are poorly constructed, stripping them of their value.
Henry Gantt developed the tool a century ago. The original Chart was simply a horizontal bar chart showing the timing of events. It was used in World War I and the construction of the Empire State Building.
The Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT) were developed in the 1950s to model the complex project dependencies of the Navy’s Poseidon program. Today, nearly all scheduling tools fold PERT and CPM capabilities into the visually appealing Gantt.
The project schedule is a model for forecasting future events. If correctly constructed, it will calculate when activities should be executed. I have examined hundreds of plans, and unfortunately, most violate the required practices, which renders them no more effective than a hand-drawn picture. This article describes the best practices for creating an effective Gantt schedule.
Is this the right project?
Using a Gantt to create a schedule e requires meeting requirements that do not apply to many projects. The tool works well when:
- Deliverables are well-defined; and
- Activities required to create the deliverables can be identified, sequenced in a logical order, and the effort (time and resources) can be estimated.
Construction projects generally meet these conditions. Architects create detailed blueprints and specifications describing the deliverables. The activity sequencing is clear. And reasonable time and effort estimates can be provided. Knowledge work projects such as software development struggle with these pre-conditions.
Start with the Deliverables
The first step to creating a good schedule is defining the deliverables, which describe the project’s scope and the expected outcomes. It is helpful to think of deliverables as nouns.
Deliverables are both external (customer-facing) and internal (used by the project team). External deliverables are kitchen cabinets or user reports. Internal deliverables can include the plans, specifications, and other project documents.
The work breakdown structure (WBS) is commonly used to decompose the scope into well-defined components. Traditionally, the WBS is a hierarchy chart. Most tools have replaced this with an outline view that is easier to navigate and display. Lines are indented and numbered to depict the level in the hierarchy. The WBS can be organized functionally, by phase, or in a hybrid view.
The work package is the lowest level of detail in the hierarchy. Work packages are small enough to estimate the time and cost, and can be assigned. The WBS anchors the project by identifying the required outputs. A common mistake is bypassing this step and jumping to planning the activities.
Labeling or color-coding WBS elements and activities will make it easier to navigate the Gantt.
Identify and Sequence Activities
After cataloging the work packages, the next step is identifying the activities required to create them. Think of activities as verb-noun phrases with many activities needed for each deliverable.
List all the activities, then sequence their order of execution. Every activity must have at least one predecessor and successor activity. Failing to map dependencies or force-fitting dates strips the Gantt of its power.
Dependency Types
Activities can have mandatory or discretionary dependencies. Mandatory dependencies are standards, regulations, or laws of nature; and must be followed. Discretionary dependencies are preferences or best practices.
Relationship types describe the order of execution:
- Finish-to-Start (FS): The second activity starts after the first finishes. This is the most common relationship.
- Start-to-Start (SS): One activity must start before the other.
- Finish-to-Finish (FF): One activity must finish for the other to complete.
Baking cookies illustrates these relationships:
- Discretionary: I start preheating the oven before mixing the batter (SS).
- Mandatory: I must finish mixing the batter before baking the cookies (FS).
- Discretionary: I must finish taking the cookies off the sheet before cleaning up (FF).
Leads & Lags
Leads and lags describe the trigger to start an activity:
- No Lead-No Lag: The beginning of the second activity begins immediately following the completion of the first. This is very common. Example: Testing starts when development is complete.
- Lead: The second activity starts before the first is complete, or the second activity leads the first through completion. Example: Testing begins before development is complete.
- Lag: After completing the first activity, there is a pause before the second begins. Example: Waiting for the paint to dry before applying the next coat.
Estimating Activity Durations
The next step is estimating the time and effort required to execute each activity. There are several estimating techniques ranging from high-level to detailed. These estimates drive the schedule calculations.
Duration estimates should consider the number of resources and the time required. For some activities, adding resources can reduce the duration. If we are digging a ditch, adding workers will reduce the time. However, for knowledge work adding resources often leads to delays (Brook’s Law [2]).
Critical Path
The critical path is the sequence of activities with the longest duration and defines the project length. If any of these activities take longer than expected or are delayed, it will impact the project's completion.
Float (or slack) is when an activity not on the critical path can be delayed without impacting the schedule. The start of these activities can be postponed, or their duration can be extended, which creates flexibility.
Activity sequencing drives the critical path and project duration. Interrogating these relationships [3] can have a significant impact on the schedule.
Milestones
A project schedule can be hundreds or thousands of lines long. Milestones are added to summarize the project and mark the completion of significant events. Large organizations may require specific milestones to standardize reporting.
Finalize the Plan
The project plan should be reviewed and approved by the sponsor, key stakeholders, and the project team before being finalized. The approved schedule should be baselined in the scheduling tool to track performance. Changes to the baseline must go through the project’s change management process.
Monitor Performance
The baselined schedule is used to monitor actual performance against the plan. The project manager should regularly meet with the team to update the deliverable status. The updates will identify deviations from the baseline plan.
Nothing ever goes according to plan. Some activities take longer than expected, and others are completed more quickly. The critical path will likely change. Consequently, operational plans should adjust as facts on the ground dictate. The project team may need to reprioritize or resequence work.
Performance should be measured by completed deliverables (work packages). Completion is binary (done or not done), avoiding confusing effort with accomplishment. Be aware of the 90% Rule [4] (the last 10% of the work takes 90% of the time).
© 2022, Alan Zucker; Project Management Essentials, LLC
See related articles:
- 4 Ways to Shorten a Project Schedule [3]
- Improve Your Project Schedule [5]
- Planning is a Process, Not an Outcome [6]
- Project Gone Bad—What to Do [7]
To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/ [8].
Image courtesy of: wallpaperaccess.com