SIMLab

Goodbye for now.

Sun, 31 Dec 2017 00:00:00 +0000

In late December 2017, the Board, with me recused, agreed unanimously to cease operations effective the end of the month. As I wrote in my announcement post, and in follow-up ‘What Happened’ pieces here and here, it’s incredibly sad to be losing our team, our ethos, and the good we could have done - but there’s so much to look back on.

We’re behind on staff salaries, and some bills. If you liked what we did, or ever used our resources, please donate to help us close as gracefully as possible. Hire our team! And help the team build the first digital prototype of a new way to break down the barriers to effective ICT4D: BetterBox.tech.

If you haven’t already, check out our blog, our resources, and our history and principles.

Thanks again, everyone, for everything.

To celebrations to come.

Laura

What happened, part II: five operational lessons learned for nonprofit CEOs

Tue, 19 Dec 2017 08:59:00 +0000

This is the second of two posts about the causes of SIMLab’s closure (part I is here). This post focuses on the more operational issues, and offers 5 unsolicited tips for non-profit CEOs everywhere - particularly introverted, detail-oriented ones.

Know thyself: a table of personality types based on the Myers Briggs test

1. Hire the skills you don’t have, and delegate even where you’re strong.

As the leader of a small organization, you always need to be executing on three fronts, in addition to actually carrying out the core business: honing and maintaining your strategic vision; selling your core ‘thing’; and running a tight ship operationally. It’s critical to know yourself well enough to know which of those things you suck at, and find people to do those things for you.

I remember congratulating myself, in conversation with my husband one day, on the diversity of our team, and looking at Sean to see his mouth hanging open. ‘What are you talking about?’ he said. ‘Every single one of you is introverted!’

Yes, and I’m English. I come from a totally different business development environment. Looking back, I should have found a Washington insider to do that bit. But also, if your skill is in shaping projects, writing things and having ideas, then spend what time you can carve out of CEO-ing there and get someone else in for the rest.

But even for the things you’re good at, try and make enough money as soon as you can to ensure that you can remove yourself from direct responsibility for the day to day on almost all of it. Your job should be strategic vision first and foremost, and being a good figurehead and troubleshooter for the rest. A thoughtful and perceptive proof-reader of this post points out: most of the role is knowing when to hold money and when to invest it, and the details are where you build the team. This reminds me of this excellent piece. And I am not good at that. I’m a details person, and when I struggled in the early months and years to set out a focussed, clear vision, I could distract myself from it with administration and project delivery.

In particular, find a good COO as soon as you can. It has taken me most of my time at SIMLab (including the FrontlineSMS years) to find Kat, who aside from being one of the best humans there is, is the first COO we’ve ever had who could genuinely relieve me of the administrative burden of being the only one who understood our complex financial and legal structure. Being CEO means having to do everything that no-one else wants to do, and this means either handling admin yourself or managing the outsourcing of it. Whichever you choose, make it someone else’s job, and invest in their seniority and decision-making capacity.

2. Keep it simple.

SIMLab began in 2014 as a refreshed brand for a 501(c)(3) that had already been open for seven years, trying to do a very hard thing: run an open-source software platform. We had significant administrative complexity. Due to a combination of circumstance, error, and excitement, we had set up far too many companies, in three different countries. Don’t do this. Keep everything as lean and simple as you can, in the least complicated organizational form you can, in the fewest countries you can. If you have to operate elsewhere, work through partners or (genuine) consultancies.

3. Fundraise for reserves, don’t undersell yourself and charge late fees.

Grant administration finalizes late. Clients pay late. Projects get delayed. In this economic environment, you have to have some buffer against cashflow hiccups. Make it your mission, no matter how hard it is, to have a few months’ run rate in the bank. If you don’t have this, you are not safe, because you never know when the unthinkable might happen. Prioritize this and get your Board on it too - this is their job as much as yours. Use this target to motivate their giving and getting funds and connections.

And value your work from the beginning. If you have to give discounts to early clients, give them, record them, and write them off as you can. (Also: get a good accountant.)

4. Set your risk thresholds and do not deviate from them, whatever happens.

I did not do this, and we are in a hole as a result.

My suggestion (which I would also say applies beautifully, for those without strong convictions, to the question of whether or not to get an epidural during childbirth): in a world that went the way we want we would stay open, against the odds, and prevail against a universe that does not want your organization to exist. But. In the world in which we live, a number of things can go wrong, sometimes more than one at once. Too many to handle is simply too many to handle.

Make a list. It might go something like:

Our income generation model isn’t performing as expected
A tough funding environment
We’re in debt
We have a less than ideal balance of restricted to unrestricted funds
We don’t have enough diversity among our donor base

etc etc - your challenges might be different. Each one of those is a nail in the coffin of your sustainability. How many can you handle at once? Set a number, say ‘4’. Your risk tolerance might be higher or lower than that. Then take one off because you’re emotionally attached to your business and you are not rational. Then take another one off for your family - see below.

Write that list down with your chosen number underneath it, sign the paper and don’t lose it. Look at it often. When you hit your number, you’ve reached your threshold. Make plans to close or do something radical - but before you contemplate an outrageous pivot or ambitious fundraising plan, read the bit about families, below.

5. Trust no-one.

This is about all I will say about the piece of very bad luck that was the final straw for us, but one more piece of advice: don’t do any work whatsoever under any circumstances, no matter how big or small the project, without a document and a signature setting out exactly when and how you will get paid. If your arrangement with a prime deviates from the grant agreement with the funder, get it in writing.

Dropping some truth at FailFest DC 2017. Photo credit: Chris Neu

A final word on our families.

Since the news broke I’ve spoken to many of you who are founders and CEOs in the same tough spot, or might be soon. I’m here for you and if you want a chat, get in touch.

One of the things I failed to appreciate fully until this moment in my professional life, is how tough entrepreneurship is on your family. Many of us have tough jobs to which we are wholly committed, and I’ve worked hard all my life, regardless of my employer. But there is something about your own business that makes you pour your heart and soul into it, and keep very little back. You work long hours and weekends, yes, but you worry even when you’re not working. When someone asks you how you are, the answer is in two parts, and the first part is about how the business is going, not about your dog or your house or your partner and kids. If you’re a good boss in a small team, and you’re responsible for their salaries, your team are part of your family, so you worry about them too. You can’t ever admit fear or failure or project anything other than buoyant joy and success, for fear that your clients and donors will realize you’re fallible and the money will disappear. Your emotional reserves are low. You don’t have much to spare for your partner, who starts to feel they can’t worry aloud or complain about their job. You never take a long vacation, partly because you can never afford it. And so on.

