Schedule to the Client's Deliverables, Not Your Finish Date

To build a project schedule around client deliverables, find out what the client wants back first, and in what order, before anyone prices the work. A deliverable is a piece of the client's operation returned to service, not a milestone inside your plan. Sequence to those pieces and you can answer the question a client asks all job long: when does my system come back. Sequence to your completion date and you have one answer available, and it is almost never the one they wanted.

The kitchen or the living room?

Ask a project controls lead to explain project controls and you expect a textbook answer. In one interview we got a home remodel instead. You hire someone to redo the kitchen and the living room, and before anybody swings a hammer you agree four things: the scope, the sequence, the timing and the payment terms. If you are professional about it, you get all four in writing.

Then the wife says she wants the kitchen back first.

That one sentence is the entire discipline. An estimator building the most efficient plan might sequence the kitchen last, because the living room opens up faster and the trades flow better that way. He is not careless. He is optimizing in good faith for the wrong thing, and he will deliver the job on time while the family eats takeout until the last week of it.

The efficient plan and the right plan are the same plan only when somebody asked the client what comes back first.

The operator's own summary was blunter. The estimator has to understand the deliverables, and so does every step of the process behind him.

What is a deliverable based schedule?

A deliverable based schedule is a plan broken into the pieces of the client's operation you are handing back, ordered by the client's priority, each piece carrying its own start date, finish date and reporting line. Your completion date is still in there. It is no longer the only date the schedule can speak to.

Most contractors build a different kind of schedule without ever deciding to. The work breakdown structure follows trades and areas, float sits against a single completion milestone, and a class three estimate with contingency prices the envelope rather than the parts. Each choice is defensible alone. Stacked, they produce a plan that covers the job perfectly and cannot be queried by the person paying for it.

If the schedule cannot report on one deliverable in isolation, it is not structured to the client, no matter how accurate it is.

Ask the sequencing question before you price

The failure starts upstream of the scheduler, in estimating. The estimator does not always know the client's sequencing priority before he prices the plan, and the plan he prices is the schedule everyone downstream inherits. Nobody rebuilds it later. The sequence nobody asked about becomes the sequence the client lives with.

Estimating is also the worst place to lose a question. One estimator described his own work this way: it looks like a linear process, but it really is not, because so many things overlap and you work them simultaneously. Quotes, alternates, bid walks and internal reviews all run at once, so a question nobody wrote down is a question that does not get asked under pressure.

That is a documentation problem before it is a scheduling problem, and it gets fixed by mapping what an estimating process actually looks like when you document it honestly instead of the tidy version on the org chart.

How to build a project schedule around client deliverables

The mechanics are simple once the question has been asked. Five steps, in order.

1. Name the deliverables. List the pieces of the client's operation you are handing back, in the client's language, not yours. A refinery names systems. A hospital names rooms and floors. A homeowner names the kitchen.
2. Rank them with the client, in writing. Ask which one they want back first and why, then confirm the ranking in the same document that carries scope and payment terms. The why matters, because the reason is usually revenue.
3. Price the sequence, not just the scope. Sequencing has a cost: extra mobilizations, overtime, float you would rather have kept. Put a number on it while it is still discussable.
4. Break the work breakdown structure to the ranking. Each deliverable gets its own activities, float and finish, rolled up to the completion date rather than replaced by it.
5. Give every deliverable a reporting line. One status per deliverable per week, written so a non-contractor can read it without a call.

Only step three costs anything. The other four are ordering decisions, free at bid time and close to impossible to retrofit once crews are mobilized. Contractors who run this well have usually already done the work of systemizing the estimating and delivery side of a mechanical service business, because the schedule is where every earlier shortcut shows up.

The reporting the client actually wants

A refinery accepts a 45 day outage and wants its most profitable systems back first. That is the whole brief. Contractors routinely build a high-level schedule that covers the job competently and is not structured to those systems, so when the owner asks when one system returns, the only answer available is when the whole project finishes. The project controls lead who described this did not soften it: that is where a lot of contractors across the industry fail.

A schedule that can only report a completion date is not a project schedule, it is a countdown.

The client-side questions are smaller than contractors expect. Is it going to be sooner. How is it coming. Both are asked about one piece of the plant, not the job, and both are answerable in a line when the schedule is built to answer them, which is the same reason a scorecard works only when every number has an owner rather than a department.

It protects you in the other direction too. When a rotted back wall turns up behind the drywall, a schedule broken to deliverables shows which deliverable moved and by how much, before the extra work is priced. Change orders negotiated at closeout are change orders you lose.

---

When two schedulers cover thirteen states

Here is the constraint nobody mentions in the sales meeting. One contractor we interviewed runs project controls for thirteen states with two schedulers, and by the lead's own honest assessment one of them is a junior scheduler at best. Any method that needs senior judgment applied job by job will not survive that math.

So build the deliverable question into the front end, where it is a checklist item rather than a skill. A junior scheduler who inherits a ranked list of deliverables can build a correct schedule. A senior scheduler who inherits a lump sum plan and a completion date cannot recover the ranking, because the person who knew it was on a bid walk four months ago. That is the ordinary shape of the systems a business needs in place before it can grow: the fix goes where the information enters, not where it is missed.

It is also why the reporting format is worth building once and reusing across jobs, as one of the six systems that carry a business through growth rather than a heroic effort per project.

Put the deliverable question into your estimating SOP

The smallest useful version of this is one line on your bid walk checklist: which deliverable does the client want back first, and why. Ask it on the walk, write the answer into the bid file, and carry it into the proposal alongside scope, exclusions and clarifications. A ten second question decides whether the schedule is ever useful to the person reading it.

Then make it survive the person who asked it. A question living in one estimator's head is not a process, and the fix is the one that works anywhere else in a service business you are trying to systemize step by step: write it down, attach it to a step, give the step an owner. At The Systems Effect we map estimating processes by interviewing the people who run them, and this one line is routinely the highest-value change on the map, because it costs nothing and changes everything downstream.

Do it on the next bid walk. One question, in the file before anyone prices a thing.

Frequently Asked Questions

What is project controls?

Project controls is the discipline of agreeing scope, sequence, timing and payment terms up front, then tracking and reporting the job against that agreement. The clearest description we have heard came from a project controls lead who explained it as a home remodel: you settle what gets done, in what order, by when, and on what payment schedule, in writing. Scheduling, change order control and progress reporting are all enforcement of that original agreement.

How should a contractor structure a project schedule?

Structure it to the client's deliverables first and to your completion date second. Break the work breakdown structure into the pieces of the client's operation you are handing back, ranked the way the client wants them, each carrying its own start, finish, float and weekly status line. The completion date still exists, it just becomes a roll-up of the deliverables instead of the only number the plan can produce.

Why can a contractor not answer when one system comes back?

Because the schedule was built to cover the job rather than structured to the client's systems, so the only date it can report is the end of the project. The cause usually sits in estimating, where the plan gets priced before anyone asks which system the client wants back first. Whatever sequence the estimator chose becomes the sequence scheduling inherits, and by then nobody remembers it was a choice.

Does a small contractor need a scheduler?

Not necessarily, but somebody has to own the deliverable ranking and the weekly status line, written down rather than carried in one person's head. One contractor we interviewed covers thirteen states with two schedulers, one of them junior, so scheduling capacity is usually tighter than it looks. For a smaller shop, put the sequencing question in the estimating checklist so the schedule is correct before it reaches whoever maintains it.