PMBOK Step by Step, Part 4: How Long and How Much? The Schedule and Cost Baselines

Every sponsor asks two questions in the first five minutes of any project: "How long will it take?" and "How much will it cost?" The wrong answer is a number pulled out of the air. The second wrong answer is "it depends". The right answer is a number with a story behind it: a list of the work, a chain of dependencies, a range for each estimate and a record of what was assumed.

This is Part 4 of PMBOK step by step, which follows one invented clinic project from idea to closeout. In Part 1 the owners of the Riverside Family Clinic signed a charter with a budget of $280,000 and an opening nine months after approval. In Part 2 they listed who is involved, and in Part 3 they broke the scope into a work breakdown structure. Now they turn that structure into two baselines: one for time and one for money.

A reminder: the clinic is invented. Riverside is a composite, not a real client, and every name and number here is illustrative. Nothing in this post is legal, financial or medical advice.

What a baseline is, and what it is not

A baseline is a snapshot. It is the schedule and the cost plan as the sponsor and the team agreed them at a point in time. It exists for one reason: so that later you can compare what is happening with what was planned, and you can see the gap clearly.

Three things it is not:

• It is not a forecast. A forecast says where the project will end up given what we know today. A baseline says where we said we would be. You need both, and they will disagree, which is the whole point.
• It is not sacred. When the scope changes, the baseline changes, through a decision. What you must not do is rewrite it quietly so that the project always looks on track. The guide on change orders shows how a change request keeps that honest, and stop scope creep shows what happens when it is skipped.
• It is not one number. The schedule baseline includes the dates, the dependencies and the assumptions. The cost baseline includes the estimates, the contingency and the timing of the spend.

The schedule, step by step

The PMBOK approach to time has six small steps. The names matter less than the order.

1. Define the activities

Take each work package from the WBS and ask: what do we have to do to finish this? "Procedure room plumbing rough-in" becomes a few activities: order materials, schedule the plumber, rough-in, inspect. Keep it at a level that someone can own. If you have followed Part 3, this is the point where the nouns of the WBS become the verbs of the schedule.

2. Sequence them

Now decide what must happen before what. Most links are finish to start: the plumber cannot start until the walls are framed. Some are start to start, such as ordering equipment as soon as the design is approved, even though the equipment will not be installed for months. Lead and lag add a gap or an overlap, for example a one-week wait for concrete to cure. Draw the links on a whiteboard before you open any software. If you cannot explain a link in one sentence, you do not understand it yet.

3. Estimate durations

How long will each activity take? You have three practical methods.

• Analogous. "The last room like this took us three weeks." Fast, and only as good as the comparison.
• Parametric. "Our crew installs about X per day." Good when you have a rate from past work.
• Three-point. Ask for three numbers: an optimistic case (O), a most likely case (M) and a pessimistic case (P). A common average is (O + 4 × M + P) divided by 6, and a rough measure of uncertainty is (P − O) divided by 6.

Here is an illustrative example for Riverside's build-out. The contractor says it is most likely 14 weeks, could be 12 if everything goes well and could be 20 if inspections or deliveries slip. The three-point average is (12 + 56 + 20) divided by 6, which is 14.7 weeks, and the spread is (20 − 12) divided by 6, which is 1.3 weeks. The difference between 14 and 14.7 is small. The story in the pessimistic number is not: what would make it 20? Write the answer down. That is a risk, and Part 5 will give it a home in the risk register.

4. Find the critical path

Once you have activities, links and durations, the critical path is the longest chain of dependent activities from start to finish. It sets the earliest finish date of the project. Any delay on it moves the finish date. If the idea is new to you, the critical path guide walks through a worked example.

For the Riverside project, in illustrative weeks, the critical path looks like this:

1. Lease negotiation and signing: 4 weeks
2. Design and construction drawings: 6 weeks
3. Permits and approvals: 5 weeks
4. Build-out: 14 weeks (the three-point estimate rounds to 15 if you want to be careful)
5. Equipment installation: 2 weeks
6. Staff training: 2 weeks
7. Final inspection: 1 week
8. Opening readiness check: 1 week

That adds up to 35 weeks, against a charter target of nine months, about 39 weeks. The four weeks of difference is the schedule's project buffer, and the team keeps it on purpose.

5. Understand float

Activities that are not on the critical path have float: the time they can slip without moving the finish date. Equipment is a good example. It needs a 10-week lead time and is ordered once the design is approved, at around week 10. It must arrive by the start of installation, around week 29. So ordering can slip by about nine weeks before it hurts. That is useful to know, and it is dangerous to forget: float is shared with the activities that follow, and once it is used up the activity becomes critical.

6. Set the schedule baseline

When the sponsor and the team agree on the schedule, you save it: the activities, the dates, the dependencies and the assumptions. That is the schedule baseline. From now on, each week you compare the actual dates with the baseline and report the difference. A Gantt chart is a good way to show it, as long as you remember that the chart is a picture of the logic and not the logic itself.

The cost, step by step

Cost planning follows the same shape: list, estimate, add the cushion, spread over time, freeze.

1. Estimate each work package

Use the WBS again. A bottom-up estimate adds the cost of every work package: labor, materials, fees and equipment. It is slower than a rough guess and far more accurate. Here are the illustrative Riverside numbers:

• 1.1 Project management: $12,000
• 1.2 Lease and design (fees, drawings; rent is operating cost): $24,000
• 1.3 Permits and approvals: $9,000
• 1.4 Build-out: $142,000
• 1.5 Equipment and technology: $38,000
• 1.6 People and operations (training, supplies, enrollment fees): $15,000
• 1.7 Launch: $10,000