This is the slow attrition of being in crisis mode, all the time, for years. This is small business ownership when you’re new at it and bad at it and the deck is stacked against you. And if you’re like me, right now you’re so triggered by the idea of shutting down that your mind immediately rejects the idea and starts coming up with crazy strategies to avoid it. You can’t even hear me right now when I say: please don’t wait until things are untenable to consider whether they are sustainable.

I said in the last post that I did all that I could to keep SIMLab going, and the truth is that while I did, I should not have. I should have stopped, when I reached my chosen risk number, or when it became clear that, whatever happened, crisis mode would not end for a long time. There comes a time when that is just, in itself, not ok.

So what’s next?

SIMLab is closing in early 2018. We’re behind on staff salaries, and some bills. If you liked what we did, or ever used our resources, please donate to help us close as gracefully as possible. Hire our team! And keep working with us until we close - we’re still consulting! Get in touch and find out how we can help make technology part of what you do.

And there’s more! You can help us build the first digital prototype of a new way to break down the barriers to effective ICT4D. Go to BetterBox.tech and leave us your email, answer one question and get a free PDF resource outlining the three main strategies for disseminating content on basic phones! And we’ll be back in January with a crowdfunder to make BetterBox.

Thank you for reading. Check out part I of this post here.

What happened, part I: strategy fails

Wed, 13 Dec 2017 08:59:00 +0000

In September, we announced that SIMLab would be closing, some time in the Spring. So many people reached out to ask to connect with our fine people about possible jobs, talk about working together, and offer their sympathy and support. To all of you, and those who tweeted, emailed and messaged us, thank you.

To those who donated to support us and help us pay our bills, thank you, from the bottom of our hearts. Most of you are former staff members, some former clients and partners and one, amazing board member. For the whole team, but particularly for Kat and I, who are here until we turn out the lights, the way our community has shown up for us is helping to get us through a tough time.

Quite a few of those who emailed me were curious - other CEOs suffering the slings and arrows of life as a non-profit, anxious to hear which of them were fatal to our little enterprise; people working at the same intersection of practice and policy within institutions, fighting the same battles for funding; and even donors, interested to find out what had happened. I promised to tell you what happened. Last week, I presented a very short version of this post at DC’s Fail Festival. Here is the extended radio edit, in two parts (part II is here.).

Presenting at FailFest DC 2017 about SIMLab’s closure. Photo credit: Chris Neu

I did everything I could, but not everything I might have.

It’s important to say, up front: as our CEO, I bear most of the responsibility for our closure.

I took risks, and they didn’t pay off. I made operational mistakes, and they cost me time and energy to recover. I didn’t know enough about how to fundraise and build donor relationships, particularly in the unfamiliar DC market. I am too eager to do the detailed work myself when I should work at a higher level. We were also unlucky. But the job of a CEO is to identify, plan for and build buffers against unexpected challenges, and I didn’t do that well enough. I’ve learned a lot from this. More in next week’s post, which is more operational in nature.

But. Here I want to focus on what was, perhaps, our biggest problem, and one I’m still grappling with: our strategy, messaging, and business model.

Our mission worked…

SIMLab’s mission was to help others use inclusive technology (accessible, affordable, locally-relevant tech) for social change work. We championed tech that excluded as few people as possible, and project design that went back and swept up those the technology missed. We deliberately avoided technocratic, easy solutions that would reach the burgeoning technology middle class - new entrants to the smartphone market, basic phone power users, people who had been trained and given hardware by NGOs.

To do this, we would help people to implement inclusive technology well, learn from that and share guides, tools and case studies publicly and as accessibly as possible. We would share and talk about what we learned and use that data and credibility try to influence policy and wider practice.

So far, so good - and in fact, we did all of these things. But our fundraising plan was not strong enough, for a number of reasons.

…but our fundraising plan did not

The plan was simple: consulting and partnership proposal writing would fund the implementation work. On the margins of that, we would begin the guides, tools and other knowledge products. They would be released, to fantastic acclaim, and donors would send emails containing restrained praise and invitations to discuss. These would turn, inevitably, into funding for the knowledge products, which would support more work, and our policy and advocacy ambitions. Over time, some of those relationships would evolve into funding for our core mission - the holy grail for any non-profit.

I was making two faulty assumptions here: one, that credibility would lead magically to business. I imagined that like other groups I admired, we’d just have to visibly know our stuff and people would beat a path to our door. I had no idea how hard other groups like ours are having to hustle; how much leader profiles and networks are leveraged to bring in money; the institutional work they have to take on to keep passion projects going; the compromises and the endless chasing after grants. No-one funded our learning products. No-one wants to pay people to think.

And two: that the people who read and liked resources like the Frameworks would be able to use them in their work. I thought all we had to do was point out, helpfully, which way lead to a better world and everyone would excitedly start commissioning evaluations and context analysis missions, and investing in research phases in tech projects. The world does not work that way. It is possible to know that there are gaps in practice in your organization and not prioritize fixing them over the many, many other things there are to do. And many, many people know that these practice problems exist, and are prevented from fixing them by systemic challenges like the chronic underfunding of NGO infrastructure.

An abandoned desk. Photo credit: Max Pixel http://maxpixel.freegreatpicture.com/Hall-Desk-Pforphoto-Lost-Places-Columnar-Office-2963769

One more problem, maybe two: we were challenging ICT4D fundraising orthodoxy. The kind of ICT4D I was proposing wasn’t sexy or exponentially scalable. It was updated 1980s participatory development - not very ‘innovative’, although it made development nerds who know who Robert Chambers is very happy. It included many focus group discussions and granular focus on context. it required design phases and adaptive management. This made it expensive and uncertain to donors. Our focus on inclusive tech already positioned us to work in the toughest tech environments, using distinctly unsexy innovations like radio and, yes, text messaging. Not exactly the easiest thing to fundraise for. And our emphasis on evidence could ultimately uncover massive failings in projects backed and carried out by powerful people with vested interests in not identifying that this stuff wasn’t working. So our mission was not only unfashionable, but potentially threatening.

