General points on service development

Photo: Rene Bohmer and (inset) You X Ventures, on Unsplash

This area of the site was written for very experienced trust fundraisers.

  • CIRCLES is a very funder-focused approach to development
  • An attached download can help you clarify what does and doesn’t need to be developed, what you should argue for and against including, and your priorities/timings
  • MoSCoW prioritisation may help senior staff to give you a better broad outline of the project
  • You want clear roles for project development
  • Impact mapping may help you structure the development discussion with the Services manager
  • RICE is one way to choose between options, if the Services manager needs help to do so
  • When thinking about keeping stakeholders onside, Mayfield’s seven principles may help
  • If there’s a three-year strategy for the charity coming down the line: beware! This can be a challenge. I offer a few ideas.

Judgement calls on values and time spent

An interesting quirk of behavioural economics is that we overstate the importance of proportionality and under-play the role of absolutes. Thought experiment: would you walk an extra few blocks to pay £5 for a £15 pen? Many people would. Would you walk an extra few blocks to pay £190 for a £200 suit? A lot of people will find that less tempting – but actually, it’s exactly the same amount extra that stays in your bank account.

I see that sometimes in myself and others in project development: people settling comfortably for a £250k project rather than a £270k one. However, you can imagine what they’d say if you asked them: would they be comfortable about losing a £20k opportunity? “Of course not.”

There’s an issue of putting a certain number of eggs in the one basket. However, when I specialised in lottery bids one of the main reasons I succeeded was because I did just that, spending longer than you’d think. In that case, it was because people arguably misjudged the values the other way. It’s easy to justify spending three or four times as long on a Lottery Stage 1, say. However, if it’s for ten times the amount and you’ve an 80% chance of success as Stage 2, in what sense is ONLY spending three times as long a good, proportionate use of your time? You could argue it’s the best use of time in a political sense, rather than in terms of meeting the needs of your charity.

CIRCLES project development gives a more funder-focused model for the proposal

The funder’s focus is only one issue for project development, but it’s the vital one for you, because your job is to build a bridge between the funder’s needs and Services. This is one way to do it:

Comprehend the services situation: the Who? What? Why? and How? of what Services are thinking of doing. If you don’t, you’ll struggle to get involved in a creative way.

Investigate (i.e., research and understand) the funder

Report on the funder’s needs. This means writing them up – though you might or might not want to keep it to yourself for now.

Cut, by prioritizing which bits of what Services want to do can you actually enable with this funding? Which does the funder’s priorities give you the best chances with? Which of the funder’s interests are you going to ground this work on?

List solutions The aim is to throw out as many ways forward that address the funder’s requirements and enable the work as you can. This will enable you to negotiate effectively with Services and help you to find the best win:win solution between you for the application.

Evaluate trade-offs What are the gains and losses of different choices?

Summarize Feed back your key points internally 

What development you do and don’t need

Bid writing is the art of the possible and involves compromises. You need a project that is as good as you can reasonably get and that meets the thresholds you see to be worth it. That doesn’t mean that absolutely everything needs to be in the project description.

You can agree limited changes with the funder after the money comes in (but not for work that’s outside the aims of the proposal: that might need to go back to the Grants committee, so it’s more of a headache for everyone).

What you need nailed down is enough to: 

  • Reasonably represent the bulk of the project
  • Give you as saleable a project as you can reasonably achieve 
  • Not leave out anything that falls outside the clear aims of the project

So, you need to break down the project into its constituent parts and evaluate (1) where you can reasonably get to with each and (2) what you need and what you can let go of.

This leads you into a dialogue with Services about developing something attractive:

The above matrix is available as a download:

MoSCoW prioritisation by senior staff

This is a way of getting a better project brief at the start of the project development, from the Services senior manager or other senior stakeholders. MoSCoW is about classifying features of the project into:

Must haves – essential to the project’s success and non-negotiable. In the above example, that might include: delivery of advice to visually impiared people about assistive tech

Should haves – crucial tasks. In the above example, these might include: delivery in at least two towns; demonstration of CCTV, JAWS and other common systems for reading text

Could haves – highly desirable tasks that could be left out if there are time or resource constraints. To give an ageist but sadly fairly realistic example: if it was difficult to get into residential care or find enough older people with significant visual impairments prepared to work with the project, it might be that Services decide this could be replaced with other work

