How to Develop a Project Schedule Without Opening the PMBOK
Running a project can feel a lot like herding cats with a laser beam: chaotic and random at best.
Not if you’re using a project schedule though. A proper one clearly outlines the activities that need to be done, their order, the resources involved, and how long it takes to complete them.
Much like a blueprint to benchmark against future progress or risks that might derail the project’s initial scope — which is what usually happens in project management.
So how do you develop a project schedule that is simple enough to be understood by all stakeholders, yet detailed at the same time to be followed by those who execute it?
Project schedule steps
While defining activities, sequences, resources, and activity timelines are viewed by the PMBOK as individual processes with inputs, tools, and output. This only applies to complex and long-term projects where unsupervised changes can turn into hairy problems overnight.
For simpler ones, you’re better off with a single, holistic process like in the infographic below:
Let’s see what each individual step is all about.
1. Define the Work Breakdown Structure (WBS)
The work breakdown structure (WBS) is the foundation of every project schedule. It implies breaking down the work to be done into smaller chunks that are easier to track and manage.
This builds control points throughout the whole project, so project managers know what deliverables to focus on, while clients have a clear picture in terms of what to expect in return for their money.
Defining the WBS is possible through a technique called decomposition, which basically peels off the structure like an onion to reveal the following layers:
Work packages represent the smallest unit of work within a WBS. They are related to each other and contribute together to the actual completion of a deliverable. Like “building the foundation” is for the erection of a house.
Activities, which are further down the road, spell out the effort it takes to complete a work package. By default, each one should come with a description to define the scope of work, as well as additional attributes — like the resources assigned, duration, costs, and dependencies — which will be later specified in the project schedule. So stick with the task description for now.
Milestones, unlike activities, don’t have a duration yet remain on the same level with them. They represent a major event during the project life cycle that can either be mandatory, say the approval of a story board imposed by the client, or optional, like a testing phase before a feature deploy that you’ve figured is a good practice.
2. Sequence activities
Once all activities have been identified, it’s time to sequence them.
Before doing so, remember that each activity needs to have a predecessor (except for the first one, which marks the start of the project) and a successor (except the last one, which marks the end of the project). The same goes for milestones. Also take into account certain logical constraints that prevent some activities to happen before others do. For example, you can’t work on a project before meeting with your client to find out their requirements in the first place.
This being said, there are 4 types of dependencies you can use:
- Finish-to-Start (FS) — By far, this is the most common type of dependency, which states that the predecessor activity must finish before the successor can start. If you don’t want to create a convoluted project schedule, stick with this one to do the heavy lifting for you.
- Finish-to-Finish (FF) — In this case, a successor activity can’t end before the predecessor ends. This usually means that activities will run in parallel, with a portion of the work to be delivered before the other one is completed.
- Start-to-Start (SS) — In this case, a successor activity can’t start until the predecessor starts. Again, this means that activities will run in parallel, with a portion of the work to begin after the other one begins.
- Start-to-Finish (SF) — Rarely used in project management, it implies that the predecessor activity must start before the successor ends. The cases are extreme, hence refrain from using it to avoid any confusion later on.
To learn more about task dependencies with real life examples, read our article.
Luckily, you can overwrite them through lag and lead time. Lag refers to the time added between a predecessor and a successor (a delay), while lead time refers to the amount of time a successor can be advanced with regards to its predecessor (an overlap).
Although handy in critical situations when you’re tight on time, these scheduling methods should be used with caution. Lag time, for instance, should never be used in a Finish-to-Start (FS) dependency, as the delay should be incorporated inside an activity’s duration. Otherwise, you’ll have a hard time monitoring the entire project schedule and account for future changes.
To continue with our house example, “setting tiles for a bathroom” with an FS logic to “painting the walls” has a 3-day lag. This means that waiting until the paint dries is not incorporated in the initial task duration, but hidden in the actual dependency.
Floating activities without any predecessor and successor also exist. Inoffensive at first, they’re actually capable of delaying the entire project if their duration exceeds the project duration. You wouldn’t “coat the roof beams with fireproof paint” when handing over the house keys.
3. Identify resources
The goal here is to identify the type of resource and amount of work required for each activity — be they human, supplies, or materials.
When choosing the right type of resource, don’t be fooled by how good things look on paper. Always probe for your team’s skills, knowledge of industry processes, and proficiency in a certain tool, as this step is closely tied to how you’ll estimate costs later. Hire an inexperienced developer for example, and you run the risk of inflating your costs through training classes, or even worse, hire an external contractor until they ramp up to full-speed.
You also need to take into account their availability during the project life cycle, including leave days, so you know whom to rely upon.
As for the amount of work required, this has to do more with the number of hours or physical units it takes to complete an activity. Whether this needs to be tackled by one or more resources is irrelevant and can be later determined through a resource plan.
4. Estimate activity durations
So far, we’ve only gathered “ingredients” for the project schedule, without actually developing it. The last step before this is to estimate activity durations, that summed up will give you a better picture of how long it takes to deliver the project.
A classic mistake is to assume that every resource works at 100% capacity, a far reachable goal even for the most project-oriented organizations. In fact, working over 40 hours/week has been proved by many scientific journals to increase the risk of cardiovascular diseases, depression, and eating disorders. So use some common sense and account for 70–80% efficiency for realistic, or should I say “human” results.
In terms of the actual estimating process, take advantage of the historical data from your previous projects like the budget, costs, and complexity implied. This works well for projects similar in structure and with an experienced team, yet not advisable due to its low level of accuracy.
For something more precise, use the three-point estimation method that takes into account the activity durations in relation to their outcome of completion:
- Most likely (M) — Based on the current activity attributes and resource constraints
- Optimistic (O) — Minimum time required to complete an activity (best-case scenario)
- Pessimistic (P) — Maximum time required to complete an activity (worst-case scenario)
The final weighted formula — (O + 4M + P)/6 — renders a higher likelihood of the project being delivered on time.
If you piece all things together so far, you should end up with a network diagram similar to the one below:
5. Develop the project schedule
With the WBS, dependencies, resources, and estimates in place, it’s time to develop the actual project schedule. There are a couple of project scheduling techniques to make sure you’re acting within the boundaries of the scope-time-budget triad, while also keeping quality in check.
Critical Path Method
The Critical Path Method (CPM) depicts the minimum amount of time it takes to complete a project. It does so by analyzing the earliest and latest start and end dates of each activity, then goes back-and-forth between them to determine the optimum path to choose — the critical path.
Beware though. Activities that show up on the critical path are not necessarily the most difficult or expensive ones. But rather those which, if take longer to complete, will delay the project duration.
Each activity though can have a float or slack, i.e. the number of days it can be extended without delaying the actual project or violating certain resource constraints. That’s why the CPM is designed to test the project schedule’s flexibility without altering its baseline.
Program Evaluation and Review Technique
Like the CPM, the Program Evaluation and Review Technique (PERT) is built on top of a network diagram. However, this one is a little bit more realistic as it takes into account the weighted average duration of an activity rather than its actual duration.
It does so by also weighing in the best and worst case scenarios in relation to the desired outcome, rendering the estimate formula we’ve discussed in the previous step.
Duration compression
Duration compression is, you guessed it, a way to reduce the project duration by implicitly reducing the duration of each activity on the critical path. So you can still meet your deadlines without compromising on the project scope. There are two common techniques:
- Crashing — Where you bring in new resources or pay overtime to deliver the project on time. Although feasible at first, crashing significantly increases the overall project cost and complexity, due in part to the effort it takes to manage the additional resources.
- Fast tracking — Where you deliberately overlap two consecutive activities so they happen in parallel for a portion of time. Beware though, as this might result in rework and increased risk, forcing you to sacrifice quality for the sake of meeting deadlines.
Resource optimization
Resource optimization techniques take into account the available supply and demand for resources and how they can shorten the project duration. There are two common ones here as well:
- Resource leveling — Refers to adjusting the project schedule in such a way as to balance any over- or under-allocated resources. This is usually done by rearranging activities in a different sequence (in case a resource is overburdened), or changing the activity durations altogether, so only the critical ones get the necessary resources (in case there aren’t enough resources). Unfortunately, this will increase the critical path’s length and overall costs.
- Resource smoothing — Quite the opposite of the previous one, it implies adjusting the resources in such a way as to not exceed an imposed resource limit. This technique is primarily used when you can’t extend the project schedule. Because of this, the critical path will remain the same, meaning that activities can’t be delayed beyond their total float. Yet, not all resources can be “smoothed” in real life, hence resource smoothing is rarely recommended.
6. Review the project schedule
Once the project schedule is complete, it’s time to review it at periodic intervals — a process that will help you correct deviations from the initial baseline and minimize risk in the long run. Here’s a couple of review techniques to choose from:
What-if scenarios — Address different situations and their effects that might delay the project. These can be anything from a major delay or a contractor getting out of business. You can then use the results and prepare contingency plans to protect yourself against these risks.
Trend analysis — As its name suggests, this technique looks at the project performance over a specific period of time to see whether it’s improving or lagging. Some of the parameters analyzed are the actual start and finish dates, the percentage of completed activities, and remaining project duration.
Critical Chain Project Management (CCPM) — Considers the shortage of resources by adding buffer time to each activity, which can then be used to address sudden changes. As a result, the critical chain represents an altered form of the critical path with resource leveling in place. That’s why this time you’re not looking to manage the remaining float, but the difference between the remaining buffer and activity durations (those on the critical chain).
How to develop a project schedule in Paymo
Phew, that’s a lot of files to keep in order and techniques to remember. Luckily, there’s a better way to develop a project schedule without losing your sanity: via a project management software.
The clear advantage of a tool like this is that you’re able to draw more complex diagrams than you could with just a pen and paper. The reviewing process also becomes much more efficient, as data keeps feeding the system so you’re better equipped to make the right decisions.
If you need to create a project schedule in just a few steps, then Paymo is the right tool for you.
Let’s see how.
1. Define the Work Breakdown Structure (WBS)
The first thing to do is map out the WBS of a project. Here’s how each element of the structure translates…
🔷 Read the full story on Paymo’s blog 🔷
