Why we think it’s ok to go over budget

If you’re developing apps or web software, you’ll know that it’s tough to keep these projects on track. They can be plagued by budget overruns, schedule overruns and unexpected complexity. Like most software companies, Pocketworks also experiences this. Fortunately, it rarely becomes a serious issue these days. How can this be? 

Develop good habits

We’ve learned that the best way to keep on top of things is to cultivate a simple habit; a weekly finance meeting where we review costs incurred and progress made. We then discuss any red flags associated with this data and can talk them through with the client. 

If you do this, when budget overruns happen you’ll find they are small, and everyone can see them coming. Simple, eh?

Side-note: This is an additional activity on top of the standard practices that we do, such as daily standups, backlog refinement and sprint reviews.

Two things you should start doing

You might think this sounds like common sense and it’s really straight forward. However, experience tells us it’s not easy to build new habits in business. You’ll need to put the effort in. Here are the essential “muscles” you’ll need to build: 

1. Make sure you can get data for every project: a) % progress and b) costs incurred
2. Build the discipline to review this data every week

By doing this, you’ll notice all sorts of interesting questions arise as you review it. 

If you’re not capturing the data and reviewing it religiously, we’d advise you relentlessly focus on the learning to do that. It’s made a huge difference for us. There was a time when we went wildly over budget and it creates all sorts of chaos. Not any more.

We’ve put a few tips at the bottom on how to go about this.

Why this gets results

Once you’ve learned these skills, you’ll find you only need to invest minutes in collating the data and reviewing it for any given software project. Then you can focus your efforts on healthy discussions around how to mitigate possible risks. 

Some recent examples of questions that came up in our reviews were: 

Q: How can we be 45% done with 15% of budget used?
A: Oh, it’s because the MVC is a lot smaller than the overall budget
Q: We’re running £900 over budget on this project. What’s that about?
A: Oh, we hit more issues with live deployment than expected. John is happy for us to bill this as part of the support contract.

As you can see, if you’re doing this every week there’s not much space for projects to get out of control. Build these habits and you can literally see problems coming at you early and decide what to do about them.

As our industry hero Fredrick Brookes says: “How does a project get to be a year late? One day at a time.”

As a result of these reviews, we’ve found that budget overruns are hugely reduced and are rarely a nasty surprise for us or our clients. 

A few practical tips

If all this sounds good to you, here are a few tips.

Who should be in the meetings? 

At Pocketworks, we invite product owners,  finance people and the Managing Director. The product team could be there too, but we feel it’s not very useful for them because the purpose of the meeting is to highlight financial risks, not developmental. Our product teams are interested in project health, but they find product roadmaps, scope and implementation more useful things to debate.

What should you discuss?

Focus your discussions on progress, cost and red flags. Agree on any future conversations that need to be had with the product team, execs and stakeholders. Avoid the temptation to discuss project scope or implementation specifics, your product team should lead those discussions.

Does this work with agile methods?

Yes. But you need to set out with the mindset of delivering business results rather than a fixed list of features. This allows you to set a reasonable budget-cap at the offset and then tweak scope as the project unfolds. 

Because you need to look at progress, you can use your project burn-up to get the % done. If you don’t have a burnup, you just need some way of guessing how far through you are. It doesn’t have to be exact. Start with a “gut feeling” if you don’t have any data. 

Obtain the cost incurred by looking at the expense of running the product or project team over time. Again, the numbers don’t have to be exact. Remember, you’re only trying to inform healthy conversations so having some data is inordinately better than no data. 

Start with gut feelings and then start measuring better later. Read “How to measure anything” by Douglas Hubbard to understand why we say this.

Being agile, we’d advise you treat estimates as nothing more than a tool to facilitate forecasting. In turn, this helps you have the right conversations at the right time. So, what you definitely don’t want to see in these meetings is anyone attacking anyone by saying “This has gone over budget what the hell are you playing at”. Estimates are always wrong, which why they’re just estimates. The only crime here is not looking at the big picture often enough. 

What about you?

We’d love to to hear how your company keeps its software projects financially in-check.