Are budgets made to be broken?
The data says yes. McKinsey found that 66% of enterprise software projects have budget overruns.
Why is that, do you think?
Because most budgets aren’t realistic. Or they’re created in a vacuum without real-world data to inform the actual numbers.
The best way to crush your software development goals is to start with a budget that’s been thoughtfully crafted from the very start.
And what kind of budget could be better crafted (or more accurate) than one you’ve created with your team, your stakeholders, and historical development time data in mind?
Let’s break down the step-by-step process of creating a realistic software project budget that’ll help you get easy approval from your C-suite and apply your development resources judiciously.
Make an Internal Software Development Budget That Wins Approval in 7 Steps
From creating healthy stakeholder relationships to diving into the nitty gritty of time data — execute these tactics to build an accurate budget that gets your internal software project off the ground and into production.
1. Define the Project (In Stakeholder-Friendly Terms)
Building an effective budget isn’t just about the numbers.
Far from it, actually.
When you need stakeholder approval to create or improve internal software for your company, adding some context will make it much easier for them to understand and get behind the project.
So, first up, create an elevator pitch that communicates to stakeholders what it is you intend to build.
A very important part of this quick rundown is the why.
Outgrown your current tech due to increased team size, new markets, or industry advancements? No out-of-the-box software solutions do exactly what’s required? Is this an opportunity to create efficiencies? Or increase integrations to help eliminate dangerous data siloing?
Once you’ve conveyed this point, the last — and maybe most critical — element of the definition is the value.
What value will this project deliver — in cost savings or in new revenue — and how does that compare to the cost of the project? Especially for internal expenditures, this is one of the most impactful ways to frame an expense to move beyond the sticker shock and portray the real value.
We like the term software design and development firm Atomic Object uses to balance value vs. expenditure: “Responsible budget.” What’s the responsible amount of money to put into internal software? Usually, it’s the amount where the tooling will be able to begin paying for itself. Nothing more, nothing less —or this entire undertaking could be pointless.
2. Connect with Stakeholders
You’ve got your elevator pitch full of easy-to-digest descriptions, purpose, and value statements.
Now you’re ready to bring it to your most important audience: stakeholders.
While it will depend on your company structure and culture, connecting with at least some of your stakeholders before you have a lot of numbers to run can be helpful for a couple of reasons:
- First, the right stakeholders can provide early buy-in. This can help you get your budget approved more easily and avoid overruns because more of your colleagues and team leaders will be fully on board.
- And second, advice from key, early-stage stakeholders will help you shape a more realistic (and, in many cases, more affordable) budget for an MVP (minimum viable product) version of your proposal.
Which stakeholders should you target at this point in the budgeting buildout?
A stakeholder can be anyone who will adopt, oversee, or approve the project. But don’t pick just any stakeholder at this stage. Focus on a select few to prevent overwhelm and avoid creating too big of a splash when you don’t have anything solid to show just yet.
In the case of internal software development, important early stakeholders include product users, leaders within the departments the product will impact (including for implementation), and any IT leaders you report to —directors, VPs, etc.
Later on you’ll probably work with stakeholders from the C-suite, finance, investors, colleagues, etc., as you fully round out your budget, eventually roll out the solution and shape new workflows around it, and conduct training.
3. Define Deliverables for the MVP
All the functionality and fixes and value you’ve been talking about for this new software project?
It’s time to flesh all of that out into what the actual product will look like and do.
And once that’s done, break each element of that down into the actual tasks that will eventually come together to create an MVP version of your final tooling.
Here are questions to ask yourself to make sure you’re thinking about all the key sections of the software, and the level of effort required for each:
- What are the individual core features and pieces of functionality that will enable the software to perform as promised? (No “bells and whistles” just yet!)
- What level of backend processing and infrastructure has to be implemented?
- How simple or complex does the code need to be,and can you use open-source resources to help build it more quickly?
- What level of user experience planning and design needs to go into this project?
- How many security and compliance measures do you need to take at this phase?
- What development methodology will you apply (Agile, Waterfall, etc.)?
- How much manual and automated testing should you account for?
- Are you budgeting for post-launch tasks like employee training, maintenance on server framework and infrastructure, plugins, libraries, etc.?
- What level of project management is required from you?
- How much stakeholder involvement are you expecting?
- What can be reused or purchased?
- Does in-house development versus outsourcing a project team make sense?
- What’s the timeline (a longer timeline usually means more spend)?
We know: That’s a lot of questions!
But that’s because we want to make sure you do your due diligence in the name of creating an accurate budget and reducing scope creep(and expense).
The scope of a project can easily creep up and out of control if you don’t outline requirements in a way that prevents misinterpretation by stakeholders, the devs building the project, and even you as the project lead.
4. Use Historical Data to Estimate Labor Costs
When you’ve got all the pieces of your MVP nailed down, here comes the crux of the entire budget —assigning each element a price.
There’s no tool better suited for this job than time data from past builds.
A huge percentage of the cost of building internal software is labor. So, it just makes sense that the best way to create an accurate budget is to look at historical time data for similar types of projects, features your team has created in the past, etc.
When you know how it’s been done before, you can start to understand how you’ll do it this time —including how long it will take and, thus, how much it’ll cost your company.
We should address here that time tracking has gotten a bad reputation among developers because of the way toxic managers use it as a weapon to impose control and punishment.
That is not a practice we support. Like, at all.
We time tracking (used effectively) benefits both engineers and the people who manage them.
For engineers, time tracking is a powerful tool for understanding your patterns and improving your productivity. For engineering leads, time tracking is the best way to conduct realistic project planning and protect your team from outlandish requests that put them in danger of burnout.
The 7pace Timetracker was created —and continues to be improved — by developers for development teams and their organizations.
It integrates right into your Azure DevOps and Azure Boards workflows (monday.com early access available) so you won’t even notice it running in the background. The data it collects is meant to help your team celebrate successes, calculate your pace, identify where some of your bugs may be creeping in, and accurately scope out any and every project.
Pro Tip: Budget With Developer Intricacies in Mind
Time and cost estimates should not be applied like a blanket to every team member.
The amount of time it takes developers to complete a task can vary greatly depending on experience, level of competence, working methods, and other factors.
Everyone’s individual experience and skill level should be taken into consideration when budgeting for labor. Better yet, let your development team assist in scoping the job for really informed estimates.
5. Add In All Other Expenses
The project will very, very likely include other expenditures in addition to labor. Think equipment, plugins and other tooling that supplements your development process or functionality, and so on.
Make sure you’re accounting for all of these items when totaling up your budget.
In addition, there are some other things to consider that aren’t necessarily items but that can still increase the cost of your project:
Sprint Length
Funnily enough, project budget can be impacted by sprint length.
Longer sprints may need less management, but sheer operating costs can add up. Shorter sprints will give you more control, but that control means more costly management time spent.
Project Timeline
Due to factors like inflation, shifting market circ*mstances, overhead, missed opportunities, personnel attrition, and a host of other unknowable variables — longer timeframes may result in higher costs.
And don’t forget Parkinson’s Law, which says that most tasks will take up all of the time we give them. So even if you think you have a quick project on your hands, if you give it a longer timeline it will inevitably become a longer project.
6. Contingency Planning
A contingency plan is a strategy put into place to deal with issues, like unforeseeable time sinks or team turnover, that may take place over the course of a software development project.
In the context of budgeting, contingency planning means building in some padding that will help you resolve and ride out any upsets to deliver as planned.
Consulting firm Axia suggests adding 5% of the total budget as a contingency during smaller, quicker projects. For much larger and more complex software builds, that contingency may need to be 30% or more of the project budget.
Gut Check: Does My Project Budget Make Sense?
Every software build is different —hence this whole process of creating a unique budget.
That said, if you need to take the pulse of the numbers you’ve come up with so far, we have something that should help.
The agency we mentioned earlier, Atomic Object, provides some real-life numbers gathered from 93 different software projects they’ve completed.
They found that the median cost to build a software product was $228,000, which accounted for about 1,750 working hours. Three-quarters of their projects fell under $600,000. From-scratch, consumer-facing products ran from $100,000 to $500,000. Rewriting existing software took a lot more effort with the average cost coming in just over $1M for 8,000 hours of work.
Of course, these numbers reflect the agency experience — which accounts for location, the going hourly rate at any given time, overhead, and serving a variety of industries. That said, we always find it helpful to peek into how other projects are scoping out to see if we’re making realistic assumptions.
7. Document Your Budget
Software development is, as you surely know, a process of discovery.
You can try to define project requirements, costs, and resources as much as humanly possible —but nothing can be etched in stone. Your project will inevitably change and evolve as you progress and learn more. The bigger the project and the more stakeholder involvement, the more likely this is to happen.
With that in mind, to the best of your ability, the last step in the budget-building process is to finalize it using documentation similar to the resources we’re about to share. And, to communicate it with any stakeholders who need to review and/or sign off.
Documentation, even through budgetary changes, helps guarantee that everyone is in agreement on the timeline and resources required. This hopefully prevents unpleasant surprises in the future.
To make the somewhat overwhelming job of monitoring your project budget easier, your documentation should be more than just a list of numbers. Ideally, you’re using a more robust system that helps you see how the budget breaks down across tasks, how spending so far stacks up against the budget, how much you have left, where you’re at risk of overextending, and whatever else you and your stakeholders need to know to be successful.
The good news is, you don’t have to start from scratch to build a vigorous budget.
You just have to keep reading.
5 Software Development Budget Examples & Templates
Start with these resources to create a trustworthy plan that leads to a successful, on time, and in-budget software build.
Simple Software Development Budget Template
From the service provider marketplace Clutch we have an editable development project budget template that breaks down costs into several categories, making the numbers much easier to digest and track. It also tallies up year-to-date spending, what you have left, and how far over or under you are on expected expenditure.
Download the Microsoft Excel spreadsheet to your computer or Dropbox here and start making it your own.
Phase-Based Estimator Template
This template from Smartsheet, made specifically for IT projects, was created to help estimate project costs.
It divides the project into phases and shows projected work hours, salaries, extras, and overall cost for each. To indicate whether a project element is not begun, in progress, complete, or on hold just select a status from the drop-down menu. The top of the form gives a brief overview of estimated cost, people involved, and hours committed —which is great for stakeholders who want to check in on the project without getting in the weeds.
Download the Microsoft Excel spreadsheet when you click here.
Best/Worst Case Estimating Example
IT consulting and development agency Freshcode does something interesting when estimating their projects. They don’t just aim to budget the most realistic case — they also plan for the best and worst cases possible for each project element and department, as seen in the example here.
This builds the contingency plan right into the budget and, when presented with context, can be a powerful way to communicate your budget and how you arrived at it to stakeholders.
Cost vs. Benefit Analysis Template
Also from Smartsheet is this cost-benefit analysis template that helps portray the value of a software project over eight years.
The first two tabs list the cost and benefit profile over the lifecycle of the project, the third finds the cumulative cost-benefit profile, and the fourth outlines a cost-benefit analysis of alternatives to the proposed software build.
Download the Excel spreadsheet right here.
Labor Cost Tracker Example
The IT Project Managers site provides an example of a labor cost tracker that closely follows each team member’s rate, hours worked per week, and total cost against the budget.
As labor is typically the most expensive, and volatile, element of a software project, including a sheet like this within your budget is a great way to keep a sharp eye on costs.
Time Data = Better Budgets
If your software development team isn’t already using time tracking, you’re missing out on a very powerful self-improvement tool for developers and a great budgeting, project management, and decision-making tool for development leadership.
Ready to see it for yourself?
Learn how 7pace helps software teams work smarter with better data — and fewer headaches.
