Complexity in Scoping Technical Work

Scoping technical work is notoriously tricky. Throughout my career, it's been a mixed bag - sometimes making a profit, other times not so much. Good scoping helps with the profit, and it also tells you how time really gets spent, when things will actually land, and what clients and stakeholders should expect.

About a year and a half ago, we started implementing complexity-driven scoping for all our projects at Built by Field. This shift was closely tied to our updated billing model, which is strictly time-and-materials based at $175 per hour of work.

Our complexity method is inspired by agile methodologies. We break down our estimates into detailed line items, aiming for as much detail as possible to ensure accurate scopes. Each line item gets a complexity value based on the Fibonacci sequence, which increases gradually at first, then more rapidly as the values get higher.

Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, ...

We use Fibonacci for two reasons. Complexity compounds rather than growing steadily, and people are overconfident by nature. It's very easy to say "oh yeah, we could do that in two hours" and be wrong, and we're all guilty of it. Our rule of thumb is that if it's a 4, it's a 5.

We aim to avoid high values since they signal uncertainty. I'd rather see many small values than a few big ones.

• Preferred Values: 1, 2, 3, 5, 8
• Values to Avoid: 13, 21, 34, 55, ...

The interesting part comes when we use these complexity values to inform our estimates. I learned a lot from Sanctuary Computer about using a "burn-down" rate. By measuring this against a complexity score, we can estimate the number of hours required to complete a task. Multiply that by our hourly rate, and we get our estimate. Tweaking our burn-down rate allows us to generate high, low, and average estimates, providing a clear sense of potential costs and range. It's also where the impact of higher complexity scores becomes apparent, as costs fluctuate with the level of specificity.

I haven't experimented much with our burn-down rate, but there's plenty of room to play. Our model is simple, with only a few variables, making it easy to adjust and find the right balance for you or your team:

• Burn-Down Rate: Set this as an average, or generate an average/median by capturing the burn-down for everyone working on the scope.
• Billable Rate: Use a blended rate like we do, or set different rates for various services. Each line item just needs a flag to indicate the service type, which drives the billable rate for the burn-down hours.
• Complexity Scale: You could adjust the scale, maybe not use Fibonacci, but I wouldn't recommend changing it.

Experimenting with these variables can quickly help you test different scenarios and find a scoping method that works for you. I got lucky and landed on fairly accurate estimates with the initial burn-down set. However, I've noticed that differences in skill levels between the estimator and individual contributors can lead to over-scoping in some cases.

Risk Mitigation

A few things keep over-scoping in check:

• Have the team score it: The people doing the work should score it. An estimator who is faster or slower than the team skews every number.
• Break down anything big: A big score means we don't understand the work yet. A 5 is the largest score we'll leave alone, and anything above it gets split into smaller items before it goes to a client.
• Show the range: Every estimate goes out with ambitious, average and conservative costs, and the spread between them is listed as the risk buffer, so the client can see where the uncertainty sits.
• Report every week: We share how we're tracking against the budget and timeline weekly. Clients respond poorly to big, bad news, but much more understandingly if you tell them something less bad, early.

What it changed

The biggest change is that clients can see how we got to a number. I've watched other groups quote "about 2,000 bucks" for a piece of work, and the first question is always "okay, but why?" Our estimates list every line item with its score and its range, so that conversation happens up front.

• No surprises: We agree on a budget number up front and report against it every week, so nobody finds out for the first time that we're 75% of the way through it.
• Trade-offs instead of revision counts: We don't promise two rounds of revisions. You figure out what a project is while you're doing it, so if design runs long, we talk about where to save time in development instead.
• Fewer things, done properly: When a budget is tight, the scores make it obvious what fits. I'd rather scope fewer things and do them right than promise more and have them feel thin.
• Getting paid for the work: If doing work becomes a cost, we go out of business. Estimating conservatively keeps us paid to do the work instead of paying to do it.

Wrapping up

The method isn't precise, and it doesn't win every job. Some clients see the range and decide it's more than they want to spend. Everyone who does go ahead knows what they're paying for and why, which is most of what I wanted from it.

Credit to Sanctuary Computer for the burn-down idea. If you want to try it, start with the Fibonacci scale and one blended rate, and adjust the burn-down rate once you have a few finished projects to compare against.