Comic Relief's Tech for Good programme for charities and social enterprises etc
Article by Joe Roberson, Guest Blogger and Tech for Good consultant at Working with Joe.
So you’ve won some funding for your project?
Ace. Nice work. You’re going to have so much fun building your product…
You’re probably thinking about the social impact you want it to create.
You might even have thought about the user value it should create.
But how much have you [Read more…] about 5 Top Business Models to Help Your Tech for Good Venture Survive Beyond the End of Your Grant
The below videos show how some existing problems can be solved using innovative tech solutions. In the 2017 programme, Comic Relief and Paul Hamlyn Foundation co-funded 10 digital transformation projects, covering a range of issues including homelessness, addiction, disability, and domestic violence. We’re excited to show you what our projects were working on from April – July this year.
To learn more about the individual projects – see our Current Projects page.
We are hoping to run another Tech for Good programme later this year. Please keep an eye on Comic Relief’s Open Initiatives page for updates.
On the 24th July, we marked the end of the second Tech for Good programme with a public wrap-up event at the Impact Hub Westminster near Trafalgar Square. Making the most of the opportunity to have all of the support team, the funders, and the 10 projects in the same room, we split the day into three parts. Firstly, a morning session for the support team, followed by an afternoon workshop with all of the projects, and finally a public showcase in the evening.
The support team along with staff from Comic Relief and Paul Hamlyn Foundation met first to share learning and reflections. We also discussed possible tweaks and improvements if the programme were to run again (we very much hope it will!).
In the afternoon, we held a workshop with all of the Tech for Good projects. This was a chance for everyone to reflect on how they found the programme, what did and didn’t worked for them, and what could have been done differently. Finally, we also discussed what support projects needed in moving on beyond this funding period.
The evening was a reception with an audience of around 100 people, who came to hear the 10 teams talk about their projects, what they’d learnt over the four months (lots!), and what their next steps might be. The teams had 10 minutes each in which to give a short presentation, and take a couple of questions about their work. Audience members were able to submit questions via Twitter – using Slido these were collated (using their hashtag) and displayed as they appeared. Teams then had a couple of minutes to run through some of the questions at the end of their slot.
The presentations were great! Most teams went for PowerPoint slideshows, though Ed from Bristol Braille didn’t use slides at all, instead showing the audience the latest prototype of the Braille e-reader. Harry Harrold from Neon Tribe (working with Alexandra Rose) braved a live demo, which worked seamlessly.
David Kane is a Data Scientist working for Cast and Beehive Giving, who has produced an analysis of applications to the Tech for Good programme, as well as a searchable directory of applications. Please see his introduction to this analysis below.
As part of applying to the Tech for Good funding programme, applicants were informed that their application would be made public even if they were unsuccessful.
This meant that when Comic Relief asked us to analyse the applications to the fund we could expand the scope of analysis beyond just the ten successful applications. Looking at all applications allows us to look at wider trends – such as who is asking for tech for good funding, what do they want to do with it, and what stage of digital development are they at.
The analysis looks at five main questions:
– What types of technology are being developed?
– What approaches are adopted?
– What’s the focus of the application?
– Who are the target audience?
– What stage of development are the projects?
Surprisingly, the first of these was the most difficult to answer. Reflecting the criteria of the fund, the projects were generally at the concept or pilot stage. This meant that applicants had often not yet come to decisions about the technology they would be using – and described the project outputs in more general terms as an “app” or “website”. I believe this should be seen as a positive – a sign that applicants were focusing on the problems they wanted to solve, rather than letting the technology drive the project goals.
You can read more answers to the questions above in the application analysis. The analysis showed that the typical application was from a larger registered charity based in London, but that there was variation beyond that typical picture. The largest focus of applications was on health and wellbeing, and generally applicants were aiming to provide services directly to beneficiaries.
We’ve also created a directory of applications, where you can explore the projects, filtering by their individual characteristics. We’ve made the code for the site available on Github.
Eve from Snook, one of our evaluators, shares her views about the learning from camp.
Applying the agile methodology (see our last blog post here) to their various projects, the Tech For Good teams arrived at valuable insights, new problems and, in some cases, some healthy confusion. In this post, we outline some of the key learnings from the camp.
Most fundamentally, teams used the camp to better visualise their project plans. This was particularly important for teams that would be working remotely and to different schedules, such as WESC’s multidisciplinary team. A Disrupt Disability team member said that the degree of structure he gained through the camp to relay to the wider project team would not have been possible without the exercises. The Shelter team refined what they felt was possible in a four-month timeframe, and built contingency into their plans, as a result of the various planning exercises.
The second key theme in this regard is the identification of new assumptions. This is not surprising, given identifying assumptions is a key tenet of the agile methodology. Some teams struggled to pick assumptions to focus on that they can reasonably close within the 4 months programme.
Team Oxfam saw their core assumption shift: from the assumption that food banks offer little ongoing financial resilience support, to the assumption that services want to build financial-resilience support to the assumption that, given financial resilience is key to food security, food-bank staff should refer users to Quidsin.
Other teams gathered more specific insights, relating to a particular assumption. The Shelter team, for instance, realised they had paid too little attention to testing the assumption that the simple intervention of a digital button would solve the problem. This, in turn, had led to an inability to fully articulate why – or whether – their intervention was needed. Similarly, the Women’s Aid team realised they had not tested the assumption that young women would indeed use their service and the context around it. For their part, one of the assumptions the Alexandra Rose team identified was that their voucher printers could print barcodes. Finally, the Bristol Braille team shifted their focus from the physical design of their Canute e-reader to user need, realising they had failed to test assumptions relating to demand.
This points us to the third grouping of lessons: the need for more user research. Bristol Braille and Oxfam both decided they needed further user research, around user demand and user experience before using the QuidsIn card, respectively. The Shelter team went one step further and decided they needed a UX designer and user researcher.
The fourth key theme in terms of what the teams learned during the camp was a clearer sense of the key problems and potential obstacles they faced. This arose largely from the journey mapping exercise. The WESC team, for example, identified problems around data permissions as a critical juncture – one with the potential to hinder further checkpoints. Similarly, they identified a key collaborator who had the potential to become a bottleneck.
The teams learned all manner of other lessons – some pronounced, some subtle. The aim of this blogpost has been to outline the key themes and to note the way they followed from the tenets of the agile methodology, outlined in the previous blogpost, that ran throughout the camp.
An essential, early part of Comic Relief and Paul Hamlyn Foundation’s Tech For Good programme is a two-day bootcamp at which all the 10 projects and the support team gather in one place to meet one another, learn and plan. This year, the event was held in Manchester and facilitated by James Boardwell, Emily Webber and Dan Sutch. This blog post gives an overview of what we got up to.
It goes without saying that a key dimension to the camp is the opportunity for the different project teams to meet, swap stories and generally collaborate throughout the sessions. Working as a team is, of course, valuable but working between teams allows people to temporarily break free of any habitual ways of working and thinking – to freshen things up.
The focus of the Bootcamp included:
An introduction Camp session focused on the agile working methodology. This is one of the primary methodologies preferred by startups all over the world. Its central aim is the ability to work, learn and, if necessary, pivot fast as a team. The focus is on refusing to waste valuable time and resources moving in the wrong direction when the team could instead “fail fast” by testing as early as possible. The teams brought with them various degrees of familiarity with agile working. It was pleasing that throughout the session, people from across the teams contributed their experiences and inputs in helping elucidate and explore agile working in different ways.
A key aspect of agile working is the rapid testing of assumptions and quick iteration based on the results. Identifying core assumptions, to then be tested, was, therefore, the next exercise. Central to identifying core assumptions is the word “why”. Techniques such as the Five Whys – asking “Why?” five times in a row to delve deeper into an answer to a given question – might seem faintly ridiculous, but are invaluable in forcing teams to demonstrate to themselves that they truly understand the reasoning behind their work. Each team was asked to identify one core assumption, and to work out how they could test that assumption as quickly as possible to permit them to continue their projects in confidence. In reality, of course, all of the teams identified more than one assumption to be tested. But beyond the fact that the exercise was designed to be replicated beyond the camp, it also makes sense to begin with the most fundamental assumption – that which most influences the others.
One result of identifying assumptions is identifying the need to test. For this, prototyping is often required. Indeed, a key tenet of the agile methodology is the ability to prototype quickly and effectively, even if crudely. Teams, therefore, spent time working out how they could prototype tests to some of the key assumptions. Many of the teams had experience with quick prototyping and knew the value of seemingly low-tech methods, such as paper designs used to replicate app UX layouts.
Another consequence of delving into assumptions is the necessity to think from a user perspective. Asking why repeatedly – and identifying assumptions more generally – often illuminates the presumption that a person or group of people or users will behave in a certain way. However, to determine this in a reliable way, user research is required. This, in turn, encourages user-centred design – not design based on the untested assumptions of the designer. These were key themes that ran throughout the camp: teams were repeatedly encouraged to approach their assumptions and design from a user perspective. More fundamentally, this meant that teams were encouraged to view the digital tools they are producing as services – not just as back-end efficiency gains.
An essential exercise was journey-mapping. Teams spent a healthy amount of time mapping both their own journey as a team designing a product and the journeys of their users in using the product. This holds a number of benefits. First and foremost, it helps generate a clear map of the project. This, in turn, helps identify problem points: it helps identify bottlenecks, linkages and collaborators who might become “blockers”. Therefore, it helps to identify key tasks and questions around how to negotiate potential obstacles.
The camp was not all spent putting the teams through their paces. It also featured presentations from previous Comic Relief Tech For Good projects. Umesh Pandya, of Wayfindr, gave an incredibly slick presentation of their work to serve as inspiration, motivation and best practice. He also stayed to take questions from team members on both the programme and social innovation more widely.
Finally, of course, everybody got to hang out. It’s amazing to gather people not only with similar priorities and passions but people at the similar points of exciting projects. Between and after sessions, people could be found discussing ideas and plans enthusiastically and fruitfully, setting the tone for the next four months.
