Extra Grant Application steps for Digital Funding Success

Getting funds for most digital purchases isn’t easy. That said, applications for equipment can be relatively straight forward. For example, you have a good chance of funding a replacement for that old laptop if you describe the operational need, attach three quotes and apply to a suitable funder.

Obtaining funding for new digital systems is harder. It is not easy to compare apples with apples when your three quotes are for different software. Worse still, when you’ve never used a certain type of technology before, it is generally impossible to accurately predict what impact it will have. Many, many organisations have an “over promised and under delivered” system. Funders are well aware of this and have become wary of applications for technology. Consequently, as well as all the good grant application practice you usually follow, there are extra steps needed to maximise your chance of success.

Apply to make a tangible improvement

Always remember that a digital project isn’t really about software or equipment. It is about processes for data exchange and communication between people to make an intervention. Your application should be capable of being summarised something like this

 “we want funds to make this (specified operational change), which will be benefit (these stakeholders) because it (solves a specific problem or improves a specific outcome) and part of the solution is this (specified technology) which involves this (development and deployment) work.”

In other words – never focus on the technology.

Your summary will help you identify the right funding sources.  Many “innovation” funds are actually quite specific. For example, the NetsafeNZ Online Safety Grant only funds projects that will help to reduce or lessen harm caused by harmful digital communications. On the other hand, an outcomes focussed project that just happens to use technology will fit the criteria of many funders who do not focus digital innovation.

Pick the type of funding

Obviously, your application will need to be a good fit with a fund’s eligibility criteria. In addition, you’ll need to be careful about what will be capital expenditure and what will be operational. Historically new computer systems were capital items and depreciated. In these days of online subscription software this may not be the case.

Online, subscription-based software can be capitalised if you need to customise it. That is if you commission code to be written just for your organisation. Good examples of this can be your website or a CRM like Salesforce and Microsoft Dynamics. Configuration – where you only change internal parameters or install a vendor templates – generally needs to be expensed. Confusingly, a website or CRM could also fit this description.  Take advice from your accountants on how your project costs will be treated by the IRD before making applications.

Provide proof the technology will work for your purpose

Your application will stand a much better chance of success if you show the funder that you’ve

  1. worked out what you are going to do;
  2. evaluated options and then made a suitable selection; and
  3. Proved the proposed solution will make the difference you say it will.

How you do this depends on how big a change you expect to make.

Don’t eat the elephant in one go

The bigger the change you want to make, the less likely it is that you can “design your end point and work backwards” to develop a budget and project plan. This is especially true when you want to do something that hasn’t been done before.  This is the reason people talk about Agile system development.  

Digital Development processes compared

The agile process uses lots of short development cycles not one long one. It reduces the chances of ending up with something that doesn’t work as intended. But it also makes it impossible to know in advance exactly what system you’ll end up with. You can see why a project with no “clearly defined deliverable” will make funders nervous about digital applications.

In reality “big ideas” will progress in stages (that’s a bit agile in itself!) and by applying for funding in stages it is easier to bring your funder along with you. The Vodafone New Zealand Foundation’s Innovation fund is structured to do this, and identifies three stages of development

  • Seed funding ($1,000 to $10,000 per application) aims to support early stage ideas and concepts. Objective – gathering evidence of need and what addresses it. Might not build any technology
  • Pilot funding ($10,000 – $50,000 per application) is designed to turn developed seed ideas into practice. Objective – building prototype technology and/or testing the in the real world.
  • Scale funding ($50,000 – $200,000 per application) is for increasing the scale of proven projects/programmes, Objective – a fully rolled out programme.

Try before you buy?

It is rare that anyone develops software from scratch. There are lots of amazing systems out there that you can get on a monthly subscription of a few hundred dollars that would have cost half a million only a few years ago. But they are not as easy to set- up as it sounds on the introductory video.

Let’s say you want an engagement system. Something that will make communication with volunteers, clients and other supporters easier and record your interactions automatically. (If you pick the right one it will also help with fundraising – but you’re not likely to get a grant for a fundraising system so I suggest adding that functionality at a later date.)

To set up an “average” charity with an “average” engagement system – say something like the NZ software VegaWorks will take someone who has never used it before between 150 and 200 hours. Possibly longer if this is the first such system you’ve used. That’s where the cost comes in.