There were other things that may have contributed to our fundraising fails. Our messaging was confusing. No-one could describe what we actually did in fewer than three paragraphs - not even us. Our service offering was incredibly broad, partly because we were good at applying what we knew to a lot of things - but it made it hard for potential clients and partners to know before they spoke to us what they might be able to hire us to do. Also, our commitment to working across sectors meant that we were trying to sell to every market, and couldn’t focus deeply on one technical area (like, for example, humanitarian aid). And my gender and relative youth may well have played a role. One for another post perhaps.

And then, of course, Brexit, Trump and the world gone mad. The bottom dropped out of the only piece of our business model that was working: the implementation and consulting. All at once, proposals just stopped getting funded, including those written in partnership with big aid and development organizations. The budgets available for design work like SIMLab’s are now incredibly small, and there is certainly very limited core and direct funding for ‘helper’ organizations who do not implement directly. I was not successful in raising any.

Confused message + no market focus + no real business model + bad luck = dead.

What would I do differently?

So, so many things. I am posting some of the more mundane ones separately, in next week’s post. But honestly, in this area, I’m not sure.

We could have identified a core proposition - a secret sauce, magic methodology, or, of course, a tech platform that took what we knew and productized it in a way that made it easy to understand and apply, across our very very broad market. This could still build up to achieving our mission, over time - but it’s a very neat bit of packaging.

We could have focussed on one sector, like humanitarian aid, and invested all of our business development and visibility in being the go-to team in that area. From a position of strength, we could still have expanded to other sectors, with a track record and more organizational robustness.

Painfully, I received both of the above pieces of advice many times, and resisted them. I am not enough of a business brain to get my mission done behind a flagship services product. The mission in our founding documents was to lower barriers to social change through technology, and I wanted to tackle all of them. And we also never really made enough money to say ‘no thank you’ when opportunity came calling. From start to finish we had clients in fields as diverse as humanitarian aid, land rights, legal services in the US, agriculture, water, and education.

I definitely should have done more to develop and nurture relationships with donors; spent more time out and about meeting people at conferences and happy hours; written and published more. A warning to detail-oriented and introverted CEOs, here, who get happily stuck in the mud of project implementation and administrative issues. These were things I knew I had to change and, I guess, couldn’t change enough. I could have invested in team and maybe board members who could have compensated for my skills gaps and personality in business, fundraising and messaging. I could never afford to do this on a staff basis, but perhaps I could have recruited a co-founder.

Let’s all go to our happy place.

And so, fin.

We’re closing inelegantly. Our team are out of jobs, owed back pay, and didn’t get to finish what they were working on. That’s my fault. That is the thing I can’t get past.

Throughout my time at FrontlineSMS and SIMLab, the team have always been the thing I get most emotional about. I had a slide for FrontlineSMS talks, a picture of the team in the Nairobi office on the day we launched version 2, and I had to speak facing away from the screen while it was up, or I would cry.

Fortunately, I don’t have a picture of the SIMLab team.

They kept coming to work, for months, even when they knew I couldn’t pay them. Some still send me heart emojis when they see pictures of my daughter and keep me up to date on their own nieces. All of them worked bloody hard and did an excellent job. And I miss them.

So I still have work to do. For two reasons:

My team still haven’t got paid for some of the work they did. If you haven’t yet donated, and would like to, the link is here. We’re still consulting. Get in touch if you want to talk.
SIMLab’s mission is still valid. There are still barriers to using tech for social change work, and we still need tools and I haven’t solved the problem we set out to tackle. And I want to have one last crack at it.

In January we’re launching a crowdfunder for our last and biggest idea yet: I’m going to widgetize SIMLab’s knowledge. If the world won’t read our weighty Frameworks, we’ll make something fun and beautiful that the world will love.

It’s called BetterBox, and it’s about you.

Post-its on a table

The people still reading this post are the reason our troubled little sector will be ok. It was you we were writing for. All the Frameworks and tools were for people who work in imperfect systems and institutions, doing hard things in challenging contexts. I want to make something that will help you beat down those barriers and make ICT4D better from the ground up. And I want you to help.

In January, we’ll launch our crowdfunder for BetterBox. It creates a way for everyone to use technology ethically and powerfully, in one, gorgeous little box. It contains a deck of cards, each with exercises, workshop techniques, research methods and tips for facilitators to help you understand your audience and use evidence in your work. It will be printable, translatable, and licensed under Creative Commons.

Help us build the first digital prototype. Go to BetterBox.tech and leave us your email, answer one question and get a free PDF resource outlining the three main strategies for disseminating content on basic phones! And we’ll be back in January with BetterBox.

Thank you for reading. Check out part II here.

Three things your COO should do this week after the Red Rose hack

Wed, 29 Nov 2017 00:00:00 +0000

Send this blog post to your COO, right now: responsible data just became a C-Suite issue.

Actually, it has been for a while, but reporting in IRIN and Devex this week on a critical vulnerability in an aid distribution platform - discovered by a competitor in a distinctly grey-hat bit of hacking - should bring the issue to the top of senior management agendas as a potentially existential threat with operational, legal, ethical, and financial implications.

As our recent research showed, the non-profit sector is woefully under-resourced to adequately manage the digital tools it is hurrying to embrace. Lack of digital literacy among senior staff, technological and legal complexity, and lack of capacity to roll out yet another set of standards and compliance mean that the kinds of breaches that CRS faced in its Red Rose deployment are virtually inevitable.

It’s worth acknowledging that there is no evidence of harm to the affected population here - the hacker, a competitor of Red Rose, deleted all the data he was able to download, and the loophole, caused by a default password that hadn’t been changed, was closed. But the Harvard Humanitarian Initiative sets out three potential types of direct harm to beneficiaries from the use of data in humanitarian response. As an example from practice, a recent article by Zara Rahman of the Engine Room points to the enormous risk of direct harm to Rohingya posed by digital ID projects on the Bangladesh/Myanmar border. These kinds of projects do not, in SIMLab’s view, pass the Do No Harm test. Improved threat modeling at the project design stage is a critical requirement of ethical practice and would require mitigation strategies for both poor implementation and design faults. Failure to take this step is a failure to take adequate care, invest in competence around digital platforms, and ensure adherence to the law and NGOs’ own ethical and mission-based obligations to the people they are trying to help.

