The five stages, with the durations they actually run on.
Sean built this and we've sharpened it over the last few years to keep our work fast, competitive, and predictable. It works when we follow it. It breaks when we don't. My job is to keep it intact, so this page settles every question about how it actually runs. No interpretation, no exceptions invented on the fly.
These apply before you get to any single step. Almost all of the friction we've been absorbing traces back to one of these six going unsaid.
A stage's clock starts when the task is in EF with complete inputs, measured against end of day: 5:00 PM PST. Complete before 5:00 PM, it starts that day. After 5:00 PM, it starts the next business day.
The clock doesn't start when someone gets around to looking at it. It starts on the trigger. That's what makes a date a date.
The range is a capacity flex, owned by the team doing the work. High volume, it flexes toward the top. Low volume, a stage can land early.
It's an honest estimate of a range. Not a promise of the low number, and not a lever the requester gets to pull.
Before anyone gives a client a date for the next step, Biz Dev confirms the team can hit it. Design before a design date, Estimating's capacity before a P2E gets scheduled.
Biz Dev's responsibility · TrueEvery project enters the queue at its trigger and holds that spot. It doesn't move up because someone calls it small, simple, or urgent.
Priority only changes through the exception path, by tier.
Minor or major gets decided by the team doing the work, against set criteria. Not by the person asking. Minor according to the queue, not according to the request.
Dates get confirmed in the Alignment Conversation before any task is created in EF. The task reflects an agreement that already happened. It doesn't create one.
This is the rule we've been missing most. It gets its own section below.
Purpose, entry gate, deliverable, and timing for every stage. The pink notes settle the specific points that keep coming up.
Discuss client background, show strategy, tactical requirements, and confirmed budget. The team aligns on strategy before any design starts.
This step has been getting skipped, and sometimes runs without a confirmed budget. It's not optional, and neither is the budget. Present the Input Call Deck from the Biz Dev Sharepoint folder so we're all presenting from one source.
A collaborative conversation to review initial design ideas, traffic flow floor studies, and inspiration, in sketch format. Loose enough to move fast, aligned enough to commit a direction.
Keep sketches loose. Over developing this step makes the timeline impossible, and going too loose invites pushback. The cut from 5 days to 3 was conditional on knowing when the call is and when we're starting. Alignment is what supplies that now.
Take-Off is where we pressure test the direction in sketch form before we commit real hours to it. When we skip it, we're agreeing to design and price an idea the client hasn't seen yet. That burns two departments at once. If we're off base on the design, we've now wasted Design's time and Estimating's time, and we're walking in with pricing for a concept that potentially missed the mark. So skipping is conditional. We only do it when the project genuinely calls for it, agreed in alignment, for a stated reason. Not as a shortcut that quietly becomes the norm.
The concept rendered with branding applications and FPO artwork, with ballpark pricing to confirm budget alignment. This is the full design to cost loop, not a quick render.
Big Idea pricing is ballpark for budget alignment. Guaranteed pricing lives in Creative and Cost. And the deliverable is fixed. Extra scope like callouts, measurements, annotations, or multiple AI graphic finishes either fits the deliverable as defined, extends the timeline, or becomes a revision. It doesn't get layered on for free.
The expectation that a Big Idea turns around in three days isn't accurate, and never has been. It's an 8-day deliverable. 5 for design, 3 for estimating. The three days people keep pointing to is the estimating portion alone, mistaken for the whole stage.
The concept updated with a detailed render and a walkthrough of guaranteed pricing in a preliminary proposal. This is where the number becomes a commitment.
The goal is the item lister and drawings working out without overloading design. We've been moving into this stage before the design settles, which is exactly what creates the churn it's supposed to prevent.
Design revisions and final proposal review, a 1 to 10 score on the final concept, and the client's call. Steelhead, yes or no.
Projects sitting in limbo waiting on a signature is exactly why we lock the sign date early. Day by day visibility on remaining production runway is coming with the signature date view in Stream.
It happens right after the Design Input call, before a single task is set in EF. Right now it mostly isn't happening, and that's the source of most of the chaos. Tasks get created before anyone agrees to them, one person ends up setting the timeline, and sign dates land too close to the show for production to do its job right. This conversation fixes all three.
Full process, or skip Take-Off? The default is the full process. Skipping is the exception, and it has to be justified by the conditions of this specific project and agreed unanimously. Not decided by one voice, and not a habit we drift into.
The deliverable date follows from the strategy call and the current queue. Agreed here, then it becomes a task. In that order.
An accountability date for when the project has to sign, set far enough ahead of the show that production has a comfortable, quality window across everything else in flight.
The formal handoff from Design to Estimating, where estimating gets full context on the project before pricing it. It's how the price reflects what was actually designed.
We've added Sam from Detailing into these meetings. Detailing oversight catches build specific parameters early, a custom build or something that's going to drive cost, before it's baked into a number we have to stand behind.
Scheduling a P2E means confirming estimating's capacity first.
Most projects are predictable and run the standard flow. A real exception runs in its own lane, and exceptional means a defined tier, not "I'd like mine sooner."
Usually it's a Tier 1 RFP we prioritize for a partnership opportunity, or a budget big enough to move it ahead of the queue. It's invoked deliberately, by the nature and tier of the project, and agreed in alignment.
Every exception gets logged. That's how we keep the standard meaningful, by making the rare departures from it visible.
These are the points that keep generating back and forth. Each one has a single objective answer that follows from the ground rules above, so there's nothing left to settle case by case.
Hidden ambiguity lives in undefined terms. These are the ones that matter here.