The Fairway Technologies Blog

Asymptotic Project Delivery: How to Scope and Estimate Projects Successfully

In No Comments
June 26, 2018

Each weekday morning I wake up, eat breakfast (most days) and head into the best job I've ever had. In my career, I started as a software dev, moved into some management roles, did some product work and some consulting work too. Ultimately, I landed at a great consulting company with the title of "Business Solution Architect." To be honest, I'm not all that concerned about the title; I'm far more interested in the work. As a BSA, I get to partner up with our Business Development team and talk with clients about how to leverage technology for their particular business need. Having conversations with potential clients is one part the job; the other is to scope out the work we're going to do with them.

When I first started "scoping" contracts, I found the work extremely challenging (it's still challenging...just a little less extreme). The most challenging projects to scope are the ones where the client gives us complete creative license (creative license with the architecture and tech stack...not budget). Sitting down and designing a system from scratch can be difficult, but it's not the point of this blog post. What I would like to share is my process for estimating work for the projects that I'm scoping once I've got an architecture in mind.

The Micro and Macro

I believe my process for scoping and estimating projects is important in the micro and the macro. In the micro, scoping and estimation needs to be as accurate as possible for the success of the company. If we're over budget, behind schedule, or the client isn't happy with the scope of the delivery, we won't be getting a lot of repeat and referral business. In the macro, I want to help repair the reputation of the software development industry. Right or wrong, clients that I talk to are all concerned about projects going over budget or taking twice as long (or both...). This opinion is either founded on actual fact, as they've been burned in the past by poor project delivery, or it's something they've "heard." Either way, I want to show people that high software can be built on time and on budget.

Ok, let's get to the fun stuff: how to scope and estimate projects for successful delivery...

Just Two Questions

Successfully delivering a software project is really pretty simple. You only need to answer two questions:

  1. What are all the things we need to do to complete the project?
  2. How long will all of those things take?

Well, although it's only two questions, they are two very difficult questions to answer. And of course, both of these questions seem stupid to even ask because if we all knew the answers, there wouldn't be a stigma around software projects going over budget or missing deadlines.

That being said, those two questions, however pointless they might seem, are crucial to on-budget, on-time software delivery. Here's why...well actually before we jump to the why, let's take a trip back to middle school geometry class.

First, let's talk geometry, specifically asymptotes. From Wikipedia:

In analytic geometry, an asymptote (/ˈæsɪmptoʊt/) of a curve is a line such that the distance between the curve and the line approaches zero as one or both of the xor y coordinates tends to infinity.


Asymptotes are curves that approach a line but never actually achieve contact. Look at the plot above, specifically the curve in the upper right of the graph. The ends of the curve approach the y and x axes, but never actually touch, even if you go to infinity. Now that we've got this mental model…

How does this relate to project delivery?

I think a lot about this concept. It applies to a lot in life, including project delivery. I think about how we should try to aim for perfection (in this case perfection is complete answers for the two questions above), and how the pursuit produces better results than merely attempting to reach "good enough." I picture each of the questions above a different axis on that graph and I'm working to close the gap between the graphed line and each axis.

Thinking of All the Things...

When I'm asked to assess how long a particular project will take, I start by writing down everything I think would need to be done in order to accomplish the project. Granted, this does take years of experience to walk a delivery in your mind and listed out all the pieces, but it's completely achievable if you can block off time to think about it. It may take a couple of passes but it's definitely doable. 

The steps you list out might even be at various levels. For example, you might have a lot of experience with load testing and you already know all the things that need to be done do implement it, but lack detail on two-factor authentication. The key is to list out, as best you can, everything that needs to happen: setting up environments, deployments, unit testing, meetings, vacations, company meetings, holidays… List out everything you can think of that would need to transpire between the start and end of a project (if possible, do it in chronological order).

Inevitably, you'll find yourself faced with tasks you don't fully understand how to accomplish--when you do, you've got options:

  • Ask other engineers that might have experience and could help you list out what would need to be done.
  • Put in "investigation" line items. Use those as buffers to figure out how long the actual "thing" will take after investigating it.
  • Pause and do some research! Even an hour’s worth of research might help you understand if a task would take an hour, a day, or a week.
  • All of the above!

Ok, great! Now we've got a list of all the tasks that need to be accomplished in order to complete the project. Next, let’s tackle step two and figure out how long each line item will take to do.

...and Knowing How Long They All Take

There are many methods for estimating software, for example: Delphi, Work Breakdown Structure, Three Point Estimation, Functional Point Method to name a few. Personally, I use Three Point Estimation to determine how long something will take. Here's why:

I believe that the mental exercise of thinking about the best and worst-case scenarios can help you think about the "corners" of each task. Without those mental exercises, and especially considering the worst-case, I find that my mind will fixate on an optimistic view of delivery, and I end up underestimating many of the tasks. Although I don't believe that every task ends up actually being worst-case, if you use the Three Point Method, especially over a large set of tasks, I do believe it closes in on being accurate. And even if it isn't exactly accurate for each task in your list, over the entire set of tasks you'll most likely end up within a small percentage of actuals, rather than orders of magnitude. 

A Few Things to Note

I've used this process dozens of times, and in using it I've learned a few things.

  • You probably can't have too many tasks in your list. I've even gone to the detail of putting code review tasks in for features I think would be complicated to review.
  • Some functions of successful software delivery are a function of project duration and level of effort.
    • For example, project management is something I generally estimate in quarter-time, half-time, or full-time work. So, if I believe the project needs full-time project management, and the project should take 15 weeks based on my estimates, then I'll add in 600 hours for project management.
    • Design and QA can fall into this category as well.
  • Every project is a snowflake (more or less). You may need to align the tasks with the needs of the project.
    • For example, if your client doesn't exactly know what they want, or maybe they keep shifting what they want, it may be a good idea to add in tasks for requirements gathering and documentation. 
  • Do not globally pad. Just don't. I know you want to, don't do it. Being able to understand what the original estimate was for a task is crucial both for yourself and for the delivery team. For each project I scope, I try to circle up at the end to get feedback on the areas in which I could have done better. Without knowing what the exact estimate was, I won't be able to adjust for the next project. Plus, if the delivery team is using the estimates to gauge level of effort to complete a task, getting padding tasks can be misleading.
  • Take breaks and know when to walk away for a bit. Trying to think of all the things is mentally exhausting (at least for me). I might start in on the process, feverishly writing down task after task, and then in about two hours, I'm watching woodworking videos on YouTube and the level of detail in the tasks is completely different than when I started. Know your limits and make sure aren't phoning it in at the end.

Tying it All Together

We started off pursuing the answer to two very simple questions:

  1. What are all the things we need to do to complete the project?
  2. How long will all of those things take?

Just answer both of those questions and all your software projects will be a success.

 Just kidding, this stuff is super hard, but I hope the next time you're asked to estimate a project or feature or bug fix, you'll think about the pursuit of the questions above. Remember, it's probably not possible to fully answer both, but the attempt can produce some really accurate results.