Yes, I know that today is not Tuesday, but this is about our previous Toronto Wiki Tuesday, a monthly meetup where we have a presentation on wikis, lift a few pints and hobnob with wiki specialists such as Martin Cleaver (who also organizes Wiki Tuesdays) and Mike Dover (responsible for the research behind Wikinomics, and co-author of the upcoming Wikibrands).
The presenter at this session was Tim Hanlon from Royal Bank of Canada, talking about RBC’s journey and future plans with wikis inside the bank. He’s part of the Applied Innovation team, who are tasked with identifying and applying emerging technologies: a sort of center of excellence for technology innovation. They’re within the Technology and Operations area, but half of their team is technical and half business, with a collection of skills that is very similar to a typical CoE.
First, a short lesson on Canadian banks: we only have five, they’ve been around since before Canada was a country, they don’t take a lot of risks, they own all aspects of our financial life, and RBC is the biggest. As you can imagine, wiki adoption in a large, conservative enterprise that’s been around for 150 years poses a few cultural challenges. I did a near full-time contract in part of RBC in 2003-4, and spent some time pushing the use of SharePoint (the only thing available internally) to get people collaborating, so I can appreciate some of the struggles that they’re having with the same culture and bit newer technology.
Hanlon outlined their progress to date:
- In 2006, wiki functionality was enabled in SharePoint, but there was no widespread education about its use or benefits, hence no widespread adoption. Around this time, however, people started to accept Wikipedia as a reference source, which validated the use of wikis in general: in other words, it wasn’t that the RBC users didn’t believe that wikis could work, they just saw themselves as consumers rather than contributors. From my experience, this is a classic large enterprise attitude: many people don’t have the time or the inclination to take that first step to being a wiki author.
- Over 2007-8, the SharePoint wiki attempts in RBC were seen, in general, as a failure. This was blamed on the technology, although that was only part of the problem. During that time period, a Confluence pilot was started.
- In 2009, Confluence was rolled out as part of the corporate standard technology infrastructure: what the RBC architecture review committee that I used to sit on there referred to as the “bricks”, which are products that any department can select and implement without special approval.
- Currently, they have 66 active instances of Confluence (paid version), mostly focused around projects. There are 1,000-1,500 total creators and participants across these instances, with a potential viewing audience of 10,000 internal users. Users are primarily at head office, with very little branch involvement. There is no external access to the wikis.
We spent some amount of time discussing the issues that they had with SharePoint. Some of these were cultural, due to the document-oriented nature of SharePoint: the standard wiki edit functionality looked very much like editing a Word document, and people were conditioned not to edit other people’s “completed” documents. Instead, they would email their changes to the wiki team, which really defeats the purpose of a wiki. Confluence has a very different user interface for editing, which allowed people to disassociate the idea of editing a wiki page from editing someone else’s document. As Hanlon pointed out, they could have customized SharePoint to make it look and feel more like Confluence, potentially avoiding these problems, but they didn’t even know that was the problem until they moved from SharePoint to Confluence.
Since RBC’s Confluence use is mostly for projects, it’s used for things such as meeting agendas and minutes. Last year, I wrote a post based on some research that I was doing with a few clients and around the web, covering the topic of when to use ECM versus a wiki: opinions ranged from “use a wiki only if there are no security requirements and you need to maximize accessibility, an ECM for everything else” to “use wikis for internal content by default, and ECM only for specific cases”. It would be interesting to see if RBC’s experiences with splitting content between ECM and wikis have matched what I’ve seen in other organizations. RBC is using SharePoint as their main document repository, and provide some easy functionality for linking to these documents from Confluence, but project documents are still often imported directly to Confluence. They’ve also found wikis useful for event calendars.
Adoption within the enterprise continues to be a struggle: Hanlon pointed out that they’re out trying to evangelize about wikis to people who just got good intranet search, so may not be ready for the idea of user-generated content. However, they’ve had a lot of success with tagging within Confluence, since many people don’t equate tagging with creating content. He said that they’re getting fairly good participation, but that the slow uptake on content creation is happening at typical “bank speed”. They’re still working on defining where wikis are appropriate, and how to educate the masses on what they are and how to use them: it’s important that wikis are not seen as just some extra thing that people need to do, but as a way of making their job easier. Although Hanlon and many others in the room saw the use of wikis as “creative” and therefore something that people will just want to do, I’ve spent too many hours with back-office workers to think that they’re going to be swayed by the argument that this lets them be more creative in their work. They’re finding that most people will still comment rather than edit, then email responses or requests for changes to the wiki team.
There’s a lot that they haven’t done yet: they haven’t yet started to work with plugins, such as ones that I’ve seen for content approval workflow. There is no federated search that includes the Confluence content, although they do have enterprise search that covers their intranet, shared drives and SharePoint content. They have an internal community of practice (Hanlon’s group), but no real training to roll out across the potential user base. There’s no single sign-on, and about half of the Confluence instances require a login. There’s little customization in terms of appearance, and they’re considering more of an RBC-specific skinning, although this could backfire if people then become confused over what’s part of the (uneditable) intranet versus a wiki. They’re still working out what to put in a wiki versus SharePoint (which is their document repository). In other words, lots of work for the RBC wiki team in the future.
So what does RBC need to do in order to push forward with wikis? They are starting to see value from wikis in content creation, but accept that Word and Outlook still rule in that area; in my experience, most content creation isn’t even making it into an ECM system (if one exists), but is on network drives and in email attachments. They need to balance the corporate need for control with the bottom-up wiki usage and folksonomy, likely by involving some wiki gardeners to help curate the content without controlling it. They need to push past the regulatory and information security mindset that exists within financial institutions, since regulations and privacy don’t apply to much of the information that would likely be stored on internal wikis. They need to understand the long-term value proposition for updating wiki content: what’s in it both for the individual and the company. Lastly, they need to make the long-time RBC employees see themselves as content creators, not just content consumers.
At the end of it all, a very informative talk on the struggles and successes with wiki adoption within a large enterprise. And, at the end of the night, I somehow ended up volunteering to speak at the June event, on using wikis with ECM and BPM. Hope to see you there.