#UX and #design friends, we need to talk about estimating. …

Avoiding wars with clients is a matter of how you structure your engagements, along with how you spell out what you're doing in your proposals/contracts. That starts with estimating.

The biggest 2 rules I follow are these:

(2/12)

1. I do not EVER estimate a project in full from start-to-finish.

2. Once we're past initial Discovery (see below), I estimate in small chunks, e.g. "here's what will take us to the next iteration/review."

(3/12)

NEVER estimate past the point where you may get new information based on a build/test cycle.

Believe me when I say that you'll be wrong every time. Ask me how I know ;-)

(4/12)

So instead, first, I estimate a Consult/Discovery part that details what I think we need to do to get a handle on what's actually wrong here, and how long that will take.

For example...

(5/12)

...every client I have agrees to a time span, either me working directly with their team or me evaluating what they have and speaking with them. That is all pure fact-finding, nothing more. Getting the lay of the land (including politically).

(6/12)

There are no deliverables other than a summary of

(1) What I think is wrong, and

(2) What I suggest they do next, with or without me.

There's no scope for them to adjust, in other words. Nothing to change their minds about.

(7/12)

"I'm giving you X days/weeks, and at the end of that I'll tell you what I see."

Once I get past that, if they need me to advise on design/dev for an iteration, I chunk that out as a timeframe as well. X weeks with X review points, and those reviews are specified.

(8/12)

1 full day onsite, a 3-hour ZOOM session, etc. I don't ever estimate past a single iteration cycle or sprint, because there are too many unknowns, too many opportunities for them to second guess and change their minds about what they want to do.

(9/12)

This keeps the emphasis on the span of time instead of the tactical work at hand. If I give them a cost for 3 weeks, that figure reflects the distinct possibility that I may or may not spend 8 hours a day every day of those 3 weeks.

(10/12)

Whether I do or don't is irrelevant; I'm saying to them, "if you want my undivided attention for X weeks, here's what that costs."
You have to base your estimates on the only thing you can CONTROL, which is the TIME you spend.

Estimating tasks is a losing proposition.

(11/12)

You limit your risk by charging appropriately for that time — all of it. And you're also not inviting debates about how long something should or shouldn't take.

I hope that's helpful, and again — there's a LOT more where that came from here: https://t.co/s5JuUZnIEo

(12/12)

#UX and #design friends, we need to talk about estimating. I'd like to share some advice that's come up 3 times this week, in hopes it's useful. And it's echoed, by the way, in the BUSINESS OF UX course @EliNatoli and I are teaching at my UX 365 Academy (link at the end).

(1/12)

More from Tech

You May Also Like

#UX and #design friends, we need to talk about estimating. I'd like to share some advice that's come up 3 times this week, in hopes it's useful. And it's echoed, by the way, in the BUSINESS OF UX course @EliNatoli and I are teaching at my UX 365 Academy (link at the end).(1/12)

More from Tech

You May Also Like

#UX and #design friends, we need to talk about estimating. I'd like to share some advice that's come up 3 times this week, in hopes it's useful. And it's echoed, by the way, in the BUSINESS OF UX course @EliNatoli and I are teaching at my UX 365 Academy (link at the end).

(1/12)