Day-to-day grant management

Photos: Cliff Booth and (insert) Christina Morillo, on Pexels

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

  • It’s helpful to have an induction meeting with Services at the start of any major new relationship. The agenda should include at least:
    • How to deliver anything added into the project for the funder
    • Reporting requirements
    • Monitoring and other things collected for the funder
    • Anything to ensure speedy draw-down of the grant
  • Some charities don’t let fundraising see service user data for monitoring purposes. However, others do, it can help your team and I’ve not so far seen it cause problems. You may, though, want Services to do that analysis. It’s something to consider.
  • This webpage covers lots of considerations around how regularly to meet Services to check how the service is going and ensure the funded work is on track. A list of items to consider (and vary from) in these update meetings is included.
  •  Dealing with changes:
    • The project management 7Rs framework is useful to ensure you’ve covered the necessary issues
    • When changes do come up, a Futures Wheel is a useful tool to help you consider all the implications of a change
  • Changes take time to implement. So, don’t over-commit to the funder if you have indeed decided to go for the change.
  • If anything’s gone seriously wrong, this is covered on other web pages on this site. The key ones are really: the problem solving, internal relationships and “What to say to the funder if anything has gone wrong” pages. However, good internal grant management processes still need to be in place – so, do come back to this page.

Grant inductions

If a project is important and complicated, I always aim to have a grant induction meeting with Services. This is usually with the Services manager, though if the changes involved require understanding across the team, a wider meeting might be needed. (I showed this to Robyn McAllister of Street League, who commented that she usually involved Finance as well, if it was a restricted grant. That sounds like a good idea for some contexts.)

An induction meeting covers: 

  • The work covered by the grant. I’d particularly pick out anything new, the project KPIs and especially anything that was added in for the funder (this is where the problems are most likely to be). It’s probably a while since Services did the work and they have not usually been very involved. So, it’s good to get them properly up to speed
  • What the funder will need by way of monitoring data and anything else that’s unusual for the reports (e.g., an account of equalities and diversity issues; or learning during the year)
  • Who’ll be doing what on the reports; access to monitoring data for Fundraising. 
  • Anything that needs to happen within a certain period to get the grant drawn down quickly
  • Occasionally the project was cobbled together at speed and some more development work is needed. If so, it’s good to be on top of this, as there’s potential for drift as regards the date of drawdown of the grant.
  • I’d reiterate points they should be familiar with: 
    • We treat the proposal as an agreement between Fundraising and Services
    • If changes are needed, the funder may well be open to that, but they need to discuss it with us before making the change so that, if need be, we can run it by the funder

Access to monitoring data

I’ve been at charities where we’ve had full access to all monitoring data, there have been absolutely no problems with this and it’s been convenient for Services. If need be, the Trusts team can be DBS checked. 

You may not want that level of involvement, though. It avoids a log jam sometimes in terms of Services not complying.  However, there can be issues understanding the system / getting clean data, that you may prefer to leave with Services who’re doing it for other purposes.

One advantage with access to the data is that it enables you to slice up the work many different ways, broadening the ways that you can fund the work.

How often to meet internally for grant management?

At my current charity, there are services I meet monthly on behalf of my team to keep on top of all the nuances. (Services where I am just now are very helpful indeed.) At other charities I’ve met quarterly and sometimes you can trust people to leave them until the reporting process, bar the odd quick check-in call. Considerations include:

  • How closely we’re involved in fundraising for the work
  • How far I could trust Services to deliver without speaking to them. Considerations would include:
    • The kinds of risks you thought about when applying: how new/innovative/within their skillset is the work? Is there a reason it might not work?
    • Have we added specific work for the funder? Things which aren’t in Services’ core plans are most likely to slip, but could matter for you
    • What do you know about the Services Team’s willingness to stay within the parameters of the funding? (People usually do, but not everyone.)
    • A project that’s well merged against risks – where risks are clearly identified, monitored and responded to – is more likely to deliver than one that manages issues when they emerged (as research shows)
    • Projects with strong support from senior management are more likely to work than those which have only lukewarm support (as research shows)
  • Working relationship the relevant Services team have with the Trusts team: do they know what to come to you with and will they?]

Regular meetings template