But that post is for another day.

This one, as I mentioned, is for your COO. And what they need to know, and ensure is somewhere near the top of their corporate risk register, is the following:

Failing to handle data responsibly could mean you are breaking the law

As I have argued before, it’s very tough for an organization to know all of the law that might apply to international ICT4D projects. By their nature, you may be operating internationally, using platforms hosted in a third country, funded by or partnering with organizations from yet another, and employing nationals from just about anywhere. There isn’t one clear place in the law to look, as ICT4D could involve the law on communications, digital infrastructure, marketing, health, free speech… and we can’t all afford to retain counsel in every country. And even if we could, multiple jurisdictions being involved means additional complexity which might mean that what you hear from your lawyer is bounded by many, many caveats that mean that in the end, you have to take a deep breath, and guess. An excellent thing for our sector would be some kind of attempt to explain this problem more clearly, with maybe three or four case studies developed by cooperating pro bono counsel from relevant countries. But we haven’t done that yet, and so we are all, collectively, on our own.

Breaking the law means, potentially, fines

Some countries have watchdogs that monitor such things and have the power to levy fines. In the lead up to the EU’s General Data Protection Regulation coming into force in May 2018, most European countries are beefing up their arrangements in this area. The UK, for example is already fining charities for breaches linked to fundraising and although it is promising proportionality, the GDPR itself allows fines of up to EUR 20 million or 4% of the organization’s annual revenue (not profits). These are enormous numbers, with the power to change the trajectory of any large NGO. The implications in countries with weak governance could be even more impactful. In many host countries of ICT4D programs, these types of breaches could be an excellent excuse for closing programs and expelling troublesome international civil society from the country, or simply for raising revenue from big fines.

Even where the law doesn’t come into it, reputational risk can be significant, and expensive

An NGO which has been shown to have caused harm to the people it is supposed to help through this type of breach is vulnerable to the kind of embarrassment that may lose it supporters - and not only individual personal donors, although that might happen - but institutional funding. To take an example from a quite different sphere, the Girl Effect’s Yegna project was shut down overnight by an embattled DFID Minister despite years of excellent evaluations, following a campaign by the UK’s Daily Mail. Many funders are considering importing frameworks such as the Digital Principles to their grantmaking - which means that data responsibility could soon become a condition of your grant.

One or all of these three risks might become real for an NGO caught in this type of event. It’s not beyond the bounds of possibility that an NGO might be terminally damaged by such a combination.

Don’t panic: just start somewhere.

It’s evident in the responses of agencies implicated in Red Rose’s vulnerability that they perceive risk to themselves. Users of the platform have scrambled to ensure that they weren’t affected by similar vulnerabilities, and the provider has issued statements defending their platform’s security.

For senior staff of organizations watching the Red Rose vulnerability play out, some questions to consider: do you know all of the tools and platforms currently in use in your organization? Do your staff understand how to reduce avoidable weak points like outdated usernames and passwords, and are systems in place to support, enforce and create accountability for these steps? Do you have a policy for how to gather, store, manage and dispose of the data you gather? Do you have a plan in place for what happens if something goes wrong?

If not, perhaps this week was the reminder you needed. Here are three things you can do now to make a start.

Know your problem. You need to understand where data is held in your organization, in what platforms, and by whom. Commission someone (internal or external, as long as they can bring both programs and technology expertise to the issue) to do a data audit.
Get these issues on your risk register and in front of your CEO, HR, IT, and Programs heads. You need to table a longer term discussion about how to implement good governance systems for your data and digital investments. How are they chosen, piloted and rolled out? What scrutiny must they pass? Organize a briefing for your next Board and senior management meeting.
Invest in training and awareness-building among any team that might implement or procure this type of technology. Responsible Data practice should be regarded in the same way as good HR practice or robust financial management - a non-negotiable standard that no manager or member of staff should fall below. Start your HR department looking at adding modules to internal training.

You can read more about our findings on the need for infrastructure investment, improved tools and guidance, mapping of the legal issues involved, and resources that work for beginners, in the report, available in machine readable and PDF format here.

Sean McDonald provided thoughtful comment and many links to the writing of this blog post. He recently co-authored an article in the International Review of the Red Cross, summarized here, which handily unpacks some of the risks of humanitarian experimentation in a taxonomy of harms which includes legal and reputational risks (full disclosure: Sean is my husband). You should read it, for an excellent primer on the ethics of experimentation and innovation in humanitarian aid.

The Evidence Agenda: appealing for rationality in tech for social change

Wed, 08 Nov 2017 00:00:00 +0000

We don’t have a culture of evidence-informed action in tech for social change. Instead of being seduced by the lure of the new, we have to start building a body of evidence; professionalizing our action; and focussing on incremental improvement in practice over mindless innovation. Our CEO Laura Walker McDonald charts a way forward.

