How to Be Smart About Intermediate Milestones

By Leonard Kogan  |  September 29, 2026  |  In Practical Terms

How to Be Smart About Intermediate Milestones

Almost every large project has intermediate deliverables or milestones. A first TCO. A phased turnover. A block of space delivered by a date the financing depends on. 

Here’s what usually happens: the milestone gets set as a business target — to satisfy the pro forma, or align with what was promised to a tenant. Then it’s handed to the project team. 

And that’s where the trouble starts. 

A milestone is rarely just a date 

A milestone is a package — a date, a space, a quantity — but these are often treated as a fixed, singular event. A point in time. 

In reality, only one of them is usually what the client truly needs. The amenity floor for leasing season. The units the loan requires. One tenant’s space, ready to fit out. 

Understanding which one matters is the whole game. It tells you what to protect, and what you can flex. Get that right — and the right deliverables written into the contract — and you’ve changed the trajectory of the project before it starts. 

Set all three in stone, and you’ve boxed the project in. The stress you didn’t need to create lands right on the critical path. 

And there’s a cost beyond the deadline: chasing a milestone pulls crews and focus off overall completion. Hit the wrong one, and you slow the whole job for the sake of delivering a fraction of it early. 

Setting a smart milestone starts with the question most people skip: of everything we want — what’s really important, and what do we actually need? 

Because a milestone is a promise. The real question is: at what cost will you keep it? 

Your milestone has more than one variable 

Each element of that package may pull the schedule in a different direction. 

  • If you’re after a specific date — a loan closing, a seasonal opening — then space and quantity become the variables. You deliver as much as you can, where it matters most, by then. 
  • If you’re after a specific space — a floor, a tenant’s area — then the date becomes the variable. It may be driven by building elements or systems outside that area, so the date adjusts to whatever it takes to deliver that space, complete. 
  • If you’re after a specific quantity — the units the financing requires — then you’re solving for when that many units can cross the finish line together. 

Same milestone. Three completely different approaches. 

Often, the conflict on projects comes from never deciding which variable is the real one — so the team chases all three at once. 

Name the one that matters, and the schedule has a target. Leave it unnamed, and you’re writing it into the contract anyway — you just don’t know which one you picked. 

So figure out which variable is real before it’s in the contract. After that, it’s not a variable anymore. It’s an obligation. 

What’s actually driving your milestone? 

Once you’ve determined what you actually need, you run the schedule — and it tells you what it will take to achieve it. Certain things emerge as drivers. 

Sometimes it’s the structure: you top out, and then the race begins — mechanical systems, elevators, completion of interior work. 

Sometimes it’s the building enclosure and achieving watertight conditions, which releases the interior program behind it. 

Or it may be a building system — fire alarm, life safety — that has to be certified before anyone can occupy the space. 

That’s the difference between saying “we want 60 units at first TCO” and understanding that first TCO is actually gated by life-safety sign-off across a defined zone — which determines how many floors, and therefore how many units, are truly available that day. 

The same logic applies in healthcare, hospitality, retail, or pharma. The deliverable you can realistically promise is an output of the critical drivers — not a number you pick because it sounds reasonable. 

Until you know what’s actually driving your milestone, and how long those drivers really take, every date you set is shooting in the dark. 

But knowing the driver is one thing. On the best projects, you don’t just find it. You shape it. 

Don’t just read the critical path — engineer it 

Most teams treat the critical path as something they discover. Run the schedule, find the driver, plan around it. 

The best projects go further. They shape the driver itself. 

Take a fire alarm system. Treated as one building-wide system, it may become the single biggest driver to achieving early milestones — because nothing gets occupied until it’s signed off. 

But it doesn’t have to be that way. How the system is designed, compartmentalized, and filed can be engineered to match the turnover sequence you actually want. Zone it to the phasing. File it that way. Now a portion of the building becomes independently certifiable, instead of the entire project waiting on one sign-off. 

The gate moves. On purpose. 

That’s the difference between reading the critical path and engineering it. 

And fire alarm is just one example. The same thinking shapes far more — whether you build top-down, how the site safety plan positions the crane and hoist, where major mechanical and electrical equipment lands, how zones are drawn, how systems are split. 

Dozens of decisions. Far cheaper to get right on paper than to fix in the field. 

Here’s the catch: it only works if planning and design are deliberately coordinated early — before systems are engineered and filed. Not after. 

The point of all of this 

The most valuable scheduling doesn’t happen when the work starts. It happens before you’re committed — when the date is still a variable, the milestone is still a choice, and the path can still be shaped to deliver what actually matters. 

Use the schedule to make those decisions early. Not to explain later why they didn’t work out. 

Streamline Management Solutions provides senior-level construction planning, CPM scheduling, and advisory services for complex projects. If you’re facing a milestone your financing, tenants, or occupancy commitments depend on, we welcome the conversation. 

Want a schedule that actually supports your team's decisions?

Initial conversations are exploratory — focused on understanding your project's challenges, priorities, and constraints. Direct access to Leonard from the first conversation.

Discuss Your Project →