Our Approach to Budgeting Software Projects

All custom software development projects have one thing in common; something unexpected happens. We use libraries and tools that reduce risk and make a project more predictable. But this is not a paint by numbers business. No one has ever built this specific piece of software before.

Which is why estimating the cost of a custom software project is so difficult. It’s an exercise in trying to predict the future. We often get the question “How much will this cost?” The better question is “How much should we budget to collaborate on solving this problem?”

Unlike off the shelf products, we are not configuring a set of tools that already exist. Said another way, it’s not like shopping from a menu. The reality is that while we use data to inform the budget, the main input is intuition.

We say creating a budget is more of an art than a science. But we have been shaping project budgets for the past 8 years. And while we will never be 100% accurate, we have a good idea of how a project might play out.

This process of setting a budget comes to life for us via four models. None of them are better than the other, it’s only a matter of which one makes sense for a given situation. And we always use more than one model to triangulate on a budget for a given project.

This post aims to create some transparency around a mysterious part of our industry. And give insight into exactly how we create budgets for a given project.

Rough-order-of-magnitude (ROM)

A ROM budget buckets a project into a range based on gut feel. For us, the ROM buckets are $50-75k, $125-150k, $250-400k, $500k-$1mm. Many times after a first call a client wants to know “What something like this might cost?” We would communicate a ROM budget at that point. And caveat that we should head into our Blueprinting process to understand more.

Another way of ROM budgeting is to consider the team size and calendar time required for the project. The result of that consideration is a “full time equivalent” (FTE) count and sprint count. Then, based on that number of hours and our hourly rate, we can communicate a ROM budget.

Comparable Analysis

At the time of writing this, we have shipped over 300 projects. Those projects range from marketing sites, to web applications, to IOT projects. With that experience comes a wealth of data. Our team uses Harvest to track hourly time entries on every project. This means we can always go back and see how much time we spent on a given project or problem.

When we encounter a new client project we will often look to that data. We ask “This kind of feels like Project X, how long did Project X take?” From there we ask, “Does this new project feel more or less complicated than Project X?”

This allows us to create a comparable analysis, not off of a previous budget, but from an actual cost. This works well when there are technology or feature similarities across projects.

Bottom-up Budgeting

This is by far the most time consuming approach, but it is necessary on every project we do. It is the best model at driving alignment with our clients and setting up our project teams for success. Our Blueprinting engagement produces two key deliverables; a Story Map and an Assumption Inventory. These are the backbone for creating a Bottom-up Budget.

Transparent assumptions inform how we estimate at the User Story level. Having them is critical in aligning on a healthy budget. Assumptions may include requirements around accessibility internationalization, or performance. These do not show up as individual User Stories. But they do impact the work required and QA time for each story.

Armed with these assumptions, we tackle a spreadsheet that has a list of User Stories. We assign a developer day estimate to each story. We use days as the unit since most of our projects are in the 3-6 month range and this unit works well for us. Summed up, we now have an estimate of the developer effort to complete the project.

But having worked on custom software projects for 8 years, we know where risk might pop up. As a result, we add buffers either across the whole project or across an individual Epic.

For example, we are more likely to misunderstand the scope of a project if we skip our Blueprint process . In that case, we add a buffer across the whole project. If we need to integrate with a specific 3rd party tool for authentication that we have never used before, that would introduce risk. We would add a risk adjustment to the Authentication epic in that case. The size and application of these risk adjustments are all based on feel and intuition.

With a range of developer days, we can now add time for Design and Product Management. Design and Product Management work tends to be more front-loaded in a project. But our designers and product managers are active throughout. For example, our PMs help with QA and our Designers program in HTML, CSS, and some JS.

As a result, we add a smoothed FTE count of Design and Product Management across the whole project. This smoothed FTE count is an over-simplification. But it works for us and keeps our process focused on the right things.

We base the FTE counts for Design, Product Management and Development on intuition. And our availability. If there is a hard deadline the client needs to hit, then we can design a Developer FTE count to hit that timeline. More people should equal a shorter timeline. But that is a limiting strategy. You can not infinitely add people because you can not parallelize all work. Also, we prefer small teams. We try to keep the FTE count between 1-3 Developers on any project.

Budget Anchoring

A Budget Anchoring approach means that a client has come to us with a budget in mind already. This is either because they have approval for this amount. Or they are raising capital to fund this project. If we don’t think it’s possible to deliver the desired outcome of the project given the proposed budget, we decline. Not every project is for us.

But if a ROM budget seems in line with what the client’s approved budget, then we do a Bottom-up analysis. Next, we take a scope axe to that analysis, and shape the project into the anchored budget. This process takes really good Product Management.

The challenge in this case is trying to visualize the order of operations of a project. And then deciding what to cut. Here are our considerations in this process:

• We have to identify any dependencies in the project. We can’t cut features that other features are dependent on.
• We need to understand your business and project objectives. That informs how to make tradeoffs in cutting scope.
• We tend to cut entire Epics – large chunks of the product – as opposed to cutting smaller stories here and there. By cutting stories, you run the risk of having a wide surface area of the product with very little depth. We lean into the idea that it’s better to have a “kick-ass half, than a half-ass whole.”

This is also a great opportunity for us and the client to align on how the other makes tradeoffs. Constructive conversations around how to cut scope is healthy. They tend to be a leading indicator of a successful relationship.

Why We Approach Budgets This Way and What to Expect

Our approaches to business and process are grounded in Our Constants. The way we budget is no different, and two Constants inform this process. First, Own the Outcome. We need to align on a healthy budget that will allow us to deliver quality software. Software that will deliver the outcomes you want in your business. A budget constraint can be helpful for making tradeoffs. But if it is too tight, we may not be able to solve your business problem. We can only take ownership over an outcome if we have enough budget to do so.

The second Constant is Be Authentic. We may do things different than other agencies. And those differences may show up in our budgeting process. Here are some topics related to budgeting and how we handle them.

• We tend not to be the cheapest option. We deploy a full cross functional team for every project – we don’t offer staff augmentation. And all our team members live domestically. These leads to a higher hourly rate than offshore partners.
• We tend not to be the most expensive option. We prefer to work in smaller teams which helps manage costs. Our Designers write code. Our Product Managers do QA. We value asynchronous communication. These three things limit the amount of handoffs required in a project. Handoffs can create bloat. Finally, we have an in-house Opex team that leverages the best open-source software available. We also contribute to the open-source software community. This allows our teams to work very fast in a comfortable and repeatable way.
• We tend not to respond to RFPs outright. We only uncover the risks and assumptions of a project through in depth discovery. These assumptions are a backbone of how we budget. That is why we always lead with our Blueprint Engagement.
• We tend not to negotiate prices. From our perspective, our analysis is thorough. And we are confident that the budget number we present would allow us to deliver value to your business. It’s also a price that makes sense for our business and allows us to take care of our amazing people. If you need a lower price, then we need to reduce the project scope.
• We tend to think of a budget as a bet. For a given budget, there is almost always some version of the software that can be built within that budget. But the right question to be asking is “How much is solving this problem worth to the business?” And “Are we comfortable making a bet that we can solve it with this specific software project?” These are the types of questions we ask in Blueprinting that help us shape a healthy budget.

We hope this information pulls back the curtain on what can be a mysterious part of our industry. If you want us to help your business grow with custom software, the best place to start is by contacting us here.

×

Subscribe to Our Newsletter

If you made it this far, you should sign up for our monthly newsletter. Get our latest articles and insights delivered each month.

First Name*

Last Name*

Email*