A ca. 6 months old Winter White Russian Dwarf Hamster (Phodopus sungorus) in a hamster wheel. Doenertier82 at the German language Wikipedia [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons

As a profession, the technology for social change field is at least a decade old. We can and should be working to professionalize, setting standards and improving practice, and developing a body of evidence on which we can all draw.

But get any group of practitioners together and similar stories will emerge:

Challenges in moving from pilots to effectively ‘scaling’ interventions
Duplicating effort, funding and building multiple platforms and tools to perform the same functions
Technology interventions that are disconnected from the context, real needs and capacities in the target environment, the implementing organization’s existing infrastructure and systems, and the wider field’s existing efforts
Conflating the availability of a consumer technology in a market (access), or household-level ownership of a technology (ownership) with meaningful use of the technology (use), leading to exclusion of burdened groups such as women, people with disabilities, and older people from tech-enabled services and accountability mechanisms

These problems persist because technology for social change has a weak culture of evidence and accountability:

No requirement or culture of demonstrating appropriateness or empirical research before technology is implemented in a given project
Few, if any, evaluations of technology projects, and very few published or shared
A culture of reporting by blog post (partly encouraged by frequent funding through pilot, innovation and core funding without the rigor of programmatic funds)
A relatively intimidating technical field reducing the intensity of critique of our proposals and reporting by non-technologist colleagues, including donors, compared to more mainstream areas of work
No industry-standard criteria for monitoring and evaluation (M&E) of technology projects
Scarce funding for M&E of aid, and less for tech-specific enquiry
Lower rates of follow-on or repeated funding for technology to the same organizations or for the same project, in contrast to strong relationships between donors and humanitarian agencies or with particular development issues in particular places

There is evidence that this is starting to change. For example, the Principles for Digital Development propose best practice which could be used as a standard at project level - although at present, implementers are encouraged only to make a corporate commitment to the Principles by adopting them. The growing M&E technology field meets several times a year at MERLTech conferences - although the focus is usually on using technology for M&E, not how to tease out the contribution tech makes to social change.

Requiring evidence-based working in technology-enabled projects would require overcoming cultural, resource, and technical constraints, some of which are summarized in SIMLab’s Monitoring and Evaluation Framework. But sustained investment in changing the way we work could allow:

Improved project-market fit, with appropriate technology being utilised more of the time
Better value for money, as tech-enabled social change projects become less risky propositions
Publication of results meaning that future projects can iterate on past learning, contributing to a global understanding of what works
Systematic sharing of learning allowing collation of knowledge across thematic, geographic, time or other themes through meta-evaluations and other exercises
Increased ownership by target populations through feedback and participatory governance measures
Improving impact.

It is possible to build a culture of evidence in a field previously not known for it. The development of the accountability agenda in humanitarian aid following the catastrophic response to the 1994 Rwandan genocide shows how a culture of self-reflection, improvement, and holding each other to account - however imperfectly realized - can be traced to the realisation of failure as a sector. Now, accountability is a given, a requirement on all aid projects, and built into most organization’s daily work. Every three years, ALNAP produces the State of the Humanitarian System report, based in part on shared evaluations. The SPHERE project and the Core Humanitarian Standard set clear benchmarks for quality. Although there is always more to do, the humanitarian sector’s progress on evidence and accountability can be a model for us to follow.

For now, though, ICT4D professionals can still operate more on conviction than evidence. Ultimately, the population targeted by our intervention may pay the price, in wasted time or resources, or worse, in actual harms caused by inappropriate and exclusive practice.

In the months we have remaining to us SIMLab will try to make meaningful progress towards a better future with the resources we have - we’re working with DIAL to finalize openly-licensed Framework approaches to Monitoring and Evaluation, and Context Analysis. Both are open for consultation RIGHT NOW on our website - head over to our resources page to find links to the Frameworks in Google Doc, ask questions, suggest improvements and get right in there and edit.

But there’s more we’d love to see done. Both the Frameworks could be improved way beyond what we’re able to do now, with more design work, improved sample tools and resources, and translations. I’d like to see better partnerships between academic researchers and practitioners in the ICT for Development field. Most importantly, I’d like to see a repository for practitioner evidence (like evaluations) for tech for social change projects, hosted by an impartial body or jointly by a network of organizations, donor-funded and supported to solicit and manage contributions, and with resources to conduct analysis on the evidence that arrives so that it can become open knowledge. ALNAP, the humanitarian body I mentioned earlier, does this already. There is a precedent. Can we challenge ourselves to be as generous with our learning as humanitarian agencies working in some of the toughest contexts in the world?

Without this kind of investment in improving our practice we’re just experimenting without learning anything - and that’s not ethical, when the projects we work on affect people’s lives. We are bound by our ethical codes - be they the Digital Principles, human rights, or humanitarian principles - to do better.

Responsible Data versus Data Transactions: the coming culture clash

Wed, 01 Nov 2017 00:00:00 +0000

SIMLab’s recent consultation on responsible data in practice demonstrated a deep disconnect between two opposing visions of data in social change work: one, rights-based and respectful of the ownership of the people we serve of their own data; and the other, data-centric and focussed on transactional exchanges of development gains in return for data access and monetization.

The consultation, part of the Good Data Collaborative funded by Stanford’s Center on Philanthropy and Civil Society, which we announced back in May, was published in full today. The consultation was part of the work of the Collaborative, a joint project with the Center for Democracy and Technology (CDT), Future of Privacy Forum (FPF) and The Engine Room (TER), to look at the resources available to help social change organizations to manage data more responsibly.

Our findings suggest that RD is a complex issue, and rarely handled effectively even in organizations that recognize the need to improve their compliance with RD principles. For many of our respondents, ‘responsible data’ is a new concept, without organizational compliance mechanisms or even broad understanding. Our interviewees see data practices as largely left to individual actors to implement, monitor and enforce; people do not know where to go for help, and even where they do understand the basic principles of RD, they express feeling overwhelmed by the complexity of implementing the required practices in their organization. In many cases, they respond to the uncertainty and discomfort by putting the responsibility for becoming compliant on other colleagues. Many express concern about not properly understanding the law covering data management, and many do not publicly admit to their uncertainty. Donors and platform providers are equally challenged to provide guidance and investment in a challenging and potentially expensive area with such strong links to legal liability and capacity-building.

But, critically, the consultation also brought out a brewing ‘culture clash’ between data-centric and rights-based approaches to technology in social change projects which will needs open discussion.

Two points of view

Respondents interviewed as part of our consultation held opposing visions of data in social change work: one, rights-based and respectful of the ownership of the people we serve of their own data; and the other, data-centric and focussed on data access and monetization.

Some institutional donors are investing in Responsible Data toolkits, mostly through staff engagement with the issue at conferences and events, participation and support for broader ethical codes such as the Principles for Digital Development, or by directly developing their own toolkits and guides - USAID’s work is due out later this year.

Others are taking their investments in a completely different direction, expressing enthusiasm about the opportunity they see in monetizing data about clients, service users or aid recipients as part of poverty reduction work, as long as the data relationships featured ‘trust and transparency’. They highlighted services aimed at low-income people that rely on personally identifiable data, such as mobile data usage, to generate benefits such as credit histories and access to low-interest microloans.

Our interviews pointed to a widening gap between proponents of RD and the enthusiasm and funding flows towards data-centric, utilitarian projects which prioritize access to and monetization of data over RD principles. These opposing views might arise even within the same institution, in some cases. The data-centric vision of tech for social change, though, appears well-represented among a group of donors with relatively large spending power, lighter emphasis on evidence-based granting, and swift decision-making - although SIMLab also sees it at work in the ‘innovation’ spaces around technology, particularly in humanitarian aid.

What this means for implementation

These powerful organizations can heavily influence practice beyond their grantees. One conversation painted a picture of a pendulum swinging too far towards data as a good in itself, with a more context-specific and grounded analysis of risk and benefit seen as negative, expensive and too conservative, in the face of the limitless potential of data-driven work. This translates into lack of funding and interest in implementation of RD, and perhaps more damagingly, lots of funding for data-centric approaches that do not respect the rights of data owners. In this analysis, there will be no way to promote or encourage a cautious, human-centric approach to data management until ‘the pendulum swings the other way.’

This raises urgent and, to SIMLab, disturbing questions about power and the role of data and ethics in the tech for social good space. These rapidly polarizing views of and approaches to RD are setting up inconsistencies between and across platforms and projects that would make it impossible for data subjects to navigate the marketplace of such projects and make informed decisions about who should get their data and how it would be managed. We need to explore and openly discuss the tension between data positivism and the responsible data movement, so that at least this disconnect is understood and acknowledged.

Learn more

Read the report, get involved on the Digital Principles forum where you can discuss Principle 8, Addressing Privacy and Security, and follow the #responsibledata hashtag. Later in the year we’ll be sharing new tools developed, redeveloped or finished off on the ResponsibleData.io site as part of the Good Data Collaborative project. And tell me what you think in the comments, below.

The SIMLab you didn’t see

Tue, 17 Oct 2017 00:00:00 +0000

Now that SIMLab is closing, I’ve started trying to find a new home. I always have a host of questions when walking into an interview, but there’s always one I save for last. To me, it’s the most important thing to ask.

So…tell me about the work culture.

When I ask this, almost every group I’ve ever interviewed with typically brings up things like benefits and work-life balance. They might say something about how the team treats each other, but more often than not, I hear obligatory buzz words like ‘respectful’ and ‘inclusive.’ Both of those are super important, but really, shouldn’t this be something I can take for granted? And then there’s the dreaded “we have a ping pong table,” at which point I have to pray it’s a phone interview, because it’s literally impossible for me to not roll my eyes. (I’m not knocking ping pong. I happen to be a beer pong champion. But I can’t tell you how many of the places that have space for ping pong tables don’t seem to have space for new mothers to pump, and I can’t see how that’s fostering an inclusive environment).

Closing SIMLab is truly a loss, for a lot of reasons. But one of the reasons most personal for me, and I imagine for those lucky enough to have worked on the inside, is that closing SIMLab means shuttering a company culture that’s incredibly rare. It’s the only time I’ve ever experienced it in the decade I’ve been doing this work, and I wonder and worry if it’s something I’ll find again.

So what is workplace culture, and how did SIMLab manage to nail it?

Culture is our organization’s character.

It’s how everyone in our organization does things - how we make decisions, how we treat each other, how we are driven. It’s an overarching integrity that’s reflected in everything we do. Culture is what everyone does when no one’s looking - not of guilt or obligation, but from desire and a dedication to shared purpose. SIMLab is special. Our culture is remarkably principled, marked by unparalleled talent and intelligence, and a level of drive that shines in the face of adversity. And we have, without a doubt, the most hilarious team I’ve ever encountered.

Culture is at least as important as your business strategy, company objectives, or compensation package. Not that all of these aren’t critical to success - something the SIMLab team knows all too well. But I’ve watched organizations execute on all of these brilliantly well while failing to build a great culture, and these organizations struggled in key areas where SIMLab flourished: attracting talent, driving engagement, and keeping a happier, more successful staff - one that sticks around when things get really tough.

Most organizations are starting to get wise to the reality that our fundamental assumptions about how, where, and when work is getting done have shifted. Workforce demographics have changed. The millennial workforce is thinking deeply about the meaning of work, and it’s having an impact on other generations. Salary/title/brand are less important than they used to be. The new imperative is meaning and purpose. What they do and how that manifests in the world matters.

There are a lot of things that affect culture, but there are a handful of things that SIMLab did especially well.

Work Environment. SIMLab is extremely open and collaborative. Everyone’s opinion is important, always, and there have been only a handful of occasions when the full team wasn’t consulted. The team works supportively, and when decisions are made, it’s done with total transparency. But beyond this, the team is just the most ridiculously fun group of people to work with I could ever imagine - and I work from a home office more than halfway across the country. I have never, ever, laughed as hard as I did this last year, and when you work as hard as this team does, that matters. The team could somehow manage to make tough decisions and send cat surfing gifs via Slack in the space of a minute and a half, because they take the work seriously, but never themselves.

Policies and Philosophies. SIMLab makes it clear that, while we take pride in our company and our work, we care about our team as people first, and that means that we not only value their lives outside of work, but we trust them. We offer unlimited sick leave and allow the team to take medical appointments at any time during work hours, because it’s a pain in the ass to schedule off-hours appointments, and because they would never abuse the policy. We allow the team to work from home and remotely as needed, because we believe our team will work more effectively when they have a voice in defining their work schedule. We make sure they know that, above all, they are valued as people much more than employees, and that we believe in them. The team works hard - much harder than any team I’ve ever seen - but it never feels like an obligation. I really believe everyone pushes so hard because they feel valued and needed. And they are.

People and Principles. Long before I came to SIMLab, the team worked hard to build principles and a body of work worth being very proud of, and a reputation the team was keen to protect. When you join something like that, it’s hard for anyone not to feel a part of something important, and it’s easy to work hard to continue that success. We’ve done incredible work in the last few years, and the team knows and believes in it. SIMLab does an excellent job of hiring brilliant, talented people that have integrity, and are driven by meaning and purpose.

Leadership. This is, to me, the most important, because without it there simply cannot be strong culture. The way your leaders communicate and interact with employees, what they celebrate and recognize, how they make decisions, they extent to which they trust their teams, and their general attitude and beliefs, are the core of culture. I’ve been fortunate to work with a lot of very capable leaders over the last decade - but none have come anywhere close to Laura, our CEO, who manages to combine strategic vision with authentic love for her team - something everyone felt. It makes every single person want to fight, hard, despite the odds. There is no better feeling than to go to a job where you believe that you personally make a difference, and Laura gave this to her team.

The SIMLab team is the hardest working, smartest, most wonderful group of people I could ever have dreamed of working with. We’ve been in an unfortunate position of paying brutally low salaries in one of the highest cost of living cities in the US, and unable to augment them in the several years of our existence. Over the last year, we had begun to evaluate whether we would be able to stay open - whether we had a sustainable business model - and all of this was no secret to the staff. Through all of this, and long after we had to delay and ultimately stop paying salaries, the staff kept showing up, day after day, producing the same exemplary work, and behaving with the same integrity and - amazingly - humor, as they always had. This is something that can’t be achieved with money or even mission, but only with culture. I’m forever grateful for the small period of time I got to be a part of it.

Our evaluation of Groupe URD's open-source Sigmah platform is published

Wed, 11 Oct 2017 00:00:00 +0000

We’re pleased to share our evaluation of the Sigmah platform: open-source project management software for humanitarians built by Groupe URD. This evaluation was the first to pilot the Evaluation Criteria we developed for our Monitoring and Evaluation Framework, and the first that we know of to evaluate a software-focussed aid or development project as if it were any other social change project.

Sigmah, created in 2008 in response to requests from Francophone humanitarian agencies to build for their overlapping needs and use case, and funded by Agence Française de Développement (AFD), was at a critical phase in its life, and needed an assessment of its outcomes, strengths and weaknesses to enable its Steering Cooperative and Groupe URD to make strategic decisions about its future. The evaluation sought to review the technical basis of the software; the team and business model around it; the support and sales approach; and its governance.

We were excited to undertake the project, bringing to it not only our work on how to evaluate technology in social change work, but also our experience building and maintaining free, open-source software for the humanitarian sector, in the FrontlineSMS project.)

