chieftech’s blog

What is Government 2.0 all about? And how can Knowledge Management help staff in government agencies to meet its objectives?

The Federal Government sponsored Government 2.0 Taskforce presented its final report at the end of 2009 - see http://www.finance.gov.au/publications/gov20taskforcereport/index.html

As part of the Taskforce's consultation process, they commissioned the creation of Online Engagement Guidelines and a Web 2.0 Toolkit. This was designed to provide guidance to government agencies using web 2.0 tools and provided a recommendation for a toolkit of web 2.0 technologies that agencies can use based on principles of shared services and re-use.

James Dellow will provide a briefing on:
* The Government 2.0 Taskforce
* An overview of the new Online Engagement Guidelines and Web 2.0 Toolkit
* How you can make use of it
* How your Knowledge Management skills and practices can contribute to enabling Government 2.0

James will then facilitate an open discussion on the topic, using a conversation cafe style format.

Thanks to the ACT KM community and Brad Hinton at AusAID, I'm taking advantage of the fact that I'm down in Canberra this weekend for BarCamp Canberra by running this session tomorrow (Friday) about Government 2.0, with a focus on the Online Engagement Guidelines I helped to write for Taskforce Project 8.

Five great tips from the Atlassian guys on how to get the most from your Confluence wiki's Personal Space:

1. Manage Personal Files
2. Start a Personal Blog
3. Share what you're working on
4. Show that you're an expert
5. Show that you're a person

These tips actually have pretty broad application to just about any enterprise social computing platform that supports some kind of profile or personal space, however I think there are some particular Confluence features that are worth bearing in mind:

• Every change you make to your personal space is part of the overall tagged (and secure) activity stream of Confluence, so your personal space isn't another silo; and
• You can attach documents and other files to your personal space and use macros to pull content from elsewhere across Confluence (and beyond) - so its more than just a "profile" page.

I’m finding that some Communities of Practice (CoPs) at work are lacking leadership even though they have a community leader.

This is a broad statement, and there can be many reasons for this, but in this post I want to focus on one particular reason.

This has happened on several CoPs where the team leader has appointed their personal assistant or a nominated team member to set up a CoP…or the team leader has borrowed a person from another team leader as they like how they designed their CoP.
NOTE: Personally I would be inspired by CoPs with active and frequent conversation, over a well designed website.

The reason for their approach is that the community leader is technically proficient at designing and using the CoPs. The problem is that this person is not a Subject Matter Expert (SME), and does not have the interest, passion or time to facilitate the community in a non-technical way.

Facilitation is not just technical design/support, part of it is monitoring how people use

John's observations at work also reflect my experiences. Getting the balance right between CoP leadership and technical facilitation skills can be difficult to get right in one person. Unfortunately, in some online communities or communities that involve some element of online or computer mediated communication it can be difficult to separate out the technical facilitation entirely.

In a past role, to help deal with this issue I came up with a model that divided the world into CoP leadership behaviours (and skills) that were non-negotiable and other activities that could be delegated. This was designed to make it clear to CoP leaders what exactly was expected of them by us and also their community. It also allowed me to design appropriate systems, policies and training to support them.

However, I'm not going to give you a dot point list - these leadership behaviours and delegated activities were designed specifically for that situation, based on feedback, surveys and other analysis of the CoPs in that organisation. In another organisation, these leadership behaviours and delegated activities would be different.

Incidentally, John's point that he "would be inspired by CoPs with active and frequent conversation, over a well designed website." was an issue that came up during our investigation. It was critical that we could tell that story based on feedback from community members as part of the process of refocusing CoP activities where they actually counted, rather than simply our (educated) opinion.

Well known for his thoughtful analysis (and pretty diagrams) about the two dot oh domain, Dion Hinchcliffe has proposed 14 reasons why Enterprise 2.0 projects fail:

1. It starts strong in a single department and then never makes it out;
2. Selecting the tools first;
3. Selecting the wrong tools and sticking with them;
4. There are no resources allocated to adoption and training;
5. It’s purely an IT initiative;
6. The effort excludes IT;
7. Engaging with HR, legal, branding, compliance, etc. too soon;
8. Pushing Enterprise 2.0 as a generic toolbox instead of the solution to specific problems;
9. Lack of effective executive champions;
10. Lack of effective participants: Empty blogs, wikis, or silent social networks;
11. No long term plan or budget for governance, community management, upgrades, or maintenance;
12. Failure to draw in key influencers as adoption broadens;
13. Building it all as a self-contained, top-down effort; and
14. Not waiting long enough to let critical mass build.

I’ve read through this list a few times now, trying to tease out some new or special factor that is specific to Enterprise 2.0 projects, but I just can’t see it. While these issues might be considered uncommon in certain types of IT projects, they are very common in projects that affect the areas of individual work practices that people have discretion over. We have seen these problems for years - but now the label has changed from “knowledge management” or “collaboration” to “Enterprise 2.0”.

Unfortunately many companies have a bad track record in how they have introduced groupware and collaboration tools in the past - social computing technology alone is unlikely to change that (and hence the Enterprise 2.0 technology and culture debate, although its more than just culture too).

I looked at Social Software back in 2005 for a NSW KM Forum presentation and commented then on the difference between old groupware and collaboration solutions with social software (see slide 6). I think it is important to consider what has changed:

• The technologies of Enterprise 2.0 exhibit different characteristics from those we had in the past; and
• In addition, there is growing population of workers who are familiar with these technologies based on their experiences of using the Web.

If we understand this, then we have a chance to avoid past mistakes. In my view there are four key rules of thumb for avoiding Enterprise 2.0 project failure:

• Use real social computing platforms - because they are more cost effective, offer flexibility, have ‘social’ built-in, and are user-driven;
• Take an abundance approach to the technology - the traditional model of IT is a scarcity mindset that tries to avoid wastage (failure is a wastage), but an abundance approach will allow you to grow organically and support experimentation.
• Put the ‘users’ in the driving seat - this really is the point of Enterprise 2.0 and if you have already followed the first two rules of thumb, you should have the tools that let you do this.
• Tap into your pool of early adopters - getting momentum quickly is always important, but you can use the fact that some people in your organisation may already be ‘Enterprise 2.0 ready’.

Mix these up with Dion’s list and we might start to get somewhere with understanding why Enterprise 2.0 projects might fail.

Last week I spoke with two organizations who had “KM problems”.  In both cases they found that associates were not filling out all the information into their system of record.  What resulted was an inability to look back at older cases and extract “knowledge” about the process to help train new associates.  It’s a common problem — associates were never motivated to fill out forms and stuff SharePoint with documents.  They were motivated to bring open cases to closure efficiently. Their respective approaches to the problem was to get new tools or to figure out new ways to mandate compliance.  I told both companies that their approach will not work and I explained why.

...It’s somewhat obvious to me when I  see the problem from the outside.  But one of my clients could not understand why a management edict in the form of “Thou shalt upload all documents to SharePoint in a timely manner” would not work.

Gil was actually blogging about a TEDxBoston presentation - so go read (and watch) that for the context of this quote. However, the point he makes above I like to simplify into what I call the WIIFM ("What's In It For Me?") gap. Its critical to examine this point from all levels in an organisation - corporately, through the management levels and finally the individuals involved. This is a three way gap between what the organisation wants as a whole, what the departments or internal groups involved want and what the individuals who will be affected want.

This perspective actually dove tails neatly into a couple of different change management models I use, one based on innovation theory and another based more pragmatically on addressing sponsorship 'holes' in the organisational structure.

Most of us have built and reviewed and rebuilt intranets using Waterfall project methodologies. It’s the process of understanding all of the requirements and risks first, developing specifications to describe them, and then implementing the solution. Using this approach, however, typically results in late and over budget intranets. This is because intranet projects are often plagued with changing requirements, unanticipated integration challenges, and usability annoyances that are difficult to accommodate in the fixed scope of the project

I can't tell you how strongly I agree with the recommendations here - its one of the reasons I've been a fan of the MIKE 2.0 methodology, to help break that waterfall approach failure cycle with not just intranets projects but any kind of information management, knowledge management or collaboration system implementation.
BTW I couldn't find the original article, so hat tip to Matthew Hodgson for sharing it.