Won’t haves – there are always desirable things that the service won’t actually do. In this case, these might include visits to special needs schools, or demonstrating expensive equipment with very minority appeal.

Feedback on the shape of the project doesn’t replace the Service manager’s development work – there’s still a project to be put together. However, it clarifies the constraints.

Clear roles and responsibilities in the development

As project management Ricardo Vargas says, ‘A dog which has two owners sometimes dies of hunger.’ There are two considerations:

  • Within the development of one project/application, a clear delineation is needed, though it might need to change as capacity issues become clear.
  • When you work on something and don’t want to do the same kind of task in future, that should be very clear and there should be a clear reason.

Putting together the basic project

A nice simple approach to this uses “impact mapping”, as a way to talk the work through on paper with Services. It starts with the goals and works back from those to identify the project:

There are videos on how to facilitate this, if you decide to use the tool.

RICE scoring method for choosing between options

Sometimes there are different ways a project can go. You may want to leave Services to make the choice on their own, but if they seem to be bogged down, RICE might be one way to help them do so. It assumes that they’re at the stage of having ballpark targets and a sense of impact – if they don’t, it’s not for you.

You do this calculation for each of the options and see what seems to be the better option. These are likely to be “finger in the air” estimates and so it’s really a way of bringing a little clarity about what are bad options, rather than a way to precisely score anything.

Reach

The number of people reached

Impact

  • 3 = massive impact
  • 2 = high impact
  • 1 = medium impact
  • .5 = low impact
  • .25 = minimal impact

(That’s one of the clever bits!)

 

Confidence

  • 100% = high confidence
  • 80% = medium confidence
  • 50% = low confidence

If it’s below 50%, people would normally reject it. This is a commercial tool, from a world where risk is more tolerated. If it’s 50% confidence, I wonder if as trust fundraisers we should be entertaining this option, if it’s a significant part of the project!

Effort

You could quantify effort in terms of the person months’ work required to do the particular option.

Mayfield’s seven principles of stakeholder engagement

These are worth bearing mind, as you start to put your project together:

  1. You might forget important stakeholders, but they won’t forget you!
  2. Stakeholder analysis is ongoing. For example, their involvement, interests and influence change over time
  3. Stakeholder prioritisation therefore also changes over time
  4. Some stakeholders might be best engaged by others – you don’t have to engage everyone yourself
  5. Seek first to understand, the to be understood
  6. Emotion is more relevant than reason
  7. Demonstration is more relevant than argument

Fit with strategy and other functions

In some charities, there are few things more likely to provoke fear and gloom than the statement, “We’re introducing a new three-year strategy”: they can represent a black hole for project development, sucking in both energy and timing estimates for several months at a time. 

Then, for various reasons, the results are often underwhelming when they do finally appear. Don’t get me started on what’s wrong with many charities’ strategies that I’ve seen over the last 25+ years and 30+ charities I’ve been at!

And yet, our projects absolutely do need to fit the realities of the organisation, including its strategy. The most unsuccessful projects I’ve seen have been the least attached to the realities of the charity. You don’t want to be reporting on an unsuccessful project.

So, you need to steer a careful line, internally: 

  • If you don’t try to disentangle your new projects from wider issues, they may get hopelessly delayed for no really good reason. You may drain them of whatever impetus there was behind their creation and completely ruin the time frame. (For example: I worked at a care charity where the frontline services were in flux through no fault of the organisation and in consequence it was almost impossible to get anything both agreed and to stay agreed. It was very dispiriting and we raised a lot less than we otherwise would have.)
  • On the other hand, if you try to sneak things through, then what risks will they face in the future? 

As ever, I think the answer can be to have the best possible understanding of the Services team – where everyone at all levels is trying to go. Then, you can see where there is essential synergy and real risk and where it’s just a case of stupid people thinking things need to be delayed.

Keep good visual records of what’s agreed

