Project Schedule Management: From Task List to Baseline

Ask a contractor when the kitchen will be finished and watch time lose its meaning. "Three weeks, give or take." Eight weeks later you are cooking pasta on a hot plate in the living room and the contractor is, as always, optimistic.

Contractors are not liars. They are victims of a very human habit that researchers call the planning fallacy: we underestimate how long things will take, even when we have done similar things before and know the history. The fix is not better character. It is a method. This guide shows the method for managing a project schedule from a task list to a baseline, and then, the part people skip, keeping it true while the project runs.

I write as a project and operations manager, and the examples are made up to illustrate the ideas, unless I say otherwise. If you have read the PMBOK Step 4 article on baselines, this is the wider view: how the schedule works as a system, with a worked example you can calculate by hand.

What schedule management really is

A schedule is not a Gantt chart. A Gantt chart is a picture of a schedule, and a pretty one. The schedule is the set of decisions behind the picture: what the work is, what depends on what, how long each piece takes, who does it and when you will look at it again. The five habits are:

1. Define the activities. What are the pieces of work?
2. Sequence them. What must happen before what?
3. Estimate the durations. How long does each take, and how sure are we?
4. Develop the schedule. Put it on a calendar, find the critical path and check the resources.
5. Control the schedule. Compare, forecast, decide and update, every week.

Swipe sideways to see the whole figure

Let us walk through them with one example that we will calculate together.

Step 1: Define the activities

Start from the work breakdown structure, the tree of deliverables that shows what has to exist at the end. If you need a refresher, see scope and the WBS. Activities are the verbs that produce the nouns: "install cabinets" produces "cabinets installed."

Good activities are:

• Small enough to estimate: one to ten working days is a good size. If it is a month, break it up.
• Owned by one person or crew.
• Finished in a way anyone can check: "drywall done and inspected" is checkable; "drywall mostly done" is not.

Do not forget the waiting: lead times for ordering materials, inspections, approvals and client decisions are activities too. They use time but not labor, and they are the favorite hiding place of delays.

Step 2: Sequence the activities

For each activity, ask: what has to be finished before this can start? Most dependencies are finish-to-start: the cabinets cannot be installed until the drywall is finished. Others are less common but real:

• Start-to-start: one task can start once another has started (painting can begin once drywall has started in the first room).
• Finish-to-finish: one task cannot finish until another finishes (testing cannot finish until the last component is installed).
• Start-to-finish: rare; mostly used in handovers between shifts.

Also watch for dependencies that are not about tasks: resource dependencies (the same crew is needed on two tasks), external ones (a permit office) and preferred ones (we would like to do A before B but could swap). Write them as honest labels, because the hard ones are the ones to manage.

Step 3: Estimate the durations

Single-number estimates hide uncertainty. A three-point estimate asks for three numbers for each uncertain activity: optimistic (O, if all goes well), most likely (M) and pessimistic (P, if the usual troubles appear). A common way to combine them, from a technique called PERT, is:

Expected duration = (O + 4 × M + P) ÷ 6

For example, tiling a backsplash: O = 1 day, M = 2 days, P = 5 days. Expected = (1 + 8 + 5) ÷ 6 = 14 ÷ 6, about 2.3 days. The number is useful, but what matters is that someone asked "what would make it 5 days?" and wrote the answer down: the tile arrives chipped, the wall is not flat, the tile setter is out sick.

Some rules of thumb:

• Ask the person who will do the work, not the person who wants the date.
• Use history. Last time we did this, how long did it really take?
• Estimate in working days, and put holidays and weekends in the calendar.
• Never estimate in front of a client or a boss who is frowning. The number will shrink.

Step 4: Develop the schedule, a worked example

Now we put it together. Here is a small kitchen remodel (illustrative), with durations in working days:

• A. Demolition: 3 days, starts day 0.
• B. Rough plumbing and electrical: 4 days, after A.
• C. Inspection: 1 day, after B.
• D. Drywall: 3 days, after C.
• E. Cabinet order and delivery: 15 days, can start on day 0 (the design is approved).
• F. Install cabinets: 3 days, after D and E.
• G. Countertops (template, fabricate and install): 7 days, after F.
• H. Paint: 2 days, after D.
• I. Appliances and punch list: 2 days, after G and H.

