While I was working as a RelMap Consultant at Prospiant, one of my tasks tied to improving on-time delivery was to help implement stage gates.

They already had an initial proposal for what the gates should be.

The issue wasn’t agreement.

The issue was traction: detailed milestones, ownership, and a practical way to execute the gates across long, construction-heavy projects managed in Procore.

The moment I knew we had a problem: stage gates existed as a proposal, but nobody could point to the concrete tasks and owners required to clear them—so “gates” were becoming a conversation, not a system.

A real-world implementation where stage gates became usable—inside Procore.

The problem

Prospiant’s projects are long in nature, and most are construction-heavy.

They’re run by an internal PM team and managed in Procore—so any stage-gate approach had to work in that reality.

There was already an initial proposal for stage gates, but it wasn’t yet executable:

• Gate definitions weren’t tied to clear “exit criteria”
• Milestones and dependencies weren’t broken down enough to run day-to-day
• Ownership wasn’t explicit enough to drive accountability
• Leadership didn’t have an easy way to see stage-gate compliance across projects

So the risk was predictable:

Stage gates would remain a concept—something people referenced—without becoming how projects actually moved.

What I did

I treated this like any execution system problem:

Start with clarity, build the milestones, then embed the workflow where the work happens—supported by reporting that leadership can actually use.

1) I refined the stage gates with stakeholders closest to the work.

I reviewed the initial stage-gate proposal and consulted with a number of internal resources to understand how projects were really run and where they were stalling.

From there, I assembled a presentation recommending what the stage gates should be—and, more importantly, what “clear” should mean at each stage.

We worked through it together and finalized the stage gates as a shared model.

2) We decomposed each gate into the milestones required to clear it.

Once the gates were finalized, we outlined the milestones needed to pass each gate.

Not vague checkpoints—real tasks and dependencies.

This is the point where stage gates stop being abstract and start being actionable.

3) I implemented the gate milestones in Procore using checklists.

Next question: how do we run this without bolting on another tool?

Because projects already lived in Procore, we explored using Procore checklists.

I didn’t have prior Procore experience, so I asked for a login and started learning by building.

I configured checklists so that each stage gate was supported by a set of milestone tasks that could be:

• Assigned to accountable owners
• Given due dates
• Tracked consistently across projects
• Applied to new projects so the approach scaled

4) I worked with the Procore team to create a compliance report + dashboard.

Stage gates only help if you can see them.

I partnered with the Procore team to build a report that exported checklist data so we could create a dashboard view of stage-gate compliance.

I used that data in my biweekly updates to the executive team—creating a shared view of where projects were moving and where they were getting stuck.

5) We addressed the adoption curve—especially the discomfort with visibility.

We implemented this through pilots.

We selected a couple of projects, trained the PMs running them, and started reviewing results internally and with leadership.

As visibility increased, there was some pushback from PMs who felt the system created too much scrutiny.

PM leadership worked that internally and reframed the intent clearly:

The goal wasn’t oversight for its own sake.

The goal was early visibility so PMs could get help sooner—resources, decisions, escalation—before issues became unavoidable schedule hits.

Why this mattered

During my tenure (a couple of months), we expanded the process to eight projects.

Because the projects are long, none progressed far enough to claim clean quantitative improvements in on-time delivery during that window.

But we did get a meaningful qualitative outcome quickly:

Once stage gates were visible, leadership could finally see what was slowing projects on the front end.

Specifically, the compliance view made it clear that sales-related deliverables were frequently not being completed in time to allow projects to enter the design stage.

That wasn’t a “PM execution” problem.

That was a front-end readiness and accountability problem.

And the stage-gate system made it visible early—when intervention still mattered.

If you’re trying to improve delivery predictability, my advice is simple:

Don’t start by polishing the stage-gate diagram.

Start by making stage gates executable—inside the tool your PMs already use.

That’s when “process” becomes performance.