A Shift in Thinking on Enterprise Wikis

Whenever I explain why someone should use a wiki I usually come back to this graphic created by NASA:


Wikis, according to NASA, are designed (or at least deployed) to help mitigate the problems associated with document coordination via email. Whenever I show people this image, they immediately identify with the problems associated with document coordination and coauthoring via email.

Herein lies my question: if wikis are meant to help mitigate the email problem, why is it that when it comes to policy compliance we treat them like websites and not like email?


Because they’re web-based?

True, wikis are web based. But then again, so is email. In my opinion, what we are really talking about here is browser based versus client-based communication; think MediaWiki versus Outlook. This is most likely a nuance that is lost on many, taken for granted or considered unimportant. But the more I think about this, the more I think that these small differences are playing out in some major ways.


My Hunch on Policy

I have a hunch that many of the problems with deploying enterprise wikis are linked to the fact that we have trouble with them from both a policy and a cultural perspective because we try to treat them more like an intranet than like email. From a policy standpoint, we look at wikis and think about all of the interrelated policy frameworks (e.g. Official Languages Act; Access to Information Act; Privacy Act; Policy on Information Management; etc) and how they apply to government websites. I can see why we have gravitated in that direction, but have a feeling that it may be hindering adoption in a significant way. I would argue that public servants already understand their policy obligations when communicating via email. The only evidence I offer is the fact that email essentially runs the enterprise, and has for quite some time now.

Explaining wikis as websites that anyone can edit (standard practice, of which I am guilty) rather than a means of complementing email means that public servants are no longer familiar with their policy obligations. I’ve written on this matter before – about how push-button publication is changing the relationship between accountability and responsibility – but only connected the dots recently.


Why we might want to shift our thinking

Thinking about wikis as websites is creating confusion and complication, it disconnects us with what we are familiar with (email) and puts many outside of their comfort zone. We may overcome some of the barriers to adoption by refocusing on the fact that wikis can compliment email, and thus can be governed by a similar set of rules and norms. We look at email and understand how we craft it depends on the circumstances: intent, publisher, audience and the corporate (or non corporate) nature of the communication, etc. If we simply applied the same logic we might have higher levels of comfort around the use of wikis within the enterprise.


Wikis aren't new, they are new to government

I know I sound like a broken record when I bring it back to Clay Shirky’s statement about the transformative nature of technology, but I think it is incredibly important:

"These tools don't get socially interesting until they get technologically boring. It isn't when the shiny new tools show up that their uses start permeating society. It's when everybody is able to take them for granted. Because now that media is increasingly social, innovation can happen anywhere that people can take for granted the idea that we're all in this together." – Clay Shirky, TED Talk

Dulling the Luster

Perhaps giving everyone in the enterprise “control over their own website” is simply far too interesting, while extending their (boring) old email system is far less so. Moving forward I’m considering purposely dulling the shine of enterprise wikis by explaining them more like this:

“Think of wikis as just an extension of email. They make it easier to circulate those enormous attachments or collate people’s input on a document. All in all they aren’t so much shiny, new or interesting as they are ruthlessly utilitarian.”

The Changing Relationship Between Accountability and Responsibility

Collaborative technologies apply flattening pressure to hierarchical organizational structures by diffusing the ability to publish, share and disseminate information. For example consider the action of publishing something to the corporate intranet compared to an enterprise wiki.


Intranet Publishing is a Linear Process

This linear process is designed to ensure compliance with a broad set of interrelated policy frameworks, such as official languages, access to information and privacy, information management directives, values and ethics, etc. It does so by making people along the chain responsible for formally approving the content. These people are gatekeepers, key decision making nodes along the pipeline. While this type of system may ultimately produce compliance, it does so at the cost of expediency and thus perhaps even relevancy. In short, when it comes to internal communication models, many hands don’t always make light work, sometimes they make long work.


Wikis are Different (or at least they can be)

In an open enterprise wiki environment, publishing is unfettered. It can be instantly achieved by anyone in the organization. This means that formalized structures (e.g. linear approval processes) are incredibly difficult to maintain. Since there is no formal chain of command that ensures policy compliance, there are no nodes of decision-making that act as gatekeepers. In this model publishers are not only responsible for production but for policy-compliant production. In short, wikis make for quick publication but at the cost of ensured policy compliance.


How Does This Affect the Relationship Between Accountability And Responsibility?

In an enterprise wiki, publishers may have new found responsibility but the traditional accountability chain (i.e. the hierarchy) remains intact. I can't say for certain what the exact impact of this is on the organization other than it is largely seen as an erosion of power of gatekeepers. Gatekeepers rely on the bureaucratic tradition of:

Power = Knowledge

Where:

Knowledge = Position within the hierarchy x # of direct reports x Information / relative importance vis-a-vis other areas

The reason this equation works is simple: the information/action/work must be routed through the established process. The minute that process changes, say by implementing an enterprise wiki in parallel to a corporate intranet, the power structure implodes. Ask anyone working in these spaces right now and they will tell you that corporate intranets are losing ground quickly to enterprise wikis.


These will be difficult times

This shift – enabled by changes to the relationship between responsibility and accountability – is playing out in the culture right now. It is creating confusion inside organizations, people are unsure where to put information, where to find it, and in some cases which source of competing information is the most accurate.