The evaluation showed significant achievements: with a small team and budget Groupe URD had built a powerful platform with a solid code base; provided excellent support to their users and continued to bring on new clients; and had generated a new business model in response to their changing environment. However, it also showed that they needed to improve project management processes, streamline their governance, and refocus their target audience and thereby, their business model. Groupe URD have transparently shared their response to the evaluation, and their plans for next steps, alongside the full evaluation report.

More than anything, the evaluation findings underscored the acute challenges facing open-source platforms in the aid and development space. Frequently undertaken by organizations whose core business is not software development, such projects are dogged by unrealistic and conflicting stakeholder expectations, and chronic under-investment in a funding environment which prefers new and ‘innovative’ projects to maintaining and incrementally improving existing platforms. There is a real tension between the quality of user experience and enterprise-level capacity that organizations demand from software platforms, and low cost expectations attached to the open-source label. More on this in a forthcoming joint post reflecting on the recent MERLTech panel.

Evaluating such a project using our adapted OECD-DAC criteria was an interesting exercise, and will help as I refine and finalize our Monitoring and Evaluation Framework in the coming months, thanks to support from the Digital Impact Alliance. The frame of the Criteria ensured a rounded look at the project using an external logic, which I think made it a more powerful exercise, even if not all of the Criteria were relevant. We will share those resources on the SIMLab and DIAL websites as they become available.