Let us calculate the earliest dates. A runs from day 0 to 3. B from 3 to 7. C from 7 to 8. D from 8 to 11. E runs in parallel, from 0 to 15. Now F needs both D (day 11) and E (day 15), so it cannot start before day 15, and runs 15 to 18. G runs 18 to 25. H runs 11 to 13. I needs G (day 25) and H (day 13), so it runs 25 to 27.

The project takes 27 working days.

Swipe sideways to see the whole figure

The critical path

The chain that sets the end date is the longest one: E → F → G → I = 15 + 3 + 7 + 2 = 27 days. That is the critical path. Compare it with the chain through the construction work: A → B → C → D → F → G → I = 3 + 4 + 1 + 3 + 3 + 7 + 2 = 23 days. That chain has 4 days of float, meaning it can slip four days without moving the end date. Paint (H) has even more: it finishes on day 13 but is not needed until day 25, so it has 12 days of float.

Read that again, because it changes how you manage. The remodel's biggest risk is not the demolition crew or the drywall. It is the cabinet lead time. If the cabinets are ordered a week late, the whole project is a week late, even if the crews are perfect. If drywall slips by three days, nothing happens. A good project manager spends attention where it moves the date. That is the idea behind the critical path method, which the linked guide explains with a calculator.

Swipe sideways to see the whole figure

Put it on a calendar, and check the people

Once you have the logic, put it on a real calendar and check resources. Two tasks that "can" run in parallel will not if the same crew is needed for both; this is resource leveling, and it often stretches the schedule. The article on capacity planning and bottlenecks shows how to find the people who are the real constraint. A Gantt chart is then a good way to show the result, as long as you remember it shows the plan, and the plan is not reality.

Where to put the buffer

