There has been much written about measuring the value of online communities such as Social Networks or Communities of Practice.  However, most pundits tend to think of measuring value from a purely financial perspective, i.e. the Return on Investment (ROI).  Clearly this is an important factor, but it’s not the only factor that should be considered. Surprisingly few organisations consider the value that is being created by having better informed and more knowledgeable staff, or the potential value of getting closer to customers and local communities. These latter factors are quite difficult to measure in terms of ROI, and will normally take more than one business cycle (e.g. a financial year) before any meaningful financial measures can be made. Unfortunately – and especially in today’s financial climate – organisations plan around 1 or 2 year business years, whereas online communities will not usually be time-limited, and very rarely be driven by finance and budgets. Allowing for the relatively small cost of bandwidth and technology, conversations are – for the most part – deemed to be free.

I was pleased to see that Matt Rhodes over at Freshnetworks did refer to non-financial ROI, though I would have liked to have seen more emphasis on the value that is generated for the members of these online communities, rather than the usual social media impact measures (numbers of page hits, numbers of conversations etc.) – important as these are, and adequately illustrated in the accompanying presentation.

I have taken a slightly different approach to the issue of how the value of online communities is measured, giving more emphasis to the discovery of value rather than the dispassionate assembly of a series of metrics – financial or otherwise. I should also add that the perspective is on public sector communities since this is where I’ve been primarily engaged over the past few years. The main points are covered in a presentation I gave to the Public Health Information Network Conference earlier this year and reproduced below:

1. We need to distinguish between cost and value.

I used the humble nutmeg to illustrate this point. Weight for weight more valuable than gold in 17th century Europe. The spice was held to have powerful medicinal properties. It rocketed in price when physicians in Elizabethan London claimed that their nutmeg pomanders were the only certain cure for the plague. So, cost was very high, but the value? Well, despite the assertions of the medical experts of the day, it certainly didn’t cure the plague!

The point is reinforced by the following quotations:

I conceive that the great part of the miseries of mankind are brought upon them by false estimates they have made of the value of things.
Benjamin Franklin 1706-1790.

A cynic is a man who knows the price of everything but the value of nothing.

Oscar Wilde 1854 – 1900.

2.  We are more likely to find and create value from the communities we choose for ourselves than the communities we are compelled to join.

I have argued that one of the key characteristics of a Community of Practice is the fact that the members are self-selected, i.e. they are there because they want to be there and not because they have to be there. They may select to become members because they share the same interests, passions and goals as the other members. A successful CoP will create value for the members – either collectively in terms of working towards a common goal or objective, or personally, e.g. through self-development or sharing knowledge.

3. We are re-discovering networks and communities and through them, re-learning how to have conversations.

It’s sad fact that 20^th century working practices and pressures of modern life have led to a sense of personal isolation. Mass production, prescriptive and repetitive tasks and limited social opportunities in the workplace have created a workforce conditioned to think and act as a corporate entity, limiting individual aspirations and creative thought.  The opportunities for sharing information and knowledge have been gradually eroded over the past 50 years; social clubs have closed; people don’t have the time (or money) to regularly socialise after work; we are increasingly driven by task-oriented emails.

What is sometimes forgotten is that professional communities, where good and notable practice is shared amongst fellow artisans, are still flourishing today in the form of Worshipful Companies (over 800 in London alone), with most having existed for many hundreds of years. Communities of Practice are not new; they’ve just discovered they can exist in a virtual world. The key issue for many people though, is learning how to have on-line conversations.  The following points from one of the slides are worth re-iterating:

• We don’t know what we don’t know
• People don’t learn from content – they learn from other people.
• We don’t know the value of knowledge until it is shared
• We need to find where the conversations are happening….and join in!

And…

Dialogue is NOT:

• Discussion, deliberation, negotiation
• Committee, team, task or working group
• Majority wins, minority dominance, groupthink

Dialogue IS:

• Free-flowing exchange of ideas among equals
• All ideas are solicited and are considered
• Best ideas rise to the top

4. ROI doesn’t just mean ‘Return on Investment’