SIMLab is closing

Wed, 06 Sep 2017 00:00:00 +0000

I am very sad to announce that SIMLab is closing.

In the three years since we spun out FrontlineSMS and launched as a new non-profit brand, we’ve built a team, a culture and a body of work of which we’re incredibly proud. We’ve worked on projects all over the world, including here in Washington, DC; developed frameworks, case studies and research on inclusion and excellence in technology for social change; and shared our message of principled and evidence-based practice with practitioners and decision-makers. Even in such a short time, we’ve deservedly built up a reputation for expertise, solid execution and integrity. And I have never enjoyed going to work as much as I have at SIMLab.

But the bottom line is: our business model is weak, and due to an unexpected and very frustrating series of events, we don’t now have the cashflow to meet our financial commitments.

I’ll write more about what happened in the coming weeks [editor’s note: these posts are now available here and here] - as ever, our goal is to be forthright and transparent, in the hopes that our lessons will help benefit others. But for now, I want to write about what this means.

Starting immediately, our staff are looking for their next challenge, and are the most high-performing, committed and wonderful people I’ve ever had the joy to have as colleagues. You can read about them and what they want to do next, here.

We are behind on staff paychecks and some other liabilities. If you’ve ever used our resources, been a client or partner, or simply enjoyed our cheery presence in the world, please consider helping us pay off what we owe by making a donation here.

Until we close late this year or early next, we are open for business, preserving our resources and learning for posterity, dropping some last-minute wisdom on our blog and in op-eds, and continuing to provide our world-class consulting services. Now is the time to get us to help you! Find out what we do and how we might work together, here.

If you are a current client or partner, we have already contacted you to lay out what will happen next. If you haven’t heard from us and feel that you should have, please reach out.

FrontlineSMS continues to go from strength to strength, and you can find their website here.

We’re preserving as much of our learning and as many of our resources as we can on this website, which will stay up indefinitely to house them and remind the world that we were here. We are also publishing some of the ideas we had which we never got to do. Please feel free to pick them up and get them done! Get in touch if you want to talk about them.

For important bits of SIMLab, this is not the end. Our ideas and principles will live on, in our outgoing staff and on this website, in the concepts and frameworks we came up with and explained to the world, and the projects we worked on. SIMLab, as a container for all those things, has failed, and I’m sad and not a little angry. But I’m also philosophical, and eager for the next chapter and new challenges. Mostly I am grateful - to you, our readers, partners, friends and clients; to the funders who supported us; to the organizations and colleagues who inspired and worked with us; to the personal friends and companions who have helped us through the last tough years and months.