Here is a trick that saves projects. When asked, most people add a little padding to every task. But padding hidden inside tasks tends to disappear: work expands to fill the time available (this is called Parkinson's law), and people start late because "there is time". A better approach is to estimate each task honestly, close to the middle, and add one visible project buffer at the end of the critical path, owned by the project manager. In our example, if the team thinks the unknowns justify a week, the plan says 27 days plus a 5-day buffer, and everyone can see how much of the buffer has been used at any time. This is the practical core of the "critical chain" idea from the theory of constraints.

Step 5: Control the schedule

The plan is the easy part. Projects are delayed one day at a time, by small things nobody reported. Control is the weekly habit that catches them. Here is a routine that works for a small project.

The weekly schedule check (15 minutes)

1. Update the facts. For each activity that started or finished, record actual dates.
2. Update the remaining time. For each activity in progress, ask the owner: "How many days do you need to finish?" Not "what percent is done?" Percent complete is a guess about the past; remaining time is a forecast about the future.
3. Re-run the critical path. Did the chain change? Did a path that had float lose it?
4. Forecast the end date. If the forecast moved, write why, in one line.
5. Decide. Can we recover by changing the sequence, adding people or removing scope? Or do we tell the sponsor the date will move?
6. Report in one page. The status report guide shows a one-page format with the three things a sponsor needs.

Milestones beat percentages

"The cabinets are 90 percent installed" is not information. "Cabinets installed and leveled: yes or no" is. Define milestones that are binary: done or not done. Put three to eight of them on the first page of the schedule. A milestone that is not done on its date is a signal; a task that is "almost done" is a rumor.

Measure with numbers that mean something

If you want an objective check, earned value in plain English turns progress into two simple indexes. For a small project, even a count works: how many milestones were planned by now, and how many are done? Look at the trend. A slip of one day in week two that becomes three days in week four tells you something is wrong.

Changes go through a door

Scope changes move the schedule. Every request that adds work should arrive with an estimate of its effect on days and dollars, and an approval before the work starts. Otherwise you are doing scope creep under a friendlier name. In construction, the same discipline applies to change orders and delay claims, and the guide on construction schedule delays covers the common causes.

Choosing the right style for your project

Not every project deserves a network diagram. Match the method to the work:

• Fixed date, expensive changes, many dependencies (a building, an event, a product launch): use the full approach above.
• A stream of requests with no end date (a service desk, a small team's weekly work): use a board with limits on work in progress. See Kanban for small teams.
• Uncertain scope and a fixed budget (many software and creative projects): plan the frame and run short cycles. The guide to agile, waterfall or hybrid helps you choose.
• Small business improvements: a one-page schedule with five or six milestones and a weekly review is plenty. Put it inside a 90-day sprint.

Common mistakes: the hall of fame

• Starting the chart before the logic. Dates without dependencies are decoration.
• One-number estimates with no assumptions behind them.
• Padding every task and still finishing late, because everyone started on the last day.
• Ignoring the lead times of orders, permits and approvals.
• Treating the baseline as sacred and never updating, or treating it as disposable and never comparing. Keep the baseline and the current forecast side by side.
• Percent complete. Use remaining time and milestones.
• No one owns the date. The project manager owns the schedule, the sponsor owns the decisions to protect it.
• Hiding bad news until it is large. A one-day slip reported on Friday is a conversation. A two-week slip reported on the last day is a crisis.

The schedule on one page

If you remember one format, remember this one. It fits on a single sheet and holds up in a weekly meeting:

1. The goal and the date, with the confidence level: "27 days, 80 percent confident, with a 5-day buffer."
2. The critical path in one line: "Cabinets → install → countertops → handover."
3. Six milestones, each with a planned date, a forecast date and a status.
4. The top three schedule risks, each with an owner and a next action. The risk register guide shows a simple way to keep them.
5. Decisions needed from the sponsor, with a date by which each is needed.

The format belongs in the weekly meeting described in Project Focus Part 4: the scoreboard, last week's commitments, the projects, decisions and new commitments. And it pairs with the cost side of the baseline in the cost management guide, since time and money move together.

Try it: is your schedule a plan or a wish?

Tick the statements that are true for one of your projects today.

Interactive tool

Is your schedule a plan or a wish?

Loading the tool…

What to do this week

1. Pick one project and list the activities that will produce its main deliverables. Aim for 15 to 30 activities, each of one to ten days.
2. Draw the dependencies on a whiteboard or paper, including waits and lead times.
3. Ask each owner for three numbers for the two most uncertain activities: best, most likely and worst.
4. Find the longest chain and mark it. Ask: what is the one thing on it that, if it slipped a week, would move the end date?
5. Decide where the project buffer sits and who watches it.
6. Next Friday, run the 15-minute check and replace "percent complete" with "days remaining".

If you want a second pair of eyes on a schedule, see my services or take the diagnostic. And for the full step-by-step path from business case to closeout, follow the PMBOK step-by-step series.

Frequently asked questions

What is project schedule management?

It is the set of habits that produces and maintains a project's schedule: defining the activities, sequencing them by dependencies, estimating durations, building the schedule and finding the critical path, and controlling it every week with updated actuals and forecasts. The picture, such as a Gantt chart, is only the output.

What is the critical path and why does it matter?

The critical path is the longest chain of dependent activities, and it sets the earliest possible end date of the project. Any delay on it delays the project, while activities with float can slip a little without any effect. Knowing it tells you where to focus your attention and your resources.

How do I estimate task durations accurately?

Ask the people who will do the work, use history from similar tasks and estimate with a range: best case, most likely and worst case. A common way to combine them is (best + 4 × most likely + worst) divided by 6. Write down the assumptions behind the worst case, since that is where the surprises come from.

How often should I update a project schedule?

At least weekly for most projects, and daily for short, intense ones. Record actual dates, ask owners for the remaining time on work in progress, re-check the critical path and forecast the end date. Keep the original baseline so that you can see how the forecast compares with the plan.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

Name (optional) What is the worst "almost done" you have ever heard on a project? Post comment

No email and no sign-up. Every comment is reviewed before it appears. Please keep it respectful and leave links out.