I’ve taken the liberty of using something I once heard Euan Semple say: “Keep the I small and the R will look after itself”. I think this is a good mantra because anyone worth their salt in the Social Media/Social Web world knows that implementing a social media strategy doesn’t have to cost a fortune. The days of multi-million pound corporate websites is fast diminishing, and anyone with this amount of money to spend is going to be quite rightly questioned on ROI – and they better make sure they have the answers.

I’ve given some alternative definitions for ROI, such as:

• Return on Influence
• Return on Interaction
• Return on Impact

These are the things which should be measured for value, and add a different dimension to the traditional financial measures.

5. Recognise that value to the organisation is different from value to the individual.

There is an over-emphasis on measuring value of online communities from the organisational perspective. I’ve given a (financial) example in the slides, using cost savings of online conferences as an example.  However, it is important to remember that there is also a value to the individual in being a member of an online community, and this aspect often goes unrecognised (and unmeasured). The value or benefit to a community member is quite difficult to measure (the member may not be able to articulate or recognise what knowledge they have gained from the community) and any outcomes may not be easily aligned with corporate goals (e.g. job satisfaction). It is nevertheless important to consider this dimension in any overall value measurement. Qualitative metrics can provide some answers, but it’s also useful to examine quantitative data to gain a better understanding of the community itself, e.g.:

• Number of community members
• Number of contributions
• Number of contributors
• Number of inactive users

Having a Social Network Analysis (SNA) application is even better, since this can reveal who the key ‘nodes’ are in the community chatter. It’s a useful discipline to consider what would happen to the online community if these community members decided to leave the community. Dependency on one or two ‘power’ contributors should be recognised as a risk.

The presentation concludes with a number of lessons learnt from the IDeA CoP platform , which has now been active (and by all measures, successful) for over 3 years. It’s always useful to have a distilled list of “do’s” and “don’ts”, herewith reproduced:

Do…

• ..identify and look after your facilitators – they are quite often the difference between successful and unsuccessful communities
• ..let users drive their own experimentation and use of tools.
• ..target and support areas that have a clear desire and need.
• ..build trust and relationships face to face where possible.
• ..condition your managers for failure – not every CoP is going to be successful.
• ..use online conferences and ‘Hot Seats’ to build membership growth and encourage conversations.

Don’t…

• ..think you can force people to collaborate
• ..assume everyone understands how to use  Web2.0/social media tools.
• ..assume everyone knows how to contribute.
• ..worry about the ‘lurkers’.
• ..let command, control or hierarchy hamper or kill your community
• ..set unrealistic targets

I hope this has been helpful to anyone involved with social networks or communities of practice, and particularly those who need to show that their online communities are delivering value. Just remember there is more to ROI than finance!

I’ve always thought that one of the best ways of getting a message across is to use reverse psychology, i.e. by accentuating the negatives you can highlight patterns of  irrational behaviour. This  make us realise that as rational human beings we would never do these things and we then start to think more deeply about the opposite of what we’re being told – which we’re more likely to remember.

Nick Milton over at Knoco Stories has refined this process into a fine art, with 100 ways on how to wreck organisational learning. It’s a great list of behavioural patterns, and I wonder how many people as they read through this list will admit to themselves that they are doing exactly these things, and how irrational this behaviour is if they believe they are contributing to a learning and sharing culture. I think this is a really powerful message, and have reproduced Nick’s full list below:

If you follow any of the advice in the list below, you will hinder lesson learning.

If you follow all of the advice, you need never learn a lesson again!

1. Learn only from mistakes. Why learn from success? You know you’ll never repeat it! And if you learn only from mistakes, you will associate “Lesson learning” with failure, with error, and with awkward conversations with management, which will be enough to tarnish the concept forever.

2. Don’t schedule lesson capture as part of the work cycle, just react to events in an ad hoc manner. That way you can miss many of the key lessons from projects that delivered as expected. After all, nobody minds if progress reporting or budget management is ad hoc, so why would they mind about lesson learning?

3. If you schedule the lessons capture late enough in a project, the project team will have disbanded and you won’t have to do it at all.

