<\/p>\n
Have you ever run, funded or been part of a development project?<\/p>\n
Have you ever gotten to the end of it and felt that, during the process, everyone had learned and grown, and had stories to share?<\/p>\n
Have you ever thought, \u201cWe should definitely share what we learned\u201d?<\/p>\n
And then someone wrote a report. And that was the end of that.<\/p>\n
It continues to surprise me that we keep forgetting (or ignoring) the things that we all know: that building on history requires us to listen and learn from others\u2019 experiences. Instead, we like to invent our own new things \u2013 and we repeat the same mistakes ad nauseam.<\/p>\n
The web has changed our world in ways that we are still only beginning to learn, but development professionals haven\u2019t yet leveraged it to full effect. As a tool we\u2019ve applied it well in some cases, as more people have access to more knowledge than at any time in history. Yet we\u2019ve also applied it poorly: While information retention within our institutions may be going up, our knowledge retention often lags behind. So we see discussions on secure chat channels lead to pivotal decisions, then vanish as if the conversations had never happened.<\/p>\n
We still have much to do to adapt our behaviours and cultures to work with these new tools. We need to keep thinking through how we are going to make the most of both human and machine experiences, as they increasingly combine.<\/p>\n
These might feel like hard questions, but if we shift the way we approach solving problems together, we might come up with new answers.<\/p>\n
<\/p>\n
Let\u2019s start with a user need. Think of a project you worked on six years ago. You\u2019re trying to solve a similar issue now, but you can\u2019t remember how you did it before. You remember that there was a really good idea, a phrase, a table of data, a use-case or an interview that helped your team to find a solution. But how do you find the thing you remember?<\/p>\n
You might, as many people do (whether allowed or not), carry a backup of all the project details around on an old hard drive. You might try and find the old project website, if there was one (which is likely). You might try a funder\u2019s website to see if they have a copy. You might email a colleague who worked with you on the project \u2013 you might even call them.<\/p>\n
However you frame this, your starting point is to conduct a \u201csearch.\u201d But a search for what? The project title? The name of a person or a topic? What if you can\u2019t find it? What if the information you\u2019re looking for is in the notes from a phone call, which were never properly categorized in the first place?<\/p>\n
This all leads us to our first design principle:\u00a0Design for search<\/strong>.<\/p>\n What does this mean? First and foremost it means something very simple: Did you add enough words to your digital files (e.g. in the title) so that when you type words into a search box six years later, you might have a chance of finding it?<\/p>\n In the age of the web, this is harder than it might seem. The average website survives\u00a0less than three years<\/a>\u00a0so we also need to make sure this information can be searched for at all. There\u2019s a huge spectrum: Google isn\u2019t going away anytime soon (probably); your project website will atrophy rapidly (unless funded); Wikipedia may or may not quite fit; Archive.org archives pages more than their context; national libraries have lasted centuries, but may not be as interested in hosting your project files as you might wish.<\/p>\n This drives us to a solution that is culturally different than what most of us are used to. Rather than publishing project details \u201cin your house\u201d (i.e. on your organization\u2019s website, which is usually designed around the hierarchy of the organization, and still reflects its physical structure), you should focus on publishing in \u201ceveryone\u2019s house\u201d (i.e. on popular websites with a digital-native structure that reflect all users\u2019 needs, not just those of your organization). You should, therefore, place your content in as many different places as possible to maximise the chance that you, your colleagues, funders, partners \u2014 and the rest of us in the development space \u2014 can find it.<\/p>\n Our second design principle is:\u00a0Publish widely under an open license \u2013 or at least for open access<\/strong>. By providing context and publishing widely, under open licenses such as Creative Commons, development professionals can create a better return on our collective investment. We can help the machines help us find things. To give one example that\u2019s likely to resonate: How many of you have used Google to get a copy of your own company\u2019s logo?<\/p>\n <\/p>\n There\u2019s an essential question that\u2019s deeply linked to enabling others to find, use and build upon your work: Is what you are producing relevant to the people who could potentially use it?<\/p>\n How often have you encountered a summary report that is written for \u201cpeople\u201d rather than for \u201cyou\u201d? On a regular basis, I find myself asking, \u201cWho is this written for \u2013 what is their name, role and organization?\u201d If you can\u2019t answer that question, then let\u2019s pause for thought.<\/p>\n Some questions you should answer to define your audience include:<\/p>\n Certainly, everyone wants to publish on their own websites, but where are your users obtaining their information? Go to where they might find you. The ambition here is, in most cases, not to drive traffic back to your website. You\u2019re not a destination, the content is. If I\u2019m going to find it, it should be in as many relevant places as possible (e.g. blogs, Instagram, LinkedIn, Slideshare, Pinterest, Wikipedia, Archive.org, Github, postcards, books and videos). This isn\u2019t about having a social media strategy to flood people with your content (you do that already). It\u2019s about making sure that when your site is dead and the team is scattered to the wind, you can all find your own work again.<\/p>\n Once you have a sense of your likely readers and their needs and information sources, ask how you can:<\/p>\n The answers to these questions can help you deliver content that\u2019s likely to reach the people who need it, not just now but for years to come.<\/p>\n <\/p>\n In my time running the\u00a0Open Data Institute (ODI)<\/a>, we took extensive measures to foster a culture of open sharing and long-term accessibility of information. I mandated the creation of shared Google documents. The sending of attachments (internally) was banned. The guiding principles of this approach were reflected in this checklist, to be followed with all documents:<\/p>\n This applied to all meetings (internal and external), as well as all operational documents, research, proposals, HR, budget, financial reporting, sales planning and reports, project plans, performance metrics, board reports, compliance reporting, and legal and accounting documents. Instead of each person writing something, then emailing a document, we would schedule short group working sessions to simultaneously edit documents, often while in voice contact to discuss anything unclear. This produced better outcomes, and was also far faster \u2014 but only after induction and training, as it takes practice to work so differently.<\/p>\n Once learned, this process was also applied to co-create proposals with clients. The outcome was that the client could input directly to proposal documents, engage in internal Q&As about scope and budget, and shape outputs, timing and costs. This improved the team\u2019s relationships with clients and their trust in the team.<\/p>\nWHY, WHAT AND WHERE ARE YOU PUBLISHING \u2013 AND FOR WHOM?<\/strong><\/h2>\n
\n
\nStart by writing down the essentials. This can involve writing the press release for every project. It\u2019s not that everything should go through PR, but the process of thinking about the story and the specific audience is critical. Who will act upon it and why? In many instances we know that there are likely only 20 people who will read any report in-depth, and maybe 100 who might read an executive summary \u2014 so it can be helpful to write the summary first. How will you describe this work to someone verbally in two years? This is a powerful, behaviour-driving question.<\/li>\n
\nIs it a document? A PDF? Slides? Images? Data? Code? Algorithms? What\u2019s useful to the user? Why? What format do they (not we) need most?<\/li>\n\n
CHANGING HOW WE WORK TO BE OPENLY COLLABORATIVE<\/strong><\/h2>\n
\n