What to do if budget is a major issue for your project

So you're ready to start your project. You know what you want built. You have the time in your schedule to have it built. And you have an idea of who will build it.

But after talking with a few software consultants, you've gotten a bit of a sticker shock.

High demand

On one had, software development is in high demand now. But it will only get worse. Organizations are training elementary school children how to program because in 10 years they know we won't have enough software developers to meet the demand.

(And we don't even have flying cars or even fully self-driving cars. Those will need software written too...)

This demand means you're project is competing with every other project and the consultants are trying to pick the best ones for themselves and for their clients.

Let's be honest. Having a larger budget available will help almost any project, even if the budget is not used on a consultant.

Your software got popular and now you need more servers? Buy more.

Had a new idea for a feature? Buy more time.

But that's not going to help you if your budget is already an issue. In that case, here are three things you can do to stretch your budget.

1. Reduce unknowns in the estimates

Have a deep conversation with your consultant about each feature you want and its cost. When estimating, a consultant has to balance dozens of unknowns and factor all of them into a single number.

If there are a lot of unknowns around a feature, they are going to use higher estimates for it. Any vagueness in the specification is going to be reflected in a higher estimate to you.

But that doesn't mean you should cross every T and dot every I either. Unless you're a software developer yourself, you're going to have a hard time seeing what the big unknowns are for each feature. You might over-specify the trivial and under-specify the important.

Talk with your consultant and find what areas they are uncomfortable with or that have significant unknowns. Focus on these and you could cut your investment.

My recommendation: Whenever a client has a project with a lot of unknowns I advise them to build a prototype or two. These incomplete systems help them and myself learn about what they're doing, which we can feed back into our estimates. I've had times where the prototypes discovered a huge time savings which let us comfortable reduce the estimate (and cost) by 5x.

2. Review your buffers

Similarly, all features have a bit of a buffer built in. It might take a consultant two hours to build a database-driven feature in Rails but then there is another hour to fully test it, another hour to integrate it into the rest of the system, another hour to document it, thirty minutes to deploy it to production with a smoke test, and then a few hours for finding and fixing minor bugs. So this two hour feature ends up taking eight hours.

That's partially why buffers are built into all features. Writing code is just a portion of the total time to deliver a feature.

(Tools and processes can improve this significantly for routine features. In my process I use deployment systems to speed up deployments to production to one minute, a continuous integration server to run the smoke test for me (saving me time), and a testing process to fully test a feature during development)

But there is another aspect to buffers. When a feature looks difficult or new or risky in any way, additional buffers are added to account for unknown unknowns. An unknown unknown is something that you don't know that you don't know. They are by definition, vague and surprising. In routine development they are rare but with innovative features or cutting-edge technology, they occur regularly.

These unknowns can significantly increase the amount of buffer used on a feature. 30%, 50%, and even 300% buffers are not unheard of.

The only real way to find and understand unknown unknowns is to do the work. You can start with a small-scale prototype to tease some of the out of a feature but sometimes unknowns they don't occur until you're deep into the project.

But finding even a few early on might help reduce the budget enough. Spending 30 hours to prototype a system with a 6 month estimate can provide enough knowledge to cut the costs enough to pay for itself (and also reduce the risk of failure significantly).

My recommendation: In addition to using prototypes to reduce unknowns, I try to give estimates in ranges. This makes it clear how much of a buffer each feature has built in. A 3-4 hour estimate is pretty solid, especially when compared to a 1-12 hour estimate. Even though the latter might be quicker (1 hour) it also might take 3x as long.

3. Reduce scope

The final tool you have to adjust the budget for your project is to cut features, also know as reducing the scope.

Features add up to what your total investment is.

Remove or reduce features and your investment is reduced.

Naturally, this can affect the return you're going to get from it too. By cutting important features you won't get as much value out of it. But that trade-off might be worth it, especially if there isn't anyway at all to afford everything in your budget.

There are two ways to look at features to reduce.

3.1 Cut non-core features

The first and easiest cuts are to remove all non-core features. Done right, this can dramatically reduce your investment.

Most projects are created to solve a core problem or have a core improvement. This means there are features that directly contribute to that goal and features that only complement/supplement that goal.

For example, in a social network the goal might be to connect with other users. Letting users find other users and contact them would be core features. Registering and creating a profile would be supplementary. Useful yes, but you could get by without them.

Sometimes it's helpful to think about everything you want in different stages. The first stage is the bare minimum or Minimum Viable Product (MVP). The second stage builds on the first stage to improve the core features and add supplemental ones. The third, fourth, fifth, etc stages continue to build on the previous. Thinking This way you can use your budget to get the first stage and reinvent your returns into the next stage.

3.2 Reduce a feature's scope

Another way to cut features is to reduce them. Instead of supporting a dozen different ways to register you support one.

This is best used on supplemental features that are required for the project. It can be tough to reduce a feature enough to where it provides value but doesn't impact your budget, but a good consultant can help with this.

My recommendation: I try to be upfront with clients about their budget early on. This helps me figure out how lean we can build the core to accomplish their business goals. This also helps us think in stages so we can quickly build and release the first stage, start getting a ROI from it, and use that ROI to fund the second stage.

Using these three steps can help stretch your software development budget a bit further.

1. Reduce unknowns in the estimate

2. Review your buffers

3. Reduce scope

Or you can call them The 3 R's to Reducing Your Budget. Or something like that...

One of the best pieces of advice I can give is to start talking with a software consultant early in the process. Their experience can guide your planning and help you make the most effective use of your development budget. My Trail Map service is a formalized out-growth of this process that I use for clients.