4. If you do have to schedule lesson capture, then don’t use an established process for this, and don’t give people any guidance on how to do it. It’s much more fun if they have to make it up for themselves.

5. For significant projects involving a large number of people, allow no more than half an hour, once a year, for lessons capture. Any more than this would just mean getting into detail.

6. If the five questions of the after action review are OK for learning from a short task, then surely they are OK for learning from a complex multi-million dollar ten-year project as well. Why complicate your learning?

7. If you are holding a lessons-capture meeting for a project, and there is a similar project is starting up soon, then you need to ensure that nobody from the similar project is invited to the meeting. They would get too excited, and so spoil the atmosphere of calm disinterested detachment.

8. Ideally, allow people to identify lessons themselves, rather than discussing them through dialogue or at a meeting. That way you will be sure to stay at the superficial level, and never capture the “deep lessons”.

9. This will definitely be the case if you give them no guidance or template; just a blank sheet of paper to fill in.

10. Don’t involve the whole team in lessons capture. In fact, why involve any of the team? The project manager or team leader can identify the lessons, and that way you can be sure to get a one sided view of things.

11. Avoid the use of a facilitator for lessons capture meetings. They would only end up challenging the team, and asking awkward questions, which would make it very difficult to avoid getting at the truth

12. At the lessons capture meeting, allow random conversation. It’s much more fun to let conversation wander rather than homing in on specific learning points.

13. If you have to interject with questions, ask closed questions in order to get minimal answers.

14. Whatever you do, don’t ask any questions about what should be done in the future. Stick with talking about the past, it’s much safer.

15. Combine your lesson capture processes with personal performance assessment, and assignment of praise and blame. This will really cause people to clam up.

16. Don’t base your lessons capture on solid performance data. Why analyse facts, when it’s much more fun to collect opinions?

17. Don’t relate your learning review to the original objectives and deliverables of the project. It’s much more fun to reinvent history.

18. Root cause analysis is just too difficult and too awkward. Stick with the superficial high level things, and you will get your meeting over with much more quickly.

19. Don’t assign any roles and responsibilities for lessons identification and capture. It’s much better if everybody thinks it somebody else’s job.

20. If you’re collecting lessons from an individual, don’t brief them in advance. Surprise them, it’s much more fun.

21. Also don’t do any preparation yourself, to familiarise yourself with the interviewee; you’ll find out about them during the interview so why bother to brief yourself beforehand.

22. Don’t record the interview. I’m sure you can write fast enough to document everything.

23. And if you have to record, don’t have a backup recorder, because those things never fail and batteries never go flat.

24. One sheet of A4 paper should be big enough to write notes a 2 hour interview.

25. Let the interviewee ramble as much as he/she likes; you can catch up on some sleep.

26. Don’t follow up on the interview by requesting additional material; they may have mentioned some crucial documents but nobody else will want to read them.

27. Evaluations and assessments should never be systematic or objective, but constructed from ad hoc opinion. I mean, who’s going to take any notice of them anyway?

28. Once you’ve collected the evaluation data, feel free to make value judgments, but avoid learning points at all costs. If the team learns enough from your evaluation to be successful, they may never need evaluations in future and you will be out of a job.

29. Don’t separate out unique single lessons; combine all your lessons from one project into a single document. That will make it really hard for people to find them in future.

30. Document your lessons at the back of individual project reports. That way people can’t find them without reading the reports from every single project.

31. And if you can hide them on the library shelf, even better.

32. Make your lessons as generic as possible. Aim For motherhood statements. Everybody loves these – they sound so wise, but teach you so little.

33. Use fuzzy phrases like “do it better” or “do it earlier” rather than actually giving specific advice. The reader of the lesson will be thoroughly confused.

34. Don’t give lessons any consistent structure, it makes them too easy to follow.

35. Lessons should be supplied devoid of context, making it an exciting intellectual exercise for the reader to see whether it’s applicable to him or her.

36. Unless, of course, it is a very simple lesson that can be explained in a diagram a photograph, or a few lines of text. In this case, you may want to write a 50-page article.

