When projects go wrong

Photos: Marcus Aurelius and Pixabay, on Pexels

This webpage is for trust fundraisers with three or more years’ experience. Beginners should use this page instead.

Being able to deal with your problems on projects is very important for the long term success of the charity.
Good grant management to avoid problems is key.
Be positive where you can (people overlook that) but be honest and upfront where you need to.
What you say to the funder is the focus of the video that follows. However, it’s often the LAST thing, after a lot of problem solving and work with Services to sort things out properly.
The basic principles are:
- If it’s not actually your fault, make that clear. There’s plenty that’s outside your control. There are reasonable reasons for things to go wrong
- You take the donor’s needs seriously
- You’re a hugely skilled, knowledgeable and committed charity and this came into play when sorting things out
- You learnt everything you can
Money’s rarely clawed back, but I’d do in-depth research with the trust when there’s a real risk
If changes are needed, if you can stay within the original aims of the project you’ll probably be on safer ground

Grants officer Edgar Villanueva raises, ‘The risk of talking honestly about what’s going well and what isn’t, which is of losing funding.’ At the same time, we have obligations under the Fundraising Code of Practice and common decency to not deceive our grants officers. The following video gives ideas about how to do whatever you can to preserve things – and even to use the problem to actually strengthen the relationship.

This video is very focused on the narrow issue of what to do with the funder. However, the big picture is that you’ll often need to have worked very hard on problem solving (a sub-menu on the Trusts Team menu) and to have worked with Services to sort things out (the Work with Services sub-menu on the Internal menu). What you say to the funder often mainly comes after all that work has been completed.

Why diagrams focused on dependencies

Since doing that video, I’ve identified another useful little tool to crack open the issue of explaining why it’s not your fault, if it isn’t. You can do a Why Diagram (described in the Problem Solving video, or online) focusing on the project’s dependencies.

To take a recent example: we had a project that we’d delivered very well in part and spent all the donor’s money on, but we hadn’t delivered some other work that was in the overall project description and wanted to explain that to the funder. The un-delivered work was some early intervention casework.

So, to break down the causes (secondary causes are further to the right, primary ones further left):

Ability to deliver casework

Needing to work with hospital staff

- - Everyone is rushing around in hospital due to COVID and can’t deliver “extras” like this.
  - Staff will be unable to help for a very long time, due to backlog

Understanding the situation

- - As a very new, highly innovative project introducing concepts from Australia, we have learnt that some of our assumptions weren’t right, despite all initial research we had done
  - However, there isn’t enough to hang on this – probably don’t reference

COVID

- - COVID had made the work much more time consuming and expensive, leaving no money left to deliver the casework
  - COVID is still affecting our sector and the casework would be difficult to do even if hospital staff were more amenable

Resources within the charity

- - In the two years since the project started, the NHS identified a massive new problem in our sector, which we’ve refocused our efforts on. That means that, having spent the grant, we can’t bring in the extra resources needed

Money for the work

- The funder was the only one to put money into this (innovative and previously little explored) area for us. As we’re reliant in their grant, there’s no other funding in place.

Clearly some of these arguments are neater things to say than others. If we kept digging, there’s probably more again that we could have said.