Bootstrapping a Corporate Wiki

Lauren Wood recently has recently been seeking input from people successfully using a Wiki in a corporate environment. I’ve been meaning to write up my own experiences in this area for a while, as I’ve spent the last few years nurturing a burgeoning Wiki culture at Ingenta. Lauren’s request was the spur I needed to start to set down my thoughts.
Read on for some personal notes on the viral introduction of a Wiki into a corporate environment.

In The Beginning

We’ve had Wiki environments running at Ingenta for about three years now. The original Wiki site was one I started for my own personal use as tool to support the R&D role which that my focus back then. I had a need to be able to quickly capture bookmarks and commentary on a number of wide ranging topics, as well as write up research proposals, notes, and experiments. I also needed to share these with my colleagues in the research team and the rest of the engineering department. I could have just put up a website, but wanted something quick to evolve. As I’d already used several public Wikis I decided to install a Wiki engine and give it a whirl.
After I’d had the tool up and running for a while, I got interest from the engineering team who wanted a similar environment for writing project documentation. So, starting from a clean install, we added a second Wiki environment, and got the engineering team contributing to it. They had the usual initial fun creating personal homepages, but then got down to work on documenting various tools, components and procedures.

Unleashing the Virus

At this point I got interested to see how far it could go. Like many “.com” companies, Ingenta had grown rapidly and was finding itself without an adequate content/knowledge sharing infrastructure. We’d had repeated plans to build a corporate intranet but (I suspect) like many projects of this nature, feature creep and analysis paralysis crept in to the extent that a simple document repository/intranet concept turned into an online employee database, internal workflows, document management system, the whole shebang. Needless to say that grand vision never did quite see the light of day.
Before joining Ingenta I’d worked for Praxis, a local IT company that had been bought out by Deloitte Consulting. Praxis had a intranet which consisted of a core set of pages (corporate information, project links, process docs, etc) which was richly supplemented by personal homepages owned and constructed by staff members. Deloitte had a completely centralised intranet, that had very little staff contribution (beyond under-utilised forums) plus a bespoke infrastructure (Lotus Notes).
I knew which of those environments I’d personally found most useful, and so wanted to see a similar de-centralised approach to organising internal information.
So I decided to try pushing the Wiki as a de facto intranet environment.

Building a Community

With the engineering department slowly building a useful set of technical content, the next goal was to get some of the other departments involved.
The first lesson I learned here is that users new to a Wiki environment expect it to be more like a website: they wanted one of their own. So, to the existing research and engineering Wiki’s we inevitably added several others: IT support, QA, and one for capturing “intelligence” (competitor and industry activities, etc), etc.
After leaving these to bed themselves in for a while it quickly became obvious that only the engineering Wiki was growing organically. The others had had a brief flurry of usage but quickly became stagnant. I believe the reasons for this were several:
User Base — Wiki’s are nothing without constant nurturing. For that you need a decent population of users. The engineering department was larger than the others and so it was easier for them to reach a critical mass which kept the content moving.
Relevance — The engineering Wiki was directly supporting the team as it went about it’s business. Component documentation proved useful as teams grew and shrank; Detailed release documentation became an essential of the configuration management process; change requests were quickly written up and circulated amongst the team; best practice documentation was similarly shared. The other teams were often creating content purely for other users, who weren’t directly contributing back to the Wiki, so they had gone fallow.
Good Citizens — A number of my colleages had really got bitten by the Wiki bug, and were becoming good WikiCitizens. As the content base grew, more thought was being put into organising and reorganising the Wiki to keep the content fresh and (hopefully) easily navigable. While it’s easy for one person to setup a Wiki, it’s essential for the user community to take ownership for their own content and, perhaps most importantly, for other people’s content.

Expanding the User Base

Around this time I became manager of the engineering department (the poor fools have never recovered 🙂 and pushed more of our processes into the Wiki: all change requests, specifications, and project write-ups were done in the Wiki rather than in lengthy Word documents. Test scripts for QA’ing the site went through a similar treatment.
Using “inter wiki” linking features/macros I tied the Wiki into our Bugzilla installation, then into features on the test and public services. Our shared corporate drive had been descending into a mess for some time, and as it was available as HTTP over the internal network, I created an “Intranet” page on the Wiki and linked to every useful resource I could find on it.
Basically I wanted to reinforce the relevance of the wiki to the engineering team, whilst using the Wiki environment as an organizing principle to start to knit together disparate internal resources, many of which were previously localised to individual departments.
With the move of specifications and the change request processes into the Wiki environment, the product management and QA teams began to use the Wiki. This increased the size of the community but kept the relevance-factor: the Wiki was becoming an increasingly important communication tool between the departments. In the face of a number of staff “reorganizations” this was a vital step.
From that point on the Wiki has really taken on a life of it’s own. Moving from a technology focused tool, it’s now being used by many more of the internal departments. For example the Sales teams, after some initial experimentation with a separate enviroment, are now using the Wiki to capture sales prospects, and most interestingly co-ordinate work on Request For Proposals.
Responding to an RFP involves a need for high-bandwidth communication between a number of cross-functional teams to ensure that all aspects of the proposal are correctly dealt with. Flurries of emails and shared, rapidly evolving, documentation is the norm. This work is now being co-ordinated through the Wiki environment. The initial RFP is published to the Wiki and the response team can co-ordinate around the shared pages, with everyone easily able to see the latest updates and revisions; change tracking and diff’ing are both essential Wiki feature’s. What’s more, many more people can now contribute ideas and suggestions.
It’s still early days, but it’s fascinating to see how a Wiki environment can facilitate sharing and contribution in this way. In fact, in my view, where you have many different teams within an organization, ensuring a good degree of information sharing requires extra work — you have to step outside of the task at hand. Whereas, with the majority of teams using a Wiki, you’d have to do more work to stop information being shared. I know I’m not the only one keeping and interested eye on the RecentChanges page on our Wiki to see what’s happening elsewhere in the company.

Where Next?

The Wiki concept has been so successful at Ingenta that it’s started to expand outside of the organization.
While we’re still some way from a public Wiki to provide documentation to support our services, we now have several private Wiki’s running as a means to share documentation with clients. Essentially the project managers and technical teams can share information directly with their counter-parts at our clients. It’s certainly come a long way from a simple research notebook.
At some point I’ll try and synthesise our experiences over the past three years down into some practical recommendations for others wanting to follow a similar tack. But I think this posting has gotten long enough for now.