The underlying question isn't really whether or not we should replace our intranets with wikis but rather what type of culture do we want our institutions to support? The reason there is so much tension around these issues is that the institution isn't designed to work in the ways that new collaborative technologies now enable us to.

We are slowly moving into a way of working, a way of thinking – perhaps even a way of being – that is not conducive with our way of managing, how we create incentives and/or how we create disincentives.

Maybe it is time for a redesign.


[Image credit: chelseagirl]

Column: Public Sector Wikis and How to Use Them

I'll be honest. I'm frustrated.

I'm frustrated that people still question the value of an enterprise-wide wiki like GCPEDIA. after all no one seems to question the value of Intellipedia.

Before I continue, I want to be clear: I'm not frustrated at those asking the question, but with those who are supposed to be providing the answers, myself included.

By now we should have been able to explain the value of GCPEDIA with such clarity as to render any question at this point moot.


The reason we haven't been able to deliver that explanation thus far?

No clear business objective.

Sure there are pockets of collaboration, collective authorship, small victories, piecemeal information sharing and crowd-sourcing, but all without an overall purpose baked in. The result of which has been a value proposition based on serendipitous discovery of others or information and reliance on organic growth.

But therein lies the problem - serendipity is deeply connected to the size of the community and the amount of information they collectively contribute; and organic growth has a low ceiling in hierarchical super structures.

I'm not advocating that we eliminate or somehow reel in the often messy and under-the-radar collaboration that GCPEDIA allows, but rather supplement it with a set of pages that delivers some real business value to the traditional hierarchy.


Easier said than done?

For anyone looking to use a wiki in the public sector I offer you two concrete business uses that, in tandem are sure to fundamentally change the nature of how your organization does business:

1. organizational briefing "books"
2. real time dashboards

Briefing Books

Every department/agency produces massive tomes known as briefing books. Briefing books are usually coordinated and produced in a senior office, one level below the top rung. These books include information on everything the department/agency does: history, mandate, relevant legislation, hot issues, internal corporate services, budget, etc. They are used to brief new department heads and new Ministers when they arrive. As someone who has coordinated them (by email and/or diskette based on security level!) I know first hand how much of a logistical headache they can be. People frequently fail to use the appropriate template; have trouble with version control; and need to make small adjustments based on the feedback of senior management.

Moreover, I know how valuable of a set of documents they are NOT to be shared openly throughout the organization. Generally speaking briefing books are costly to produce in both time and materials; are only distributed to Directors General and above; and are rarely shared with working-level staff.

It is no surprise that my opinion is that briefing books are a perfect fit for a wiki. Instead of trying to coordinate input via email when a cabinet shuffle is rumoured (been there, done that) we could simply assign pages to the responsible areas and have them update pages as new information becomes available. At its core this is the difference between proactive and reactive organizations.

Would you be surprised if I told you I tried to advance this proposition over two years ago? I was told it couldn't be done because "briefing books are secret". After some digging I learned that everything in briefing books is information that is widely available except for the policy advice to Ministers. In my experience the policy advice contained in briefing books is usually no more than 2-3 lines per hot issue. This translates into roughly 1-2 printed pages and less than 1% of the total material in the book.


Dashboards

Wiki based dashboards are an incredibly powerful tool built on a relatively simple concept: present very high level information about what people are working on from across the department in a single place that allows you to better coordinate your department/agency's efforts. I first came across wiki dashboards when looking into the work done in Natural Resources Canada over a year ago. Since then I have developed a policy dashboard for my department (internal link) and have created a template (internal link) that allows others to create their own dashboards with very little trouble.

Dashboards provide what the Government of Canada Employees Directory (GEDS) lacks: a window into what people are currently working on. The dashboard is a space where you can see an entire directorate list of all of the projects currently in progress under their purview, along with live links to contact people who are working on them via email.

Proactive disclosure of information via the dashboard ensures that people know what others are working on. One of the biggest problems in the public sector is a lack of clarity about roles and responsibilities, the coordination problems it entails and the drain on productivity it creates. Dashboards mitigate these problems extremely well by sharing valuable information in a concise manner. Moreover once dashboards are in place, users can create a live hyperlink in the dashboard to the actual work they are doing, thus providing a deeper level of detail into their work than the dashboard itself can offer.


Other benefits I didn't even mention ...

• Search-ability
• Cross linking between related pages/dashboards
• Portability (briefing books can be over 200 pages and GEDS doesn't say what people work on)
• Notification of updates to pages via email

Squandering Success

Think about how powerful a tool a simple wiki could be if we linked a department's briefing book (factual information) with dashboards (coordination).

Now think about how powerful GCPEDIA could be if we linked all of the data at the departmental level across departments and agencies.

Now understand that reliance on organic growth and faith in serendipity will likely never deliver this type of concrete business value to GCPEDIA. The directive needs to come from somewhere on high. My first inclination are the central agencies - after all Privy Council Office, Treasury Board Secretariat and Finance would have a great deal to gain in terms of administering and coordinating things like the Management Accountability Framework (MAF); Program Activity Architecture (PAA); supplementary estimates; and Memorandums' to Cabinet.

I have no doubt in my mind that GCPEDIA could be put to better work than it is now. Furthermore, if we used GCPEDIA in this highly targeted manner we would not only silence all the critics but also deliver the single largest public sector success story of our time.