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. Accurate scoping isn't just about boosting profits; it's about understanding how time is spent, anticipating timelines, and setting clear expectations for clients and stakeholders.

About a year and a half ago, I 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—$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 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

Despite the challenges, there are ways to mitigate the risks of over-scoping and improve accuracy:

Involve the Team: Engage the developers who will be working on the project in the scoping process. Their insights into the work required can help refine estimates.
Break It Down: The more granular the scope, the more accurate the estimate. Break tasks down into the smallest possible units of work.
Embrace Uncertainty: Accept that some tasks will be harder to estimate than others. Use ranges or complexity scores to communicate this uncertainty to stakeholders.
Learn and Iterate: Treat each project as a learning opportunity. Review actual hours spent against estimates and adjust your process accordingly.

By continuously refining our scoping process, we can improve the accuracy of our estimates, better manage client expectations, and deliver higher quality work on time and on budget.

Benefits

Implementing a complexity-driven scoping process can yield numerous benefits for technical teams and their clients:

Improved Accuracy: By breaking down tasks into granular components and assigning complexity scores, teams can arrive at more precise estimates, reducing the risk of cost overruns or missed deadlines.
Better Resource Allocation: With a clearer understanding of the effort required for each task, managers can more effectively allocate resources and balance workloads across the team.
Enhanced Communication: Using complexity scores as a common language helps teams communicate more effectively about the challenges and uncertainties inherent in technical work. This transparency can foster trust and collaboration between team members and stakeholders.
Greater Agility: By embracing uncertainty and building it into the scoping process, teams can more easily adapt to changing requirements or unforeseen obstacles. This agility is key to delivering successful projects in today's fast-paced digital landscape.

Wrapping Up

Switching to complexity-driven scoping at Built by Field has been a game-changer for us. It’s not just about making better estimates; it's about understanding our work more deeply and setting clear expectations with our clients.

By breaking down tasks and using complexity scores, we've gotten better at predicting how long things will take and how much they'll cost. This has helped us allocate resources more effectively and communicate more clearly with our team and stakeholders.

If you're looking to improve your scoping process, give complexity-driven methods a try. It’s flexible and easy to tweak until you find what works best for your team. We’ve seen great results and continue to fine-tune our approach to keep up with the demands of our projects.

Complexity-driven scoping has helped us deliver better work, meet client expectations, and stay adaptable in a fast-paced environment. We're excited to keep pushing the boundaries and improving our process.