Implementing an internal wiki – Dan Collins on the Powerhouse’s rollout of Confluence

Wikis are the sort of knowledge management tool that you’d immediately think of as having great value to museums. However it seems that in the sector they are rarely found outside of IT departments – if at all.

We’ve been looking at them at the Powerhouse for quite a few years now. We tried simple installs of MediaWiki (the open source tool behind WIkipedia) and a couple of hosted ‘free’ solutions – Wikispaces and pbWiki – but none of these were really suitable as an organisation-wide solution.

Recently our IT team rolled out Confluence, an enterprise wiki solution, which is being progressively implemented across the organisation on a project by project basis. Confluence is a commercial application built by Australian software company Atlassian but it has a good user community and 50% discounts for non-profits.

I spoke to Dan Collins, our IT Manager (and web enthusiast) about Confluence and why he chose to go down this path.

What were the initial internal drivers for a wiki inside the Powerhouse?

Dan Collins: Initially my team needed something that would store large of amounts of IT documentation. I was frustrated that we continually kept creating new documentation within the department, and that our servers were always filled lots of outdated and bloated Microsoft Office documents. A wiki model worked well for IT as the information in the wiki represented ‘live’ information and slowly staff began to trust it as the central location for all our departmental information.

After a short while I began to see opportunities where a similar wiki model might work well in other areas of the Museum. Our intranet (built as a stop gap in 1999) was an obvious choice as it contained lots of static information – mainly forms, policies and procedures. As a result staff rarely go to the Intranet – whereas ideally I felt an intranet should be be a hub for all types of organisational happenings – not just static documents.

A wiki model would be able to assist in reducing the bottlenecks of creating content for the intranet by radically distributing the ability for staff to create there own content in the areas for which they were responsible. Hopefully this would also increase ‘ownership’ of the intranet.

How was the choice made to select Confluence? What are its benefits? What else did you look at?

We came to use Confluence after using a few other systems along the way. Initially in the IT department we were using forum software called Invision Board. Then a CMS, Drupal, to manage our documentation. For the purposes of managing documentation Drupal worked well, and I liked that there was a vibrant user community contributing to its overall development.

However, I found that Drupal required a large investment in time to understand how all the various components and plugins fitted together. Whilst Drupal is a very flexible tool and there was never just one particular way to achieve what you were after – which has its benefits -but also posed a number of difficulties.

The Web Unit had also trialled MediaWiki for use by the Powerhouse Media Labs staff, and we had looked at a few online based solutions. MediaWiki was too unfriendly in terms of user interface, and it became clear that a hosted solution would become problematic due to the sensitive ‘internal’ content we would want it to host.

Around the same time I was looking to replace our under-performing and expensive corporate helpdesk software. We came across a product called Jira from Australian firm Atlassian. Jira provided many of the features that we were after for a fraction of the cost of commercial helpdesk systems, and it so happened that the support pages for Jira were hosted on another Atlassian system called Confluence, which was impressive in its own right, and things happened from there.

Initially I was impressed with how quickly we could get both products underway. A fairly painless install with most of the common database servers supported.

Configuration time was reduced by being able to link into our existing groups and users via LDAP. And being web based, it meant no client was needed. WebDav functionality allows easy copy of existing content into the system.

During the initial trial period I installed as many plugins as possible to get a feel as to what could be done. I was impressed with the support, and the stability of the system and I was able to get the system to where I thought it should be without the need the need for extensive customisation.

I hadn’t personally spent a lot of time using the editing features of wikis prior to using Confluence, so a bit of time was spent in understanding how it all fitted together. During this time it became that clear that the wiki model addressed a number of the issues we were struggling with in IT across the Museum – overuse of email, duplication of data on our file servers and in email, and a complicated and onerous corporate document management system.

A key benefit is the ease of use of the system – people are writing and attaching documents with little or no training. Collaboration of this nature is something we’ve not had before – staff are now sending links to documents on Confluence rather than large emails to hundreds of people, and using Confluence as the forum for centralised discussion rather than extensive email trails.

Another key feature is the ability to work with existing Microsoft Office documents – either import from Word, or work in Word and then sync back to Confluence. This means that staff don’t need to learn any special wiki markup. Keeping informed of work in other departments is done via alerts and the internal search works well.

The more people work in Confluence, the more file duplication is reduced and we can dedicate our disk space more important functions.

How is it being rolled out? Why are you using this approach?

We have been working with users across the Museum who have shown a willingness to try a new approach. Working closely with these staff have given us insights into the pros and cons of the tools.

We have been very cautious not to change things for the sake of it, and to take it slowly – a group or a project at a time. The approach has been to keep the existing systems running in parallel, but show how things could be done to greater benefit in the new. This way staff always have a fallback position if something doesn’t work as expected and need to meet a deadline.

We have found that after a few days of cautious experimentation, most staff are off and running, looking for new projects to bring into Confluence fold.

Positive word of mouth from staff who have come to across to the system makes it that much easier in gaining greater levels of adoption in areas that aren’t particularly tech savvy.

What strategies are being employed to boost its uptake and use by staff?

Training.

As much as the tool is easy to use, it does require a different approach to the normal document creation process for many staff, and this takes time. Providing detail on what can be done when using a wiki is important to convey. I’ve found that Wikipatterns has been helpful in that regards.

Lately I’ve been using a tool called Wink to capture screen shots and make videos of different functions and ways that it can be used. I’ve found these to be quite popular as people can view them when they have a few free moments.

In addition to training, supporting those users who are quick to adopt the new system has been very important. Making sure that they are across all the features and benefits will (hopefully) reduce the chances of staff reverting back to the old ways.

Support from senior management has also been key in getting people to participate. I’ve found they are very supportive as they are generally the most ‘time poor’ and can see the organisational benefit of simplified collaboration, reducing the need for meetings etc.

Do you think the wiki will accelerate or drive organisational change?

I believe it has already.

For too long we been haven’t been pursuing the best strategy for managing our day to day work. Everyone has had the standard set of tools, Word, Excel etc. However, little thought has gone into whether this is actually the best way we can be working with each other.

In a short space of time, I’ve seen people across the Museum collaborating and discussing projects that just wouldn’t of been possible using the standard Office suite.

I believe that evidence is there to suggest that it doesn’t take people long to get comfortable with the system and become active contributors. When the bottlenecks to creating content are removed – various ideas, concerns or suggestions bubble to the surface where previously they wouldn’t.

I’m excited that there is now a way that I can better understand what my colleagues across the Museum are working on, and that they can also engage more with the work of the IT team.

As an organisation we’ve been very focussed on using the web and various social media tools to engage with the public, and I see that now we can use some of these technologies to better engage with our work colleagues.