As part of my job as Managing Partner at Atomic Object, I talk to clients who approach us with projects they’d like us to work on. A large portion of that work is spent creating detailed cost estimates. I strive to create accurate, detailed, ranged estimates that set projects up for success and give us a good chance to win the work.
Using detailed estimates on the custom software product development process can be risky. In this post, I’ll describe those risks and explain how we mitigate them.
Assumptions
By “detailed estimates,” I mean those estimates that contain fine-grained line items describing functionality or activities/services that will be completed, with accompanying cost estimates. These are the most precise estimates that will be created, but not necessarily the most accurate.
I’m making some key assumptions about the type of project being estimated, specifically that the project is a complex, custom software product without a well-known solution or pattern that can be applied.
Projects that often don’t exhibit the risks I describe here include deployments of off-the-shelf software, simple marketing websites and e-commerce implementations, and configuration of large, enterprise software platforms. Additionally, some projects may be better suited to a team-based model where a specific team size is allocated over a period of time.
Why Should You Demand Detailed Estimates?
Trusting detailed estimates can be risky, but you should still demand them from potential vendors for a few reasons:
- Detailed estimates are important homework; they demonstrate an interest and understanding of the project. If the people you’re talking to aren’t willing to do some work to win your business, do you really want to trust them with your project?
- Making an estimate gives your potential vendor an opportunity to prove they know their stuff, and it demonstrates their level of understanding.
- The sales process should be consultative. Good consultants will ask questions and make recommendations that bring new information to light in the sales process. You should get value out of the process.
Why Detailed Estimates Can Be Risky
While detailed estimates are necessary, using only detailed line-item estimates is not enough.
My experience in sales has taught me that this type of estimation generally results in the lowest estimates. That could be good for getting a project green-lit or winning a competitive process, but it’s bad in the long run. Lower estimates equate to a high risk of underestimating and having an under-capitalized project. Undercapitalized projects cause a great deal of pain for everyone, and they don’t cost less in the end.
In fact, fine-grained, detailed estimates are often the least accurate:
- The focus on specific features and activities misses important work that happens “in the cracks,” such as dev-ops, research and design, app hardening prior to release, design implementation and polish, and performance testing.
- You can only estimate what you can imagine on the front end (the point of greatest ignorance). Custom software development is an innovation process. We can’t know all details on the front end; the team will need to adjust along the way.
- What you end up building never exactly matches the feature set in the estimates because you learn more about what you should build along the way.
How to Mitigate This Risk
You can mitigate this risk by asking your team to estimate the project from several different perspectives and levels of granularity. We often use the following approaches:
- Gut Feel – Discuss the project details (30-60 minutes is usually enough) and lean on your experience to come up with a ranged time estimate (usually on the order of months) given a certain team makeup (e.g., two developers, one part-time designer). Multiply time by the fully-loaded team cost.
- Comparisons to Prior Work – Review your past portfolio of work and find a project that was similar in size and shape. Apply some simple adjusting factors to what the old project actually cost to build, based on your understandings of the differences between projects.
- Build a Team Model – Model out the weekly amount of time each person on the team will spend on the project, and calculate the associated costs. This lets you create a scenario that more accurately depicts a fluctuating burn rate (e.g., as you move through different project phases) than the gut-feel approach.
The above techniques will give your team more data points on how much the project will cost and how much time it will take. If you see any large discrepancies between your fine-grained and coarse-grained estimations, ask your team to spend more time understanding why the differences exist.
Taken together, the data points will tell a story about what a responsible range for the project could be. Set your actual project budget within the range, and sleep more easily at night.