David Strauss identifies the importance of a “group memory”, including visuals including good notes of decisions  in How to Make Collaboration Work. He says there are none different problems groups fall into that it can help overcome:

  1. Repetition/”Wheel spinning”. Records of what’s agreed so far mean you can keep building
  2. Lack of a level playing field. Records that record the idea, detached from who said it, empower the idea rather than focusing all the intention on the most powerful individuals
  3. Associating ideas with people (who you might not like). As above
  4. Loss of focus. If the group is gathered around, say, a flipchart that is recording progress, this can provide a visual prompt to keep things focussed
  5. Not getting bogged down when things are hard to put into words. Sometimes diagrams can overcome that
  6. Information overload. A visual structure of “Where we are in agreeing all this” can help focus on what matters at this point / show the wood, not just the trees
  7. Disruption by latecomers. They can read what’s written, rather than the meeting having to stop and explain it to them. They can join in once they’re caught up.
  8.  Vague/misunderstood agreements. It’s right there in front of everyone and vagueness is obvious
  9. Failure of memory (if it’s a long meeting / there’s a gap between meetings)

Checking your collaboration skills

If you think you’ve room for improvement personally on this (either addressing gaps or making the most of your superpowers)  a list of skills to check is:

  1. Listening
  2. Empathy
  3. Giving and receiving feedback
  4. Clear communication
  5. Flexing between being a leader and a follower
  6. Looking for win:win objectives and outcomes

 

You might try ranking them and also getting someone else you collaborate with to rank them.

Service Development methodology

Developing a service for particularly vulnerable, hard to reach or stretched, people? I suggest you read on. The following isn;t something you’ll need to do, but it’s cutting edge and could help…

Note the capitals: Service Development is a term for a particular approach, that works a bit like commercial Product Development: you map user pathways and user experience, keep coming back to goals across the service user journey as you design, doing Minimum Viable Product prototypes that are tested with service users and generally focus on how to ensure the end user gets the best out of what you’re designing.

When I was at Action for Blind People, our advice staff would call people back to check they’d got what they needed, because we were aware that a lot of our service users were vulnerable individuals and could easily fall out of the system. In homelessness, people can get allocated key workers, who support them across a period, because advice on its own doesn’t work well. Something not unrelated happens in youth work. When you advise someone or try and provide a service to them and it doesn’t work out for them, it can leave them further behind.

You can see how designing things in the abstract or funders could exacerbate the tendency of services to do that: if the targets are too high, or things don’t wrap around the end user, people may not get the support they really need. 

For me, this is a place for Service Design thinking. Methodologies in Marc Stikdom’s book Service Design Doing include:

  • Going and seeing the actual experience of the potential service user as regards the situation
  • Mapping user journeys from problem to solution and pathways through the service
  • Focussing on the end goal of the service user at each stage of the process and asking “Is this the best way to achieve the goal?”
  • Creating service prototypes that are tested with service users and iterating to improve the experience
  • Focussing on service user experiences, as well as outcomes. A lot of the quality monitoring we do is along the lines of “What did you think of the service? How could it have been improved?” rather than digging into the actual experience of the user with them and trying to co-create an improved approach

Some of this is better done once you have the grant, but if you’re trying to improve the experience of the end user, you can write it in as a methodology (e.g., a period for testing and refining the model at the beginning). However, you need to be careful that you aren’t creating constraints that stop the service sorting itself out once it’s up and running. For example… Delivery at full speed from early in Year 1 of the project will make it hard to test and refine the model. High targets might squeeze out the time to provide quality work.

If there’s time while putting the project together, some Service Design methodology may both make for a better service and differentiate your application a bit as being expert (though, as it’s exploratory work,there are no guarantees).

Good Services by Loud Downe has some interesting ideas, that seem to apply for groups of vulnerable service users:

  • Be easy to find (which might include a marketing budget, budget for Search Engine Optimization, a service name that is about what the end user wants to achieve and using language that the service user will understand)
  • Enable service users to achieve their outcomes (rather than just get something – e.g., some potentially useful information)
  • Work in a way that’s familiar and intuitive, requiring no prior knowledge
  • Require the minimum possible steps to complete (this can involve delegating authority to the front line, so staff can deliver) and have no dead ends (for example: that they’d have to remember a lot, or they can’t access you at the times of the day that they’d need to) 
  • Quickly respond to change

 You’ll quickly appreciate that, if you can do some of this, there will be selling points about the model of work that you can make in longer applications.