The Estimation Game
How long will this really take?
Pulse Works open office, morning standup. Ren has taped the network diagram from yesterday's planning session to the wall. Post-it notes with duration estimates are scattered across the table. Tetsu arrives with coffee and a skeptical expression.
Ren (蓮) "Alright, we need to finalize our resource (people, equipment, and materials assigned to project work) estimates. Tetsu, how long for the rendering engine?"
→ Resource planning connects people and capacity to the schedule. Without knowing who is available and for how long, duration estimates are fiction.
Tetsu (哲) "That depends. Am I full-time on this, or am I splitting with the other two projects?"
→ Tetsu is surfacing a core resource planning problem: activity duration changes based on resource availability. A task that takes 2 weeks at 100% allocation takes 4 weeks at 50%.
Ren (蓮) "I mean... we'll figure out the allocation later. For now, just give me the ideal estimate."
Tetsu (哲) "An ideal estimate. For a module nobody has built before. With dependencies on an API spec that isn't finalized."
Hina (陽菜) "Um, sorry — but shouldn't we estimate based on how things actually are, not how we wish they were? I read that there's something called analogous estimation (using data from similar past projects to estimate the current one) — could we look at our last XR project?"
→ Analogous estimation uses historical data from similar work. It's fast but only as accurate as the similarity between the past and current project.
Ren (蓮) "That AR demo we built last year took six weeks. But it was way simpler than this."
Tetsu (哲) "Three times the scope, same number of engineers. Twelve weeks minimum. And that assumes I'm not pulled away."
Ren (蓮) "Twelve weeks puts us past the deadline on the critical path. That can't be right."
Tetsu (哲) "It isn't what you want to hear. But it's what's real."
Ren stared at the network diagram on the wall. Three projects sharing one Tetsu. A critical path running through a bottleneck. For the first time, the shape of the problem wasn't abstract — it was a person sitting across from him, tired before the day had started.
Hina (陽菜) "What about three-point estimation (using optimistic, most likely, and pessimistic values to calculate a weighted average)? That way we'd at least have a range instead of a single guess."
→ Three-point estimation acknowledges uncertainty by producing a range: Optimistic + (4 × Most Likely) + Pessimistic, divided by 6.
Tetsu (哲) "Optimistic: ten weeks. Most likely: twelve. Pessimistic: if the API spec changes again, sixteen."
Ren (蓮) "Okay. So we're not padding — we're being honest. I need to take this to Saki and figure out what gives. The schedule or the scope."
→ When estimates exceed the timeline, a PM must choose: compress the schedule (add resources or overlap tasks), reduce scope, or accept a later delivery date. There is no free option.
Tip Always estimate duration based on actual allocation, not theoretical capacity. A developer at 50% doesn't finish in double the time — context-switching adds overhead.
Phoenix Project Connection In The Phoenix Project, the team discovers that optimistic estimates are one of the root causes of chronic overload. Accurate estimation — even when the numbers are uncomfortable — is the first step toward predictable delivery.