This week UNICEF is partnering with the Government of Finland to organize a big innovation shindig – the rather grand sounding “The Global Innovation for Children and Youth Summit“. I’m not involved in the event – but I thought this would be a good opportunity to think about what Knowledge Management can learn from Innovation in UNICEF (and that’s probably a lot since they are much more established as part of UNICEF’s work).
One thing that I particularly like was the establishment of a set of “Principles for Digital Development” which provide a kind of both ethical and practical framework for doing effective ICT for Development programming. UNICEF, UNDP, UNFPA and a wide range of other partners have signed up to these and are promoting their use by others.
The key principles are listed below (with links to more detail/explanation on each from the Digital Principles website)
- Design with the User
- Understand the Existing Ecosystem
- Design for Scale
- Build for Sustainability
- Be Data Driven
- Use Open Standards, Open Data, Open Source, and Open Innovation
- Reuse and Improve
- Address Privacy & Security
- Be Collaborative
Taking a look through these I realize these are also very useful considerations when looking at how to support knowledge management for development. A large component of knowledge management work involves technology platforms, although of a different nature from those mostly used in innovation projects. But a larger (and often underrated and underappreciated) component of knowledge management is about people and processes so it’s interesting to reflect on how well these principles also apply to the non-technological aspects of KM. And they translate quite well, probably because a big factor in success for ICT for Development projects is also about people and process and not just the products themselves.
Below is my brief take on how the Digital Development Principles can be adopted/adapted as Principles for Knowledge Management for Development (KM4DEV):
- Design with the user
In KM this means doing work that meets the needs of users and contributes to help them meet their goals. Building a KM system for its own sake (e.g. because we need a place to keep all the knowledge) without reference to how it will help meet people’s needs is a recipe for failure. Any KM initiative needs to help meet the goals of the users and support them in their day-to-day work – it also has to be designed to make it easy for them to use.
- Understand the existing ecosystem
In knowledge management terms this means understanding how people currently share knowledge – what tools do they use, what technologies do they have access to, what are their preferences or comfort zones. This may mean supporting or building on an existing initiative or building using familiar tools rather than trying to find the perfect tool or building something that competes with something that already exists (competing platforms or repositories are common in KM but in the end they damage knowledge sharing by fracturing people into silos).
- Design for scale
In KM terms this means that although you can do good work by carrying out KM work on a single activity or project, if you really want to make a different you need to think systems. Sharing lessons on a specific project is good, but if every project does it differently and there is no shared approach or single place you can find them then the impact is much less. There are many standalone KM projects but these are hard to sustain over time and the knowledge is lost if they are not able to connect to something larger within an organization or a sector.
- Build for sustainability
This is also critical for knowledge management – too often I’ve seen a project to create an online community or lessons database that has focussed on the creation of a platform or the initial launch and population of content and not enough on how to maintain it afterwards. More than technology, the human dimension of how something will be supported over time is the most challenging, and often the best solution is to mainstream the initiative into everyday work and avoiding having a parallel set of KM tools and activities outside of the area of work they are supposed to support.
- Be data driven
This applies in any project. Bu in KM (as with platforms and tools) tracking the numbers of people who use them is important, as is capturing feedback on how useful the tools and how relevant is the knowledge provided. But it’s important not to stop with what can be quantified. Real value of knowledge management comes change in outcomes as a result of improved practice informed by knowledge. Sometimes this can be quantitative such as time saved or money saved through improved approaches, but often this is qualitative information in the form of stories of how a critical piece of knowledge changed a decision which led to a better result, and so it’s important to start but not stop with what can be counted.
- Use open standards, open data, open source and open innovation
Too much knowledge is hidden behind journal paywalls, restrictive copyrights and lack of transparency. Making material available using creative commons formats, and making platforms that are not “pay to play” is important in trying to level the playing field for knowledge exchange. There is also a big benefit in “working out loud” that is sharing what you are working on while you are working on so others can see and respond. The aim here is to share as much as possible what can be shared in terms of data, research, experience and to lower whatever barriers and bottlenecks are in the way of this. That said, open knowledge is a little different from open source development – for me at least while “open source” is good I don’t believe it is as strong a need as open sharing of content. For me the focus is on making whatever you have sharable so others can reuse it and in an organizational context that might occasionally still use a proprietary platform.
- Reuse and improve
This is a fundamental tenet of knowledge management – the whole purpose is to start from using what knowledge already exists and adapt it, and to capture knowledge from your own project so others can reuse it. More than with innovation, knowledge management is all about building on the work of others. Many problems have already been at least partially solved elsewhere yet all too often we try to create our own solutions without looking at what is already out there that we can adapt.
- Address privacy & security
The usual meaning of this expression also applies to KM i.e. when collecting data being clear how it will be used and with whom it will be shared and making sure that confidential information is adequately protected from unauthorized access. There is also a tension in KM between encouraging open participation and providing a safe space where people can be candid, share their experiences including their failures – here it is also critical to be clear to people how the knowledge they share will be used in order to develop trust in the systems and processes – without this people will quickly stop sharing information of importance which at best means not learning from mistakes and at worst failing to notice serious problems that no-one dare speak up about.
- Be collaborative.
As Chris Collison says “All of us are smarter than any of us” – knowledge management is about collective wisdom and sharing what we know with others and learning from others. Communities and social networks in particular foster cooperation and collaboration across functions and locations and can help connect people together that might not otherwise collaborate or learn from one another. In the age of social computing I always like to say “I store my knowledge in my social network”.
There is one additional 10th principle I would add for knowledge management that might be implicit in the 9 principles but deserves singling out. This would be:
- Learn before, learn during, learn after
A key element for any successful knowledge management system, strategy or approach is that it contributes to organizational and individual learning.This is critical to ensure that we continually improve both the current and future projects as a result of learning from our experience. This could be part of “be data driven” or “reuse and improve” but it is more than that. We need to learn from what can be gleaned from the monitoring data, and we need to reuse and adapt tools and approaches we have developed – but it’s important to remember that most knowledge us not stored in databases or tools, but in the experience and expertise of individuals. We therefore need to ensure that any knowledge management system helps individuals and groups to reflect on their experiences to extract the lessons and to help transfer those to others. This can happen at the end of a project – but it’s important to keep learning during a project too since often our memories of what happened and why are more unreliable after a project is completed (and subject to confirmation bias) and by learning while doing we may be able to make improvements to our project, and to grow professionally on a faster cycle.
Actually, while this last principle is an important part of knowledge management – I’d argue that it should be an innovation principle too – since one of they key reason to innovate is to learn. Maybe it’s just a good principle for development in general.
Yes, this is another review, or perhaps more of a rumination on “Geek Heresy” by Kentaro Toyama (available on Amazon!)
I’ve long been a fan of the ICT4DJester’s snarky tweets about ICT for Development (Toyama’s alter ego) and have been looking forward to this book. Here is a quick overview and a few thoughts about his conclusions.
The first half of his book is a critique of techno utopian promises in development and in particular on technology based packaged interventions (One Laptop per Child, Community technology centres etc.) that have been variously touted as being the keys to ending poverty. Development veterans will probably be nodding vigorously in agreement with his critique which is strengthened by not only drawing from examples of his own work in the area of information technology but also on examples of non-IT “technologies” such as microcredit and even elections to show the weaknesses of focusing only on the intervention (the “silver bullet”) without looking at the ecosystem in which it is placed. He also takes a satisfying swipe at some of the hype around social marketing using the example of the two for one programme of Toms shoes.
His basic thesis is that technology (or any packed intervention) acts as an amplifier of human intent but not as a good in of itself. In other words technology can enhance whatever purpose humans choose to put it to, but it will not do good by itself, only when the people using it have the motivation and the capacity to use it. The problem in development is that the people who have the greatest need, are also often the least equipped to take advantage of technological fixes.
This also reminds me of the conundrum in knowledge management that the main focus is often on scientific evidence around the design of interventions and how to generalize them using hard data, and rigorous research and evaluation – but there is much less focus on the importance of tacit knowledge – know-how in what it takes to actually get things done which revolves more around the people and the environment. Unfortunately while you may be able to replicate the design of an intervention, it’s much harder to replicate the qualities of the people and environment which it can be implemented successfully.
Toyama’s proposed solution for this is to foster “intrinsic growth” in the communities and individuals with which you work on a development project. This sounds like capacity building – but Toyama breaks this down into three critical components i) intention or heart (the desire to improve things) ii) the skills and judgment to pick the right opportunities and strategies to advance their cause and iii) will or self-control i.e. the ability to resist distractions, temptations as well as to put off present day comfort for future gain.
The second half of the book looks at how intrinsic growth can be developed, drawing on a number of inspiring real life examples. He quite rightly stresses that this is difficult and takes a lot of time and investment. He proposes several methods through which this can be done including education, mentorships and deep engagement with the communities we seek to help, as well as a focus on supporting them to meet their needs rather than trying to get them to pursue our externally imposed goals. While I think he is on to something important here – this part is less satisfying as I think he is on thinner ground in terms of evidence and experience. In fact this is a common trait of books on development – a first half of well crafted and strongly sourced critique of current practice together with a convincing theory – followed by a second half which uses the theory to propose a way forward – with useful ideas but incomplete or insufficiently concrete to either convince or to implement.
In this case the challenge is that while education, mentoring and long-term engagement and focusing on the needs of the community and not the donor are clearly important factors in nurturing intrinsic growth, it’s not clear to me that they are the whole picture – nurturing “self-control” is especially challenging (I know I struggle with it at an individual level!). He’s also dismissive of societal nudges i.e. incentives by governments (or donors) to encourage citizens to behave a certain (hopefully more productive) way – while I think there is a fair amount of evidence that this can work – albeit not without some of the other elements in place too.
An area I wish he had elaborated on further was the potential of new complexity based approaches such as human-centred design and agile development to improve how development programmes are designed and implemented. These are promising in that they are designed with the users and the context in the forefront rather than simply introducing externally packaged ideas. They also emphasize the importance of prototyping and continual iteration to improve fit. However they still often result in technological fixes even if they are designed for the specific context, and do not directly address the underlying issues of will and judgment which Toyama rightly emphasizes.
Overall the book is a quick and easy read, and well worth the effort. The biggest take away is an important and too often overlooked aspect to development – that packaged interventions (whether ICT related or not) have an important role to play in development – but this needs to be combined with a strong focus on building the capacity and intrinsic motivation of the communities where they are delivered so that the interventions become an amplifier of a self-propelled desire for progress rather than an externally imposed solution. They are not the cause of change in of themselves but are key enablers when the right conditions for change are already there or are being carefully nurtured. And if we want to reach the most excluded we might want to start out focusing on the intrinsic growth rather before delivering technology.
I’ve been in a number of discussions lately with different programme sectors about how they can better document and share experience. There is both an interest from headquarters to “tell the story” of what we do and what works, and an appetite from our country offices and our partners to get more concrete examples of successful programmes i.e. not just guidance and research, but also some real case studies that show how it is done in practice.
I’ll try to write moire later on the whole issue of what approaches to use to do this, and some of the challenges – but I just wanted to share an important quick piece of advice based on what I’ve seen.
“Put your name on it”!
Too often organizations, especially UN organizations produce case studies, lessons learned documents, stories, articles etc. without a name on them. They are produced by “the organization”, or perhaps a department witihn the organization.
A nameless article migt be fine in a donor report, or even in public awareness raising, but it has very little use as a tool for sharing practical programme experience. That’s because the document isn’t the whole picture, it doesn’t capture all the relevant knowledge from an experience, only the highlights. The experience shared is intimately tied up with the individuals who were part of the process. Adding the names of the key actors involved in a documented real life experience has several important benefits for knowledge sharing including:
1. You know who to contact for more information – often the case study or report is only the opening for learning. If there is interest to reapply the learning from the experience then you are likely to have additional questions or want to get more information and background documentation. You need a contact name to do this, and a name is much more apporachable than a generic e-mail account.
2. Given all the work pressures, and the still relatively little prioritiy given by many organizations to investing in documenting experience, giving people public visibility for their good work can be an important motivator to take the time to share. Visibility helps reward people for good work, and helps build their reputation together with that of the organization (we are an organization that does good work – because we have good people).
3. The reverse of this is that having aname on something is also good for accountability, and quality. I’m going to pay more attention to the quality of apiece of work if I know my name (and reputation) is attached to it.
4. Name and reputation is also a marker for good work. The reality is that when we read a book, a magazine article or an academic journal article we are influenced not only by the content, but also the reputation of who has contributed to it. So it makes sense for organizations to profile and build the reputations of those doing good work since it not only benefits the individual it also improves the effectiveness of the message.
Basically we should think of case studies, publications etc. not as the end of the story as regards sharing and disseminating the knowledge – but rather as the start of sharing and as a stimulus for a conversation that leads to action, whether between practitioners on how to apply the lessons from an experience, or to work with government to advocate for and then implement new policy. A pubication is a useful synthesis of evidence and experience to inform action – but it takes conversation to turn it into action, and keeping the people in the picture makes it easier to move to this next step.
We are an important juncture in development at the moment with the Sustainable Development Goals due to be finalized later this year, and with discussion now turning full swing into what needs to happen to make them a reality, including a lot of discussion around how to make the UN (and the aid and development sector more broadly) “Fit for Purpose”.
A lot of the discussion on the SDGs is taking a typical form looking at intergovernmental monitoring and follow-up mechanisms, institutional arrangements and structures within the UN, financing mechanisms and partnerships. But at the same time there are quite a few groups doing some soul-searching about whether our system of goals and targets, development plans and project timelines and monitoring are really working.
A whole range of initiatives and approaches are emerging that could be loosely grouped under the umbrella of “complexity” i.e. the idea that development is a complex adaptive process and thus top down long-term planning doesn’t really work – instead we need to be more nimble and iterative in how we respond to circumstances and push the system in the right direction rather than developing a detailed master plan for a perfectly designed future.
To understand more about what complexity is and how it applies to development I’d highly recommend this recent blog by Owen Barder which poses a number of important challenges as well as some suggested ways forward for development work based on the idea that we are in fact intervening in a highly complex system.
But how are people putting this into practice?
In fact there are quite a few initiatives that respond to the challenge of complexity in development one way or another, whether or not they explicitly use the “C” word. Here are a few examples:
Problem Driven Iterative Adaptation (PDIA), and approach developed by Matt Andrews at the Center for International Development at Harvard. Building on the PDIA principles a group individuals from a range of organizations including the World Bank, ODI launched the “Doing Development Differently” manifesto.
A number of other organizations have adopted a “human-centred design” approach to innovation in development based on the principles developed by IDEO and outlined in their human centred design toolkit. This approach, also referred to as design thinking comes in different variations such as Stanford’s dSchool.
Another approach is the Cynefin approach developed by Dave Snowden for knowledge management and decision support. It is not specific to development but is being used (or at least experimented with) in a number of government and development sector projects.
This past week there was a discussion on KM4DEV about applying the principles of agile software development, and the agile manifesto to international development. There were quite a few replies from people who were already using different variants of this approach in their project management, mainly but not exclusively from ICT for development projects.
The UN and indeed many other development organizations are launching innovation teams, units, lab, networks etc. UNICEF was one of the early movers in this and has already gone to a degree of scale including setting up a global innovation centre and last week launching a global innovation fund. UNICEF and a number of other development partners adopted the UNICEF innovation principles.
Perhaps one of the older interventions in this discussion from the aid sector was Bill Easterly’s critique of the top down approach to aid, as well as the MDGs outlined in The White Man’s Burden and the follow-up The Tyranny of Experts. The idea here being that we need searchers (i.e. those who set out to find and build on locally applicable solutions) rather than planners (those who bring a toolbox of known “scientific” solutions that are imposed from above).
And there are probably many more I haven’t listed here.
One question you might reasonably ask is how are all these things related? Which one of these approaches am I supposed to apply in my work, or at least what are the relative strengths and weaknesses of each?
When looking at the increasing number of different approaches we can see they have similar elements – namely a focus on the importance of local context, of designing projects with users/beneficiaries/partners, and of running small experiments and quickly iterating them based on experience on the ground. But they also have differences in emphasis, methodology and even ideology. Some are more strongly grounded in theory, while others are very practical, and none currently has the upper hand in gaining acceptance. While they are often connected to one another and are exchanging ideas, they are also separate initiatives taking their own paths often with strong groups of followers. Sometimes they even struggle to find a common language to talk to one another (as nicely explained in this blog by Duncan Green about a cross-disciplinary meeting on the UNDP’s “Finch Fund”)
But how do we take on complexity in development if there is no unified theory and agreed approach, and no strong body of evidence on the merits of the different approaches?
I’d argue – from the principles underlying complexity, that this diversity of philosophies and approaches is actually a good thing. Since we don’t know the one best way to tackle complexity, and indeed the aid community is only starting to wake up to the need for and potential of complexity based approaches, then it only seems right that we should be using multiple parallel approaches (or experiments) that live in their own contexts.
The fact that there are multiple overlapping and competing threads means that people are starting to take the issue of dealing with complexity seriously and are searching for ways to address it.
What I hope to see in the coming years is an increasing attention to complexity, and with it a further blooming of different approaches and variations, and opinions as each technical discipline, think tank, activist group and organization seeks to put their own spin on it.
So what if these ideas are not entirely consistent and congruent? The principles of complexity thinking call for multiple experiments together with variation and adaptation, and so we should welcome multiple approaches to dealing with complexity that are emerging and evolving. And we can hope that these will continue to evolve and improve and that the stronger more promising ones will succeed while some of the less useful ones will disappear. But while I expect that the number of approaches and initiatives will reduce as this area of thinking matures, I think we shouldn’t expect to get a single unified approach that is widely agreed and universally applied – after all it’s a complex world out there!
Footnote: here is an older blog post I wrote on complexity back in 2011 when I was trying to explain to myself exactly what it is and what it means for development – Who’s afraid of complexity in aid?
Finding up to date useful information about people in your organization can be challenging – Who is the social policy officer in Bolivia? Who speaks French and has worked on conflict prevention in west Africa? Who contributed to the position paper on HIV and breastfeeding? Who knows.
We already have a plethora of different information systems about our people who are only partially connected. We have our HR system, our IT/Network directory, our telephone directory and we have various email lists and spreadsheets managed by individual offices and sectors.
Thanks to some great work by our IT colleagues we just launched a new staff profiles system in UNICEF at the beginning of the week that seeks to help with some of these questions. It is built using the Office365/SharePoint Infrastructure that the organization has already invested in, but linking to other systems as needed. I just wanted to share our experience in trying to come up with a useful profiles system, which we have called “Who’s Who in UNICEF” in order to address the challenges we currently face in knowing about our staff, in case it is of interest. Our new system was an attempt to pull together some of the different existing information sources to provide the best (but far from perfect) information that we could get about the people who work for us, in order to make it much easier for people to find out about one another from a single place.
Pulling this all together was tricky – but basically we built on the idea that useful information about any individual can come from three broad types of sources:
1. Official system information such as our HR systems and our internal directories. This is fragmented into several non-coordinated systems in our organization so we needed to map which is the “official” source for what information and then combine them together. This is already a step forward compared to what previously existed but official information is limited in that some of the more interesting things are not digitized or confidential where we work (such as performance evaluations, training records, past work experience) so can’t be shared in searchable profiles. Plus they often miss out key experiences and expertise – and as we found out through this exercise – official information about our people is often unreliable – wither out of date or just plan wrong.
2. What you say about yourself. A lot of people profiles in social media tools and enterprise social networks give you the opportunity to also enter information about yourself – what do you do, what are you working on, what are your interests, languages spoken, a flattering headshot etc. We merged these features with the “official information” giving staff the chance to be able to present themselves and their skills beyond what the organization officially knows about them. This makes the profiles more interesting and more useful because it makes them more “personal”. But self profiling also has its limitations – just because I say I have a particular skill or set of knowledge doesn’t mans that I actually do have it. And a superficial description while helpful doesn’t give the full nuance of exactly what your skill is.
3. The trail people leave in the system. One interesting way to figure out what people actually know about is the communities and groups they join, the information they share and the things they contribute to. Our profiles are starting to make use of the “social graph” i.e. what you work on, what you share and with whom you exchange information. We’ve incorporated some initial inputs on this such as highlighting documents people have worked on, shared documents, showing people’s activity feed and identifying who they work closely with through this information – but in the next few months we plan to do more, building on social graph tools that Microsoft have developed with Office 365. At this point I feel the potential for using this type of information to help recommend people and content based relevant to the person doing the search is very large – and also needs some experimentation to see how to get the best out of this capability.
A few lessons learned from this exercise:
1. Getting a common agreement about what should be included in a staff profile is challenging. Given the absence of good existing system the tendency is to want any new system to do everything and there is pressure to add a long list of potential attributes. Also some of the things that users want that could be extremely useful are just not supported by the underlying information that we have about staff. Having self completion fields can help with this, but if the profile has too many self-complete attributes then the chances are most of it will not get completed. Also there are some attributes that individual functions and offices would like that are not relevant to others so coming up a with a common list of useful core attributes is key.
2. There are a lot of data quality problems in our official systems of record about our staff that go unnoticed and therefore unaddressed (I expected this but perhaps not as many as we are currently finding). People care about how they are presented when they realize this is in a profile/search system so when they see this information is incorrect they want to change it – and I’ve had a deluge of e-mails requesting corrections. While frustrating this is important since it is providing an incentive for staff to care about what the organization knows about them and to get this fixed – and if we are lucky it will help put the spotlight on some of the challenges with our underlying staff information systems and create momentum to fix them.
3. Working with cloud service software like Office 365 has some great strengths, such as the ability to be able to search across content from multiple sources and to take advantage of the very promising work that has been done on using the “social graph”. It’s also challenging since the platform and interface is being frequently changed and updated and so there is a risk that any customizations are broken or obsolete without notice. In fact Microsoft are currently moving away from SharePoint profiles (on which our profile system is based) to Delve profiles, and we will soon have to recreate our profile system on Delve. However Delve profiles don’t yet allow the type of customization we have done in terms of grouping and ordering fields – but well we’re hoping that will change soon so we can migrate.
4. People don’t yet understand the “social graph” and can even be a bit scared of it. “How does the computer know what I want to see”, “Why can I see this document in my profile that should be confidential”. The social graph can at times be uncanny in knowing what you might be interested in. It may therefore show different results depending on who is looking at a profile. This needs careful explanation –and also reassurance that it’s only showing people what information they are authorized to view. It’s also a good reminder to check on the sharing/security setting on your documents – in particular a number of people put private documents in their ‘shared with everyone folder” probably assuming that if you didn’t know something was there you would never find it. The social graph it’s much easier to find things – which seems to actually a cause for concern for some :-0
5. The social graph only has what you put in it. We’re still only part way in migrating the intranet to SharePoint online and adoption of sharing tools like Yammer and One Drive is still fairly low. This means a fair amount of useful information is not being captured. The profiles have highlighted that a lot of staff are still not sharing much of what they do in any place where it would be easily accessible by others. We still have a lot of work to do to promote a culture of “working out loud”. Only when we have a higher level of participation in social collaboration tools and adoption of cloud storage (rather than people using the shared drive or worse their e-mail archives and hard drives as the main store for their important organizational work) will we really be able to get the benefits of the social graph.
I’m sure we will have a few more key lessons in the coming weeks and months about what works and what doesn’t and the key challenge of getting people to update and use the profiles. Will keep you posted!
Late last year I went to the South Asia region to participate in a discussion on knowledge management. I talked briefly about what we are doing globally, and then each country gave an update about what they are doing – and what their priorities and challenges were.
While I was trying to make the case for cross organizational networking and working out loud, as well as the potential for using social tools, what I heard from the ground was a bit of a wake up call as to where many offices still are in their thinking about knowledge management.
One of the biggest preoccupations of offices was being able to organize and then retrieve their everyday documents, and for many of them the way to do this was by reorganizing their “shared drive” i.e. a shared storage space on server in a local area network (I define this because some of you might be surprised that we are still working this way).
So what’s my advice about how to improve the management of the shared drive. Simple – GET RID OF IT.
What’s wrong with having a shared drive in your office?
- It’s only accessible when you are in your office – you can’t easily access it when you are at home or travelling.
- Access control is limited – usually at the level of folders directory and you can’t easily share things with people outside of your group on an ad-hoc basis (also because the probably don’t have access to your LAN)
- There are limited metadata and only a simple search to help you find things.
- Space is usually limited and you are most likely already close to your quota.
- Let’s face it – your shared drive is probably a mess. You most likely have years of accumulated documents in a directory structure you didn’t create and possibly don’t understand. No-one knows what half the materials are or whether they are important and whether or not they are current. There is no logical file or directory naming convention, no-one can tell who edited what and which is the latest version.
So what can you do instead? Use the cloud!
In UNICEF we are a Microsoft Office365 house so the tools I’m going to mention here are based on that but Google, IBM and other providers all have their own suite of tools that do the same thing.
If all you need is access to a set of official reference documents that people don’t need to frequently edit and update or that are confidential then the best place to put these files is on your intranet – don’t refer people to copies you keep elsewhere – it’s much easier to have a simple intranet page (or set of intranet pages) and keep them logically organized and up to date than it is to create a separate storage silo.
If you need a place to store shared documents that people need to collaboratively develop and edit, or a space for working documents e.g. for an office, a particular team, for a community of practice or network, you should use a SharePoint document library.
For individual files that you want to access remotely, or where you want to collaborate on these files with a more limited or ad-hoc number of colleagues or even e4xternal partners then a cloud based storage solution such as One Drive is your easiest option.
In a cloud based solution you can:
- Access files from anywhere with an internet connection, whether at work, at home. You can also usually configure it maintain a local copy of your computer which allows you to work offline and sync with the cloud version later.
- Your stuff is available 24/7 – it’s not dependent on the IT departments servers and whether they are being maintained or if they break down, or if they get destroyed by a fire, or if someone spills coffee on them.
- You can share with more easily with colleagues and even with external partners, deciding exactly who can access the document and whether they can view or edit. This can be controlled at the level of libraries, folders or even individual documents. You can even link it to conversations about the documents through Yammer.
- Cloud based storage is comparatively cheap.
- SharePoint libraries also allow you to much better tools to organize your data including being able to add metadata attributes that are either optional or mandatory to help you sort your documents (such as document type, organizational unit, subject classification and tags). And when your stuff is in the cloud it’s also much easier to search in particular the SharePoint Search and Delve are quite powerful tools to search not only the documents you entered, but anything else that you have access to. Delve is even smarter in that it uses the “Office Graph” i.e. the set of interactions you have with colleagues and the materials you work on to help predict which materials are most relevant to you.
- SharePoint has versioning control so you can see what was changed when by whom – very useful for ensuring you have the right version of a document.
- It takes a bit more work and technical expertise, but SharePoint also allows you to program workflow i.e. to automate common work processes for working on document (such as a chain of approvals) which means you can automatically make sure a document goes through a pre-defined work process, see where it is along the way and identify any bottlenecks in getting it completed.
But if you are to move to the cloud you probably are wondering how do you migrate all the years of accumulated files to your new platform. The simple answer is DON’T. Take a copy of your hard drive and put it on DVDs or a portable drive somewhere if you are really concerned you might need it again later – otherwise only take over those files that you are currently using or have referenced in the past 6 months – or for which you know exactly what it is and what you need it for. Forget about the rest – even if they seem potentially valuable, the truth is you will never use them. I’d recommend creating an entirely new system for filing and categorizing your documents – one that makes sense for how you organize your work now with the current document types, topics, work units etc. that you are currently using and forget about how it was done before.
The step of giving up on your old shared drive and creating something completely new in the cloud (i.e. not a migration of your existing mess) is itself one of the biggest benefits of making the change. Creating something that works for you right now that you understand, control and has what you need.
As you may have noticed. I’ve not been blogging much lately – It’s hard to find the time to blog in-depth on a topic, so I’m experimenting now with much shorter blog posts in an attempt to share more often.
Appropriately enough the first topic for a short blog is the death of blogging.
I’ve been trying to encourage colleagues to blog, particularly now as UNICEF has launched its own public blog and is planning on expanding this to allow offices and departments to run their own sub-blogs under the UNICEF umbrella. This led to a colleague forwarding me this article in the NYT asking whether blogging is dead (and people have been talking about the death of blogging since at least 2009).
I’d argue blogging isn’t dead – it’s just become one among many tools for communication. I started blogging inside UNICEF back in 2006 and publicly in 2010. Back in the early days blogging was an exciting new tool that was going to allow people to share their personal views unfiltered to the world. It was something anyone could do with little technical expertise and at little expense, and it was going to revolutionize and democratize communication. When I first started blogging it was something almost a bit counter-culture and also what the cool kids were doing.
Like any new technology or tool it suffered from the Hype Cycle, in particular it rode the peak of inflated expectations. But in the meantime a lot has happened. Lots of people tried blogging and gave up because it was too much effort, or the benefit wasn’t apparent enough, or they simply lost interest. Meanwhile a few star bloggers stood out and got famous, (including a few in the aid world), and then many absorbed by the mainstream (think Perez Hilton, Lifehacker, Guido Fawkes or FiveThirtyEight which became major properties in their own right). And mainstream media and corporates also got in on the act and started producing on-message, well written, slickly designed, well promoted blogs to burnish their image – to humanize it a little bit, but still while being firmly on brand and of course these overshadowed many of the original start-up blogs. New tools emerged – first Twitter, then Tumblr, Snapchat etc. and even inside the workplace with tools like Yammer and Slack that were even simpler and quicker, and of course more suited to diminishing attention spans – now even a blog is tl;dr.
So where does this leave blogs? Is it a good idea to start a blog or even to continue blogging? It can be. Even with the decline in blogging there are still a lot of them around, and many with interesting high quality content.
If you want to start a blog to be cool and ahead of the curve, to show your counter-culture street cred., or to become famous in your field of work blogging is unlikely to be a shortcut – that time is long past.
But if you want to have a medium were you can share your ideas and your work in a first person format; one that is shorter than a book, less formal than an academic article, more personal than a news story but with more substance than a tweet or a vine, then blogging is a great medium. Writing a blog can be a great way to refine your ideas, just through the act of writing, and engaging others to get feedback on it, even with a small following. For organizations it can be a great way to personalize your work and an alternative to slick corporate messaging which can often be a turn off. It can also be a great way to get your staff and your partners to talk about their work – their successes, but also their challenges – this can increase your outreach and make it more authentic, and also can give your staff a voice.
So it’s not so strange that UNICEF is launching a blogging platform after the hype and excitement of blogging is part – it’s actually a sign that blogging is now a mainstream tool for communication, one among many tools, but a valuable one nonetheless.