Testing the software to see if it is right for you will take between 5 minutes and 50 hours. Essentially you start to set it up and stop if you find it’s not right. The length of time varies with data complexity, data volume and the number of integrations with other software that you want to test. And you do want to test integrations because they vary greatly in quality.

  1. Use the free trail that most software offers. Just don’t start until you are ready to devote time to it. The average free trial period is 14 to 30 days; calendar days not working days that is. And time flies when you’re busy doing other things.
  2. Compare a couple of options – that could mean three trials. See which produces the optimum process improvements.
  3. More complex options that use more than one technology will need prototyping to work out the operating processes that work with the digital tech. Prototyping is a subject for another day but it is probably a project in its own right.

Build on obvious changes in social behaviours

This is where innovation is often hiding for non-profits; a new approach to an old issue. Moving your online support service from a website to a mobile phone app is sensible when you look at statistics on mobile phone use. Such a move also brings new functions that could be used to improve your service.  You do of course need to take a proactive approach to data disclosure, consent and privacy issues; but using social media or GPS location data from the phone, might offer new possibilities for support.


Include funding for the extra people you’ll need

Very few projects build software from scratch. Most will need more resources for process development and data structuring than for writing code. It is essential to involve people who understand the intention of the new system and the operational environment it needs to support.  These are your staff and volunteers; NOT the software suppliers’ team.  And I am guessing that your people are already busy?

In my experience, the biggest reason a new system fails is that not enough time, internal expertise and energy was spent establishing it. You need all of them; two out of three won’t go so well.  That means that in most non-profits that employ ful- time staff, you simply MUST reduce someone’s workload to ensure a successful development. And/or bring in extra people to cover those working on the project. How much time that is varies but remember that 150 hours estimate? Remember as well that the practice expert who helps the technical team design your new system won’t have time for anything elseduring the development stage. And they will only have 50% or their time available for “business as usual” during system testing.

Then there are the resources you need only for those one-off tasks in the project. Once again what you’ll need varies. Consider this checklist of what you might need to resource;

  • Best practice also involves your clients/members/supporters in the design of new systems that they will interact with. You’ll need to manage this interaction so include both communication and housekeeping costs for things like focus groups, surveys of expenses while testing things for you.
  • Data analysts to help get the data structure right. They also help with data cleaning and transfers
  • Business analysts to understand current processes and optimise the new ones
  • A project manager. This should not be someone from the software vendor to avoid conflicts of interest. Ideally it shouldn’t be the manager who will own the finished system either. They will have conflicts between business as usual and the project.
  • Trainers to support staff. A half day training course is unlikely to be enough to change years of workplace habits so consider ongoing support for a few months.
  • Internal communications
  • Policy development to ensure legal and mission compliance. This might need to be for staff, for clients, members and supporters or even the public. Check legal disclaimers, disclosure statements, privacy provisions and Health & Safety.

A final thought on volunteers

The general rule of thumb is that essential tasks should be filled by staff members if you can afford to employ them. That keeps the skills and knowledge you gain in your digital projects in-house. But sometimes it makes sense to use a volunteer to carry out some of the one-off project tasks.  And Tier 4 or equivalent non-profits may have no other option but to use a volunteer.

Take care when you recruit such volunteers and always minimise the risks. Follow the best practice frameworks from VolunteeringNZ, the Department of Employment or business.govt.nz

Make sure you have clear task and role descriptions and use these to recruit a volunteer who is already an expert in whatever you need them for. Take a look at  HelpTank, an online service that connects skilled volunteers to community groups in NZ. It has lots of good examples of defined, specialist volunteer roles for professionals.

That’s all?

That is all the big ticket items – but there will probably be a lot of detail to work through. Policy development in particular can lead you in all sorts of directions. For example if you have the ability to GPS track staff you have a lot of privacy, confidentiality and employment relations aspects to work through. And these issues can sneak up on you – for example, if you ask them to load an app on their personal phone…

Which is why you can’t rush into a grant application to fund digital projects. A proposal or quote from a vendor will not be sufficient – you need to have worked through all the extras. So, my final piece of advice is this. Get the application in early so you have time to work with the grant advisor and make any changes before the deadline.

And best of luck!