Most of all, I am more grateful than I can say to my team. I love each and every one of you unreservedly and I am so sorry we couldn’t keep going. All of this has been worth it because of you. Thank you.

To celebrations to come.

Laura

Talking about tools: an early warning system in Kenya

Fri, 30 Jun 2017 00:00:00 +0000

Communications workshop with community peace representatives—Kitale, Kenya

At SIMLab we place a lot of value on the time before a project begins—the design phase, which comes after a context assessment but before project implementation. Project design is the foundation of a project so we devote quite a lot of time and resources to ensure the project is set-up for success. We also ensure each of our projects is thoroughly documented and shared so that others can learn from our findings, failures and fun! Here are some insights about how organizations use, modify and abandon tools illustrated in part through our ICT4COP pilot project in Kenya.

In May SIMLab traveled to Kitale, Kenya to visit our partners in advance of our upcoming pilot on Early Warning Systems in Kenya, and to review the technology and communication systems in place. This project is part of our ongoing Horizon 2020-funded research on police reform and community policing described here.First, in November we conducted a Context Analysis based off of our framework which helps us to understand the people directly and indirectly targeted by the project; the community and culture in which they live; the market and technology environment; the political economy; and the implementing organization. We spoke with local police, community based security groups, village chiefs and elders, local youth, women and girls, and Handicap International (HI), our project partner. During the context assessment we also learned about other key organizations who support the work of HI on an armed violence reduction program—Justice and Peace Centre (JPC) and Free Pentecostal Fellowship in Kenya (FPFK).

After we had analyzed our notes and insights from activities conducted during the context analysis we found that SMS was the most inclusive way to communicate with the target groups for the project (more on that below). But we didn’t know how the technology and communications could be improved in the next phase of the program. In order to make recommendations and implement changes we needed to go to the project site to talk with staff, participants and other important stakeholders about how to best shape the project plan.

The Project: Early Warning System in Kenya

Since 2012, FPFK has run an Early Warning System that relies on SMS reports sent from community members, which are then read, responded to and forwarded to relevant actors through an SMS platform called ActiveXperts. Before starting the next phase of the project SIMLab needed to do a technical assessment to first understand whether or not ActiveXpert’s system was fit for purpose, and whether there were improvements that should be made. The context assessment made it clear that SMS is an inclusive, widely accessible channel in the target communities, which made ActiveXperts a feasible tool. But before committing to using the tool we needed to understand its features and how it was being used by FPFK. Specifically, we wanted to see whether ActiveXperts had the potential to help us close the feedback loop between incident reporters, the implementing organizations, local security institutions and other NGO actors in the area.

Some questions derived from our context assessment framework specific to the tool are:

Does the tool require internet; does it have an offline mode?
Does data remain in the system or can it be exported and saved in a locked and encrypted file?
Is the tool open source?
Is support for the tool offered? Over what channels (e.g. online, Skype,)?
What costs are associated with the use of the tool?
Are there capacity constraints associated with messages sent, received or stored in system?

Is a new tool the best way forward?

FPFK felt that SIMLab would be able to help make the EWS system work better, which to them meant replacing ActiveXperts for a new tool that would cover all the desired functionalities. In our experience, organizations hit a point where they feel the tool in front of them does not work in the way they need, and they stop using it. Sometimes the function of the tool is so essential to the organization that they immediately find a new tool and work through the kinks, but many times an organization will completely abandon tools for the task and take a backwards step to a manual, analogue solution. Can this be prevented?

Like so many of our conversations with implementers, FPFK felt ActiveXperts generally worked well, but there were some additional functionalities they wanted and felt a new tool would be the best way forward. Our first goal is to find out more about the tool and needs of the program without jumping straight to replacing the technology; this approach is often at odds with our client’s initial desires. Sometimes tools face problems with speed, efficiency, reliability, or lack of features, but many of these issues can be ameliorated within the tool itself. Usually, users know what they need, and they will often refer to another tool they’ve read about or heard of and say ‘won’t this tool fix our problem?’ This scenario and the frequency of ‘tool heresay’ is more fully teased out in a research report by The Engine Room where organizations were asked how they approach tool selection. We work closely with clients to discuss our methodology and instill confidence that we will help them implement the best solution.

Tool burnout

‘Tool burnout’ occurs when an organization is fed up with a tool not working in the way they would like. But we think tool burnout can often be prevented. One way to safeguard from this feeling of discontent over a tool could start with taking more time to choose the right tool from the beginning, really investing time in fitting the tool into operations, and learning how to use it. A proper context assessment that leads to a discrete design phase and tool selection can increase an organization’s confidence that the tool is fit for purpose. Could that confidence encourage organizations to continue making effort to make the tool work, ensure end-users know how to use it, ensure staff have the proper buy-in process, training and more?

It’s not just about the tool

Another mindset we start with, and try to help our clients to see, is that maybe the tool isn’t the problem after all. Rather, many challenges may be resolved by improving business processes and behaviors which are key to improving the overall system. We know that’s not easy to hear—tech is the easy thing to pick on, people and complex systems are not.

The trip to Kenya was no different. By the end of the visit we had a whole list of identified challenges and solutions, and it turns out some of the solutions are pretty quick fixes. For instance, there was quite a lot of manual work being done with the EWS, but after searching through the ActiveXpert documentation it turns out there are functions that weren’t configured but were readily accessible on the tool - such as auto responses, auto forwarding and contact groups. Luckily we will be able to hire someone from ActiveXperts who can make a few changes in a couple hours, and much of the technology will be straightforward and automated. But that’s the easy part. Although the automation will free up some of the time of the EWS staff, the solutions required to make the whole system work better will take extra time.

We’re still working out what various improvements to the overall system will look like, but we know we need increased training for those who submit SMS reports and data protection best practices for their mobile phones. With FPFK we will implement various hardware improvements such as a backup battery and phone for when the office loses electricity.

We will be working on the EWS in Kenya to help rural and remote pastoralist communities in northwest Kenya monitor and respond to violence and insecurity. We expect the northwest region, like several other hotspots in Kenya, to become increasingly insecure in the lead up to, during and following Kenya’s national presidential election in August. These political issues make our work even more critical, and we’ll continue to write about this essential project and our work on tool modifications and closing the feedback loop.