This piece was originally written for and published on Native, the journal of the Digital R&D Fund for the Arts.

Budgeting is an art. People who are good at it approach the empty spreadsheet like a canvas, using formulae to move numbers around until they’ve painted a glorious picture of their future project.

What happens when you’re working in a space you haven’t encountered before though? Projects with innovation at their core are, by definition, dealing to some extent with the unexplored. How do you paint that?

Significant but necessary levels of uncertainty need flexible, fluid and responsive budget management. It’s a difficult thing to do. It’s also an almost impossible thing to offer generic advice about. That said, there are things I’ve learnt over the past few years – often the hard way – that I wished I had known before.

#1 Fight hard for a decent contingency.

Add a couple of percentage points and build up defences around your contingency: it’s a budget line you will use. Expect to stumble across barriers you hadn’t anticipated, with the contingency resources you’ve safe-guarded becoming vital as you attempt to clear them.

You may well be told your contingency is too high. After all you’re probably not dealing with huge health and safety risks, or items that are subject to overnight price inflation. Have a strong and cogent argument that illustrates the inherent instability of the space you’re working in and explores the type of impact this could have on your process and therefore your budget. A decent risk assessment can be helpful here, focussing on the unpredictable nature of innovation.

#2 Both testing and marketing are necessary but costly.

The first time I produced a digital project, I hadn’t taken on board how important both testing and marketing were to the process. As a result, both elements were under-resourced, the end of the project was fraught, and of course the results weren’t as good as they could have been.

Make sure you build enough time into your schedule for a thorough testing period, including time to make amends based on issues your users bring to light. You may want to build a number of test phases into your process, allowing you to gently and iteratively adjust your plans as you go. This can be a lot easier than waiting until the eleventh hour, at which point so much of what you have done is set in stone and can’t be reversed. Remember it’s not just the testing itself but also the potential amends that you need enough budget to accommodate.

Recognise that product build is just the first part of the story. You also need a set of activities that allow you to locate and attract your users. This marketing and promotional activity requires intelligence and resources. Pay particular attention to this if you’re making a native app: you have many competitors in this space, and discovery can be difficult.

#3 Collaborative practice can cost more, not less.

If you’re budgeting to bring a dispersed team together to work in a genuinely collaborative fashion, it’s going to take time. Relationships take a while to develop, and sustaining a cluster-mind that is working together to push the boundaries of existing practice involves a lot of time in the same room overlapping on several tasks, particularly during the early stages of project development.

That time can be really expensive, particularly if you’re working with some people whose rates may be higher than those you’re used to. To make remarkable digital work, we need to bring together people from different sectors to work alongside one another as equals. A theatre-maker may be working with a graphic designer, a mobile developer and an academic fellow. While person x may be pleased with a £250 day rate, person y is more used to charging £700 plus per day. Be prepared for this: do your research and budget accordingly.

#4 Agile or iterative methodologies need agile budget management.

It sounds so obvious, doesn’t it? But this a tricky thing to impress on the people who wield the financial power – maybe your funders, your board or your client. In the arts we tend to work in front-loaded environments. Schedules, budgets and even outputs have to be articulated ahead of project start. In the best cases, good communication with your stakeholders can lead to a healthy understanding of the needs of the project. That in turn should mean there’s room for a bit of shape-shifting. However, the bottom line often can’t and doesn’t change.

The reality with agile methodologies is that your research will lead you to discoveries that may fundamentally undermine the assumptions you made in the early stages when working on concept. Before you start using these methodologies, think hard about whether, financially, you will be able to accommodate the changes they point towards. Do you have access to or can you generate the additional funds you may need to increase the scope or complexity of your project?

#5 Think about the future.

When you’re working in the digital realm it’s easy to forget that you’re about to generate a bunch of collateral materials which, while intangible, still need looking after. For example, a website needs hosting, and hosting costs money. If you’re building a website you’ll need to a) plan to take it down at the end of the funded period, b) include a budget line for x years of ongoing hosting, or c) build the hosting costs into your core operating costs. The same applies to other ongoing elements of your project such as community management, ongoing technical maintenance, editorial etc.

When you’re setting up your initial project budget it can be a good idea to include sustainability planning as a specific line. If you’re making something that you think should have a life beyond the scope of your initial funding, somebody – either someone from within your organisation or possibly a consultant – will need to spend significant time working on a business plan and associated funding applications or investment rounds. It’s a much easier task to take on if you have the available resources and expect to use them.

Image courtesy of Adrian Serghie.