That is $250,000 in total. If you want a refresher on thinking about costs before the project starts, the project cost management guide covers budgets, baselines and contingency in more depth.

2. Add contingency and reserve

No estimate is perfect. The team adds contingency, an amount tied to named risks, such as the build-out coming in at the pessimistic 20 weeks. It is part of the cost baseline, and the project manager controls it. In the example it is 10 percent, or $25,000, so the cost baseline is $275,000. Above it sits the management reserve, held by the sponsor for unknown unknowns. Here it is the remaining $5,000 of the charter's $280,000 budget. Spending management reserve needs the sponsor's decision, and when it is used the baseline is updated.

3. Spread it over time

A budget is not a single number. It is a curve. The team spreads each work package over the months in which the work happens, and adds the months together to get a cumulative line. In the example, the planned cumulative spend of the base $250,000 is about $45,000 by the end of month 3 (design, permits and the lease), about $140,000 by the end of month 6 (the build-out is under way) and the full amount by month 9. Drawn on a chart, it looks like a gentle S. This is the same curve you will use for earned value: the planned value at any date, against which you compare the work done and the money spent.

4. Freeze the cost baseline

Once the sponsor approves, you freeze it. When someone asks, in month five, "are we over budget?", the answer is a comparison with the baseline, not a feeling. A weekly one-page status report makes that comparison routine.

Linking the two

The schedule and the cost depend on each other. A longer schedule costs more in management time and overhead. A cost-cutting decision may lengthen the schedule. A useful habit is to review them together: every time someone proposes a change, ask the two questions out loud, "what does this do to the date?" and "what does this do to the cost?" If the change is large, it goes through change control. That is how the lightweight governance from earlier posts keeps decisions honest without becoming paperwork.

Common mistakes

• Estimating in your head, alone. The person who does the work should estimate it, or at least review the number.
• One-number estimates. "Two weeks" without a range hides the risk. Ask for O, M and P.
• A schedule with no dependencies. A list of dates is not a schedule. If you cannot see what blocks what, you cannot find the critical path.
• Padding every task. If each person adds a cushion, the cushions are wasted by Parkinson's law and the project is still late. Keep the buffer at project level, in the open.
• Confusing contingency with slack. Contingency is tied to risks. If nobody can say which risk it covers, it will be spent on whatever comes along.
• Treating the baseline as a rule. It is a reference. Change it through a decision, not through silence.
• Not recording assumptions. "Permits take five weeks" is an assumption. Write it down, so that when the city takes eight, you know why the plan moved.

How this fits the PMBOK map

In the language of the PMBOK Guide, this post covers the planning work in the schedule and cost knowledge areas: defining and sequencing activities, estimating durations, developing the schedule, estimating costs and determining the budget. The result is the performance measurement baseline, which combines scope, schedule and cost and is the reference for monitoring and controlling. Part 3 gave you the scope baseline, and this post gives you the other two.

PMBOK and PMP are registered marks of the Project Management Institute, Inc. This series is independent and is not affiliated with, or endorsed by, PMI. The Riverside Family Clinic is an invented example, and all figures and names are illustrative.

Try it: your 12-day baseline

The tool below turns the steps in this post into a calendar. Pick the day you start, and you get a sequence of small milestones for building the schedule baseline and the cost baseline for a project of your own. Move any date to fit your week.

Interactive tool

Your 12-day baseline

Loading the tool…

What to do this week

1. Take the work packages of your own WBS and write the activities for the three largest ones.
2. For each, draw the dependencies on a whiteboard and mark the chain you believe is critical.
3. Ask the person who will do the work for three numbers: best case, most likely and worst case. Write down what would cause the worst case.
4. Estimate the cost of each work package from the bottom up, and add contingency only for risks you can name.
5. Put the cumulative spend in months and look at the curve. Does it match how the work will actually happen?
6. Agree on the baselines with your sponsor and save them. Then agree on how a change will be approved.

Next Wednesday, in Part 5, the team asks what could go wrong. We will build a risk register, score the risks and decide which ones deserve a response, a contingency or just a watchful eye. The stakeholder map from Part 2 will come in handy again. If you want help applying these ideas to a project of your own, see my services or take the diagnostic.

Frequently asked questions

What is the difference between a schedule and a schedule baseline?

The schedule is the living plan, which you update as work progresses. The schedule baseline is the approved version at a point in time, kept unchanged as a reference. You compare the actual progress with the baseline to see how far you are from the plan, and you change the baseline only through an approved change.

What is the difference between contingency and management reserve?

Contingency is money (or time) set aside for identified risks, and it is part of the cost baseline, usually controlled by the project manager. Management reserve covers unknown unknowns, is held outside the baseline and needs a decision by the sponsor or management to use it. When it is used, the baseline is updated.

How do I estimate a task I have never done before?

Use three points instead of one: a best case, a most likely case and a worst case, ideally from the people who will do the work or from someone who has done something similar. A common average is (best + 4 × most likely + worst) divided by 6. Write down what would cause the worst case, because that becomes a risk to manage.

Do small projects need a baseline?

Yes, a simple one. Even a five-person project benefits from a list of work, the order it will happen in, a date and a budget that everyone agrees on and writes down. Without it, nobody can say whether the project is late or over budget, only that it feels that way.

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) Which estimate did you give once that you wish had been a range? Post comment

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