How I Scope Projects (Without the Nasty Surprises)

Why Most Estimates Are Wrong

Here's a secret the tech industry doesn't want you to know: most project estimates are educated guesses wrapped in confidence.

I've been on both sides of this. Early in my career, I gave estimates that were wildly wrong. Now, my estimates are usually within 15% of actual—not because I'm smarter, but because I changed my entire approach.

Let me show you how.

Phase 1: The Questions Nobody Asks

Before I write a single line of a proposal, I need to understand three things:

What problem are we actually solving?

Not what solution you want—what problem you have. These are different questions with different answers.

When a client says "I need an app," I ask: "What happens today without the app?" The answer tells me whether they need an app, a spreadsheet, or sometimes nothing at all.

Who is this really for?

Not who you think it's for—who will actually use it daily. I've seen projects fail because they were designed for executives who'd never touch the software, while ignoring the operators who'd live in it 8 hours a day.

What does success look like in 6 months?

If you can't describe what "working" looks like, we can't build it. This question also reveals hidden expectations that would otherwise become scope creep.

Phase 2: The Red Flags I Watch For

"We need this ASAP"

Urgency without clarity is a recipe for disaster. If it's truly urgent, there should be a clear, simple scope. Complex projects and tight timelines don't mix.

"Just make it like [competitor]"

This tells me we're building a copy rather than a solution. It also means we're inheriting all of someone else's product decisions without understanding why they made them.

"We've tried this before and it didn't work"

This is actually useful information. I dig into why it failed. Usually, it wasn't the technology—it was misaligned expectations, poor communication, or scope that kept expanding.

"Can you just give us a ballpark?"

Ballparks are where projects go to die. A "ballpark" of $50-100K becomes a mental anchor of $50K. When the real estimate comes in at $80K, there's disappointment—even though it's within the range.

Phase 3: How I Actually Estimate

Step 1: Break everything into components

Not features—components. A "user login" feature contains: authentication system, password reset flow, session management, security hardening, error handling, and testing. Each component gets its own estimate.

Step 2: Estimate in ranges, not points

I never say "this will take 40 hours." I say "this will take 30-50 hours, most likely around 40." The range communicates uncertainty. Point estimates pretend uncertainty doesn't exist.

Step 3: Add the multiplier

After estimating all components, I multiply by 1.3-1.5. This isn't padding—it's accounting for the things I know I've missed. There are always things I've missed.

Step 4: Check against intuition

After all the analytical work, I ask myself: "Does this feel right?" Sometimes the number feels too low or too high. That gut check has saved me many times.

What This Looks Like in Practice

A recent project example:

• Initial client request: "We need a customer portal"

• After discovery: "We need a self-service dashboard where customers can view invoices, update payment methods, and submit support tickets"

• Component breakdown: Authentication (20-30h), Invoice display (15-25h), Payment integration (25-35h), Support tickets (20-30h), Admin dashboard (30-40h), Testing & QA (20-30h)

• Raw total: 130-190 hours

• With multiplier: 170-250 hours

• Final estimate delivered: 180-240 hours

Actual time spent: 205 hours. Right in the middle of my range.

The Honest Truth

I don't have a magic formula. I have a process that forces honesty—honesty about what I don't know, honesty about what could go wrong, and honesty about the gap between what clients want and what they need.

The best estimate is one where both sides understand the uncertainty and have agreed on how to handle it when surprises happen.

Because surprises always happen.

What's your biggest frustration with tech project estimates?