All Tech Projects run over budget, change our mind.
Why you should triple your budget
When I first started out in the tech industry, my first boss gave me a nice tip.
“Whatever they quote you… triple it.”
At the time I thought he was insane. Triple it?! Sure I knew that sometimes projects run a little over budget, but triple? I was young, incredulous, and naive — in my own arrogance, I ignored his advice.
Two months later, I was sitting across from him in our executive conference room. Had I experienced insane success and been promoted to an executive position, all in 2 months?
No, I had horribly failed as the project I was working on ran more than 3 times over the budget, with no end in sight. I was thankful to still have my job, and passing off the project to my boss so he could cover our losses.
At the time, I learned two lessons. First, that I should take advice from industry veterans.
And second, that all tech projects run over budget.
Why do they run over budget?
In my experience there are usually three core reasons why projects run over budget: feasibility, failure to account for issues related to development, and technical debt.
Feasibility
This is the issue most often plaguing software development. It starts the same everytime — you meet with other members, they quote you the time and cost they think it will take to finish it. The main issue here is that, usually, they quote based on how fast the project would go without being bogged down by reviews, changes, and technical debt (more on this later).
To make things worse, you’ll then go to management, who will halve all estimates. You’ll argue that this much isn’t feasible, but they’ll say some buzzwords (most notably “agile” and “sprint”) and shoo you out.
Then you meet with marketing, which was supposed to meet with the software engineers last week but didn’t. They’ll ask a bunch of conceptual questions that border on philosophical — “not what is the product, why is the product?” — and you walk out a little confused, but confident in branding. But tonight one of them will have an amazing new, innovative idea for how to position the product — and in a week they’ll be pushing something that isn’t even on the roadmap.
The Client
Another obvious issue lies in accounting for issues related to development, especially unseen ones.
How do you account for the unforeseeable?
As a rule of thumb, every time you think something might go wrong, assume it will. In software, something will ALWAYS go wrong. My developers have a running joke with a calendar on the wall: “days since bug.” That number never has and never will exceed 0.
And then of course, there’s the client. The client comes to you with an idea — they know what they want and need you to make it.
For those of you industry veterans that just did a double take on that last line, don’t worry, I was just kidding! The client absolutely doesn’t know what they want. There will be a dozen changes to the spec, several pivots and new features, and complaints when you build what they asked for but it doesn’t look as good in real life as it did in their head.
Technical Debt
And then there’s technical debt.
What is Technical Debt and what forms does it take? Well, in general, Technical Debt arises from rushed projects and issues related to development.
According to Techopedia:
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.
For all you software devs, this will sound very familiar. It’s the cost that arises from when you run npm install xyz and the developer behind it stops updating xyz. It’s the cost that arises when you write that one-liner at 4pm on a Friday and knock the ball out of the park, but it starts slowing down the app and increasing server load above 10 users.
For more on Technical Debt, there’s a nice piece by Tomer Dicturel explaining where we are and where we’re going that has been trending for the past few weeks on Medium:
What can we do to stop them from running over budget?
This is more of an open-ended question.
Every project is different and, to some extent, requires its own special solution. In general though, I’ve found that properly allocating a budget that takes into account failure will save you hundreds of thousands of dollars down the road in frantic panic.
Next time you get quoted $8000 and 7 days to build your app, stop and think: is this an accurate estimate? Rome wasn’t built in a day, nor was it built in a week for a couple grand — your app will most likely cost multiples of that quote, and you should expect that.
We found that most projects quoted at lower estimates (usually by freelancers) run over budget and never get completed — that’s an 88% non-completion rate.
So we collected more data — data on successful projects, that were completed and reached some level of success. We found that most projects hit a cost (not a budget — we took into account the final cost) between $160k and $180k.
At first thought this may seem insanely high, but these are the costs associated with developing long-term, sustainable tech. To make your life a little easier, we built out a calculator too — one that’ll properly budget your app for success. You can check it out at howmuchtobuildanapp.io:
Or check us out on Product Hunt 🎉!
Hi, I’m Wendy! I’m the Community Manager here at HowMuchToBuildAnApp.io, where we help you budget your next software development project for success!