For services we work closely with and where we need to pick up even small changes, I meet them monthly and use the following template:

  • Any important updates – what we should know?
  • Have any obstacles led to lower than expected impacts or numbers?
  • Has anything been cancelled and if so why?
  • Any changes or improvements to the way the service is being run? For example: New service users coming through? Changes to volunteer training or accreditation? Changes to the location? Updates to how bits of the service are delivered? Etc. [If things are fairly static in a services, prompts can help check that nothing significant has actually changed]
  • How are you doing against the budget? [This is mainly to try and pick up under-spend in time to agree extra work before the end of the Project Year.]
  • Any case studies we need.
  • Any recent positive stories, or specific examples of how the service has helped someone or quotes that they’ve shared with other teams?
  • Is the Trusts team providing the necessary customer services [This is a nice one to finish on, because it emphasises that we’re trying to offer good customer services to them]:
    • Are we sharing information within the Trusts team, so that different people aren’t asking for the same details? 
    • Have my team reported back to them about the outcomes of any big applications we’re done with them?

Dealing with changes

Trusts (at least, the big ones) are well aware that changes are a normal, natural part of a project. I’m writing this (hopefully) after the worst of the pandemic has finished and at this stage, trusts seem pretty receptive to the reality of projects changing. However some changes can be very substantial, in which case there might be issues over whether the trustees’ grant decision covers it.

If the project is still furthering the same aims and achieving the same outcomes for the same target group, my experience has been that trusts have been okay. However, you could do all of those things and still be making a major change which might make the trust wonder about whether they need to go back to the trustees.

As project management guru Ricardo Vargas highlights, there’s a case to be somewhat resistant to change, to stop the project unravelling. However, it’s usually plenty enough if you highlight that the proposal was an agreement between Fundraising and Services; and that changes potentially need agreement with the trust (who’ll have limits). Services are used to delivering to service specifications, especially if they handle tenders.

Clearly, though, you don’t want to block improvements, changes that definitely need to be made, changes of detail that the trust will be fine with or things that could be argued as within the original specification.

My starting point is always: how will it affect the impacts, as this is the key issue.

A good way to unpack a change is to use the 7 R’s framework from change management theory:

    • Who Raised the change?
    • What Reason is there for the change?
  • Returns: what benefits will it have to the end user? [“Returns” normally refers to profits, I’m substituting]
  • Risks from the change
  • Are there the Resources available to make this change? (How does it affect the bottom line on the work? Have any other teams involved agreed? Etc)
  • Who’ll be Responsible for building, testing and implementing the change?
  • What Relationship does this have with other changes to the work?

If it’s complicated to think through, a nice tool to help you is the “futures wheel”. (It’s referred to as a wheel, because it the future consequences that you’ll plot out will spread out in a circle, from a hub which is the proposed change that’s under consideration.) You can do a futures wheel with the Services manager or on your own to see what this means. The consequences of each change are spelled out, building a bit of a web of issues to look at:

Garfield Weston Foundation is one trust which cares more about project changes, but in the words of Director Philippa Charles: [what turns them off is] ‘Not doing what you said you’d do. Keep us in touch with what’s happening… Report on time when we asked you. Tell us if something has changed. Share with us your learning… Not everything goes to plan, we understand that. What is a bit of a killer is when there is complete silence and we find out things after the fact. Those are the obvious things that would cause us to pause for thought in terms of any future application. [Change] is not uncommon… If something changes we would want to know about it.’

Intervention bias

This is another term coined (I think) by Josh Kaufman for The Personal MBA. The idea is that we’re biased in favour of intervening when things go wrong. In law, this might be how we’ve gone from someone successfully suing McDonalds when they burnt their lip on a cup of coffee to, now, any drink you buy saying on it “Caution: may be hot”. Sometimes it’s actually better not to intervene.

That’s not always a great message for a trust fundraiser. If things go wrong on the project, if you’re like me then you’re emotionally tempted to go back to the funder and say: “This thing happened, so we instigated a full investigation and introduced the following changes at the following different levels…” It makes it sound like you’re a responsive, learning organisation and you probably taken seriously the need to deliver what you said to the funder you’d deliver. However, in the bigger picture, sometimes it’s better not to change things, or not to change too much. So in the real world, there’s a balance to be struck.

One thing that might look like is: when things go wrong, still having a discussion with Services about making changes so there’s something positive to say to the funder, but actively “reality checking” with them that the proposed ideas you come up with together  aren’t onerous and making things worse.

Final thoughts

Changes which are outside the aims of the project will be a lot harder to agree with the funder than changes that further the existing aims of the work.

If the change is major, it’s tempting to try and get the team to deliver a huge amount of the new work so that it impresses the funder more. However, you’re effectively going back to the initial, slow period of the project, where people usually start small and get things right. So, if you promise less to Services, you’re likely to put the service back on a secure footing again.