37. In fact the best way to record lessons is as bullet point phrases. Aim for three words or less. A lesson such as “Improved contracting process” is so terse and economical, it’s almost like a haiku or a Zen koan. Something to meditate on.

38. Alternatively, instead of lessons, why not just write a little history of what happened with no moral, no conclusion, and no learning points? Leave it up to the reader to try to guess what they should do as a result

39. Even better, just tell a pointless story with no message. People will enjoy listening, and go away none the wiser.

40. When writing your lessons, it’s best not to have a particular reader in mind. It may be an engineering lesson, but perhaps an Archbishop or a ballet dancer may want to read it one day, so avoid using engineering language, and avoid explaining it in ways that an engineer can follow.

41. In fact, it’s best to make your lessons as difficult to follow as possible. If people spent all their time learning from your lessons, you would deprive them of the excitement of having to make the mistakes all over again.

42. Don’t write down the originator of the lesson, the date of the event, or the value of the lesson. That would just make it far too easy for people to know which lessons were important and recent, and who to go to for more information.

43. If a picture tells 1000 words, then why not just write 1000 words rather than attaching a picture to your lesson?

44. Never under any circumstances set up a system of quality assurance for identified lessons; this would put the “garbage in garbage out” principle at grave risk.

45. Never assign actions to lessons, it spoils the chance for the organisation to learn the lessons all over again. And again. And again. Actions just lead to change, change leads to improvement, and improvements threaten our comfortable mediocrity.

46. If there are any actions, they should only ever be of one sort; “circulate this lesson for information”. Certainly don’t require anybody to change anything.

47. You can avoid having to change things if you don’t make anybody accountable for the actions.

48. You can postpone change indefinitely if the actions have no closure date.

49. Any actions should be assigned by the most junior person present, especially if they are difficult or contentious actions. This will make them much easier to ignore, and much harder for people to treat them seriously.

50. You can avoid much of the risk of learning if your organization has no process owners for the major processes. If nobody owns any of the processes, then nobody can change them, and they will stay as inefficient as they have always been.

51. If there are process owners, then keep their job description as vague as possible and make sure it includes nothing about updating or improving the processes, as this would give them far too much work to do.

52. Process owners should have no expertise in the topic, should not be members of any community of practice, and should have no technical authority.

53. As a process matures, it’s important to keep the same process owner. It makes sense for completely mature processes to be owned by research and development, seeing as they probably invented them in the first place.

54. If you can disengage the process owner from the lessons learning cycle, then with any luck they will never be notified of the lessons in the first place. Certainly avoid any workflow which might push lessons (and work) their way.

55. See if you can avoid a validation step for lessons. I am sure every suggested change is equally valid, and if you spend enough time on trivia, the important lessons may be lost.

56. Avoid Management of Change procedures as well. Live dangerously – change your processes on a whim, and hang the consequence.

57. All process documents should be given equal weight. See if people can work out for themselves whether they are a mandatory company standard, or somebody’s bright idea.

58. Much fun can be had in choosing how to document a process or best practice. Simple principles like giving the reader all of the detail all at once, with no logical structure, with no context or high level summary, in dense text, with no pictures, audio or video, can create masterpieces of incomprehensibility.

59. Then store your process guides and best practices somewhere that the user will not find them. Give them misleading names, and hide them in an obscure branch of the folder structure on a remote file server. After all, everybody likes a game of hide and seek, especially when they are urgently searching for useful lessons.

60. Don’t date your documents – let people try and guess which is the most recent version.

61. Don’t tell anybody when processes have been updated, this would spoil the surprise.

62. If you have a blog at work, this is a great way of telling people about your holiday, and sharing the latest jokes. It would be far too boring to use it for sharing lessons and process updates.

63. The same is true for newsletters. They should only be used for staff announcements, and pictures from the Christmas party.

64. The training department have got their own budgets and their own staff – let them work out what has changed and what hasn’t. It’s not your job to make sure that training reflects the most recent lessons.

65. It’s best to avoid any review of lessons at the start of a piece of work. Just jump straight in and make it up as you go along. You will need the time later on, for coping with all the repeat mistakes that you will inevitably make.

66. A company lessons database is a complete waste of money. Why spend 10 minutes searching a database at your desk, when you could spend a leisurely 2 hours in the library (and still not find the lessons that you know are there somewhere).

67. If you are forced to invest in a database, then certainly don’t spend any time developing a taxonomy. Just file the lessons any way you want. Filing them by the last letter of the project managers surname is quite an interesting approach.

68. The lessons input form for the database should be just one single text box, to allow the maximum of free form creativity, and to eliminate any opportunities for tiresome sorting and searching.

69. In fact, why not eliminate the functionalities for sorting and searching?

70. And don’t introduce any push functionality, as it would embarrass the process owner to be notified of new lessons.

71. A knowledge library is a very bad idea, making it far too easy for people to find things. In my day we had to search through piles of reports to find everything, why should kids nowadays have it any easier? So no portals please.

72. And no search either, thank you very much.

73. As for wikis, I can see no reason why anybody should be allowed to comment on documents, processes or best practices. You lot out there should be applying the processes, not commenting on them, so just get on with your work.

74. Having completely sabotaged the formal lesson learning system, we really don’t want people to run any risk of identifying lessons informally. Therefore all attempts at setting of communities of practice should be avoided.

75. Any communities to do exist should not be provided with any way of finding each other, of asking questions, of storing knowledge, or of meeting or discussing anything. Give them the bare minimum of tools.

76. The community leader role should be given to the most autocratic technical expert. He or she can be relied upon to rule the community with an iron fist.

77. Choose communities to cover topics which nobody identifies with. Choose topics which people do rarely, and don’t like doing. An Income Tax Return community of practice, for example, will be inactive for most of the year and then spend a
couple of weeks complaining and grumbling together.

78. It’s best if your communities are very small. Big communities are too useful and contain too much knowledge. 20 people should be your upper limit.

79. If you can disempower your community, so much the better. There is no risk in them sharing lessons with each other, if they are not empowered to use the lessons they find.

80. Try and avoid giving your project staff the opportunity to learn from others at the start of their project. Processes such as peer assist give a project an unfair advantage, and should be discouraged.

81. If, by some mistake, a peer assist is scheduled, then make sure its objectives are unclear, that its focus is on criticism and critique, that it is attended only by managers who are senior enough to be scary, and that you have no facilitator.

82. Similarly avoid giving your project staff the opportunity to pass lessons on to subsequent projects. Processes such as baton passing and knowledge handover are also unfair, giving the subsequent projects a much greater chance of succeeding. Why should they be given an advantage? Why shouldn’t they start from a position of ignorance just like the rest of us had to? Failure is good for you.

83. You can clamp down on ad hoc learning by careful design of your surroundings. Give people individual offices, it gives them a great excuse not to interact.

84. Remove any communal areas. People can drink coffee at their desks, with door securely shut.

85. Remove any yellow pages, telephone directories, or any other temptation for people to call others and ask for their lessons.

86. Clampdown on any online conversation or social software. People are not paid to talk to each other, they are paid to sit there and work, so make sure they have no distractions.

87. There is a lot you can do to discourage lesson learning with the help of senior management. They can start by making their expectations for lesson learning very unclear. If nobody is clear what they should be doing, then most of the time they will do nothing.

88. You can set the expectation for lesson-learning too high, or too low. For example, ask a busy project to spend half an hour every day discussing and identifying lessons. Alternatively, require your most major projects to identify lessons only at the end of the project, no matter how many years they take.

89. Even if a senior management have set expectations, they can undermine these by not taking them seriously. Make sure they allow projects to continue without having done required learning, or allow projects to close without having identified their lessons.

90. Ask them to set priorities that over-rule lesson learning. People will soon realise a Retrospect is not valued, if it is consistently postponed to make room for another slide presentation to the chairman’s sister.

91. If senior managers are required to take part in any lesson identification meeting or process, ask them to decline.

92. There should be no clear chains of accountability for learning, neither within the business delivery organisation, nor within the supporting functions. This would just make it too easy for people to know what to do.

93. Never describe your learning system in simple terms. Don’t call it “learning lessons”, call it “quasi-experiential pedagogy”. Call it “knowledge gardening”. Call it “Enterprise 3.5”. Confuse people! They love a good buzzword!

94. If there is a central support team for lesson learning, disband it immediately. If nobody supports learning, they will gradually fade away over time.

95. As well as disbanding the support team, cancel any training for lesson identification and learning. We can’t have people who are actually skilled in the technologies and processes, just in case they manage to sneak a lesson through the system.

96. In fact, don’t have any training or awareness or roll-out for your learning approach. People will finder it harder to get value if they don’t understand the complete learning cycle.

97. Don’t monitor or measure learning activities. If it’s not measured, it can’t be managed, and if people know they are not monitored, they will take short cuts, or avoid learning entirely.

98. Even if you do monitor and measure, then for heaven’s sake don’t link this to any performance management incentives, or to any rewards for recognition. If people know they can avoid lesson-learning activity with no penalty, they spend their time doing other things they are actually rewarded for.

99. Learning metrics need to be kept secret. If senior management saw them, the people who aren’t complying with the learning expectations might get embarrassed.

100. If you want to reward people, then reward them for putting lessons into the lessons database. Pay them for each lesson. That way they will know that lesson learning is not part of normal paid work, but has to be incentivised separately. Also you will swamp the database with poor quality lessons, and when the reward is eventually removed, lessons identification will stop completely.

So, how well did you score on this list!

This is the first opportunity I’ve had to write anything about the Knowledge Hub (Khub) Advisory Group meeting that took place last week (17^th September) in London – though a number of my colleagues have been pretty active in the blogosphere and twitterverse on the topic. In particular I found Ingrid Khoeler’s post pretty much spot on and wondered if indeed if I had anything more to say on the topic. Well, clearly yes, because I’ve started this post!

Maybe I should start by giving some background to this project. I think the story starts in summer 2005 when I was contracted by the Improvement & Development Agency (IDeA) to develop a three year knowledge management strategy. Though it’s only 4 years ago, much has changed on the KM landscape since then, not least of which is the development of Web 2.0 tools and techniques to support knowledge sharing. However, I distinctly recall that this was deemed a high risk strategy when I raised the concept of developing a Web 2.0 platform that would support communities of practice (CoPs) working in local government, and switching emphasis from publishing (i.e. broadcasting) information on cases studies and best practice to connecting people who have the same goals or same issues, such that they can collectively solve problems and share learning with other practitioners working in the sector. I should also add that the term ‘Web 2.0’ was not even invented when we started this programme; it is accredited to Tim O’Reilly who used the term for the first time later that year.

Winding the clock forward 4 years it is easy to forget how incredibly difficult it was to get this project off the ground and in particular getting to a point where there were sufficient number of users and communities to ensure the strategy was self-sustaining. With over 35,000 users and more than 900 CoPs, I think we’ve achieved this, and the CoP platform has gone on to win a number of industry awards for encouraging team working and knowledge sharing in local government. However it will come as no surprise to KM professionals working in this space to know that the technology was the easiest bit; establishing trusted communities and developing new ways of working is where the real effort was required.

I was almost caught by surprise when I was asked ‘what next?’ when the anniversary of the 3-year strategy came around in 2008. I struggled with this question for some time, and spent an uncomfortable winter of 2008/9 coming up with a strategy for the ‘next 3 years’. However, I did eventually present a strategy paper to the IDeA KM Steering Group in February 2009 which described the idea of a ‘Knowledge Hub’. The concept is largely based on personal experience as a KM practitioner in trying to keep up to date with new ideas and good practice. This entailed belonging to many different professional networks, both on-line and off-line, active use of social bookmarking and development of many different types of lenses and filters – such as RSS feed aggregators and personalised dashboards – in order to make some sense of the growing mass of information that was available. In essence, picking out the conversations that add value from the background noise.

Reflecting on the tools and techniques I used, I realised that though the ‘Web 2.0’ landscape has made it far easier to connect with people and share knowledge, it has also created its own complexities. I don’t think a day goes by where I don’t get invited to join another social network. Standards such as Open Social do help in creating the links between the community platforms that adopt this standard, but we’re still a long way from having one ubiquitous standard that all vendors are happy to support  – and maybe this is utopia.

In developing the ‘next 3 years’ strategy it was also helpful to look at what had worked and what hadn’t with the IDeA CoP platform. Interestingly (and this is where I often wish I’d taken a degree in anthropology or sociology) most communities were being set up as private spaces, and there was little evidence of inter-community knowledge sharing. It was as if we’d created a platform which encouraged silos of knowledge to develop. And, with the exception of the IDeA-sponsored CoPs, it was very difficult to solicit information on how successful these closed and private CoPs were in achieving their goals. This has been partly addressed by having a ‘Community Hub’, an enhancement to the CoP platform that went live in October 2008 which encourages CoP members to publish what they are doing in a common community space visible to all users of the platform.

So, we come to the ‘Knowledge Hub’. What is it? How will it overcome silo’d knowledge repositories? How will it help users to connect and share knowledge more effectively? How will it help to improve local government services? Quite simply, it will support more effective decision making by making it far easier for users to filter, share and access the information that is most relevant to them, using personal profile data and activity streams to improve relevance. We’re all familiar with commercial websites such as Amazon which give us information about ‘customers who purchased this also purchased…’, and reviews from customers on how good/bad a product is, so why not reuse and adapt these techniques for professional networking platforms? Again, Amazon were doing this long before the term Web 2.0 was bandied around, yet they are one of the best exponents of Web2.0 technology to engage with and better understand their customers. So, we’re not really doing anything new with the Knowledge Hub, other than applying these tools and techniques to a professional network of local government staff.

The Khub will support social computing and adopt open standards that enable connections to be made between personal and professional networks.

It will be a vantage point and visualisation tool, providing ‘heat maps’ showing emerging trends and ideas.  It will have a serendipity engine which enables new topics and ‘hot’ conversations to bubble up to the top.

Content sources will include Twitter feeds – e.g. from local councils, Blogs, RSS feeds from council websites and other public, private and third sector organisations involved in public services. It will have access to publicly available datasets and enable mashups between different data sources to be created for value-added services.  For example, overlaying data on knife crime with socio-demographic data, displayed against Google Maps to indicate ‘hot spots’ or where local authority initiatives have had most impact.

It will be an open platform where APIs can be used for developing value-added services. Widgets and plug-ins can be developed for users to easily customise and personalise their interface to the system, e.g. using iGoogle,  Netvibes or iPhones.

It will support benchmarking and data visualisation tools that enable councils to compare and contrast services in order to identify lines of inquiry that may lead to greater efficiency savings (see post by Ingrid on the Efficiency Exchange).

It’s also a big, bold and ambitious project with many stakeholders, and particularly the department for Communities and Local Government (CLG) who are funding the project.

It is therefore extremely important that we have an empowered and ‘expert’ Advisory Group, drawn from a cohort of freelance and independent social innovators who are currently delivering collaborative solutions to the public sector, together with stakeholders from central government and social media early adopters working in councils and local communities. The Group will help shape the project over the coming months, and help in identifying the training and support that may be needed in local authorities in order to ensure its success.

As I mentioned earlier, this is a 3-year strategy, but at least now the journey is now underway!

Check out the slides below to get a better perspective of what this all about or contact me if you need any more information.  See also Dave Briggs post on The Partnerships and Places Library prototype – which is one of the discreet projects that will feed into the development of the Knowledge Hub. There’s a lot happening out there!

If you want to follow the conversations around this topic, then sign-in or join the FriendFeed ‘room’.

I’ve was pleased to be invited to do a keynote presentation at the NHS eSpace Coordinators conference earlier this month.  I wanted to emphasise the importance of the Coordinator’s role in building trust within a Community of Practice (CoP), and as a catalyst for turning conversations into active collaboration.  I should note that I’m more familiar the term ‘Community Facilitator’, for this role, and have used the term ‘facilitator’ and ‘coordinator’ to mean the same thing, i.e. the person or people who support, manage and guide the CoP members in achieving their goals. Perhaps a better description for this role is ‘community cultivators’,  since it is they who provide the conditions for the CoP to grow and flourish.

I can’t over-emphasise enough the importance of this role and the people who perform it. The difference between a vibrant and successful CoP and one that meanders aimlessly with little or no contributions is down to the facilitator (or coordinator, moderator, cultivator). Members of the CoP have been sufficiently motivated to join the CoP; it is up to the facilitator to inspire the members to connect, collaborate and co-create.  I tip my hat to all of those who do this successfully, and quite often without due recognition or reward. Something I hope will change as more and more organisations are turning to this way of working and have realised that technology alone does not provide a successful learning and sharing environment.

I’d be interested to hear from anyone who is willing to share examples of how active facilitation (e.g. guided learning) has helped their CoP, and/or what makes a successful Facilitator.

The slides are available for download from Slideshare, and reproduced below:

How and why should local authorities and Government be planning to exploit the collaborative features of Web 2.0? This article was originally published in IT Adviser late last year.

Web 2 in Local Government


Ingrid Koehler over at the Policy and Performance blog writes about how Web 2.0 is being used to support improvement initiatives in the local government sector, and in particular the positioning of (virtual) communities of practice for engaging with staff across the sector. This point is also emphasised by John Hayes, Director of Services at the IDeA.

A tangible example of the power of Web 2.0 for networking, collaboration and consultation will be evident in the forthcoming Customer Insight Online Conference, scheduled to run from 10th to 20th June 2008. What is an online conference? To quote:

An online conference, just like a ‘real life’ conference, is about getting people together to discuss a common interest and learn from each other. There are speakers, participants, panelists and discussions. It just takes place in an online platform and over a longer period of time, allowing people to dip in and out.

It’s greener – saving all that travel and paper, less expensive and many people find it more convenient and easier to engage with. The proceedings of this conference will be distilled into a learning report for practitioners and policy makers.

There will be a wealth of useful learning and an opportunity to chat with a range of colleagues through the medium of online discussion, video, photos and more. You do not have to be a technical wizard to join in. The conference platform is easy to use and throughout the two week period, we will send you regular round-ups to support your engagement and help you direct your own participation for maximum benefit.

If this is of interest to you, you’ll need to sign up for the event using the online registration form on the Communities of Practice website.

I highly recommend the recently published white paper – “Building a collaborative workspace” – by Shawn Callahan, Mark Shenck and Nancy White. The paper goes some way to redressing the balance between Web 2.0 technology solutions and the skills, processes and techniques required to ensure the technology is used effectively. I’ve blogged on this topic previously (It’s not the technology…its the people that matter), but I think the issue is very elegantly summarised by the authors of this paper as follows:-

“Today we all need to be collaboration superstars. The trouble is, collaboration is a skill and set of practices we are rarely taught. It’s something we learn on the job in a hit-or-miss fashion. Some people are naturals at it, but most of us are clueless.

Our challenge doesn’t stop there. An organisation’s ability to support collaboration is highly dependent on its own organisational culture. Some cultures foster collaboration while others stop it dead in its tracks.

To make matters worse, technology providers have convinced many organisations that they only need to purchase collaboration software to foster collaboration. There are many large organisations that have bought enterprise licences for products like IBM’s Collaboration Suite or Microsoft’s Solutions for Collaboration who are not getting good value for money, simply because people don’t know how to collaborate effectively or because their culture works against collaboration.Of course technology plays an important role in effective collaboration. We are not anti-technology. Rather we want to help redress the balance and shift the emphasis from merely thinking about collaboration technology to thinking about collaboration skills, practices, technology and supporting culture. Technology makes things possible; people collaborating makes it happen.

This paper has three parts. We start by briefly exploring what we mean by collaboration and why organisations and individuals should build their collaboration capability. Then, based on that understanding, we lay out a series of steps for developing a collaboration capability. We finish the paper with a simple test of your current collaboration capability.”

I think you’ll find this a very useful resource in this period of “Web 2.0 hype” by the leading technology vendors.