September 25, 2006
Wiki Web pages, now commonplace and prolific on the Web, are beginning to show up in the project management world, and not a minute too soon! Wikis are a rich and powerful tool to add to the project manager's collaboration toolbox.
However, company IT departments are increasingly concerned about these kind of tools. If you are sensitive to these concerns and the risks they represent, you'll be ready to provide abatements and a rational discussion that may just win you an opportunity to proceed.
Usual Concerns
Concerns crop up around the usual issues heard from Corporate IT:
Security: How to you prevent unauthorized access? How can you protect company assets? Will these tools open a door to attackers from without the enterprise? What kind of demands will be placed on the IT infrastructure team for back ups and other on-going support maintenance? Who is responsible for security updates to the software and operating system?
Control: Who manages “what goes on” on the wiki? Who manages the site or the hardware? How is content managed and controlled in accordance with company policy? Often, “corporate policy” dictates that only IT can own and operate servers.
Responsibility: Who is responsible and accountable for the site and site activity? How many revenue dollars are at stake? How many core business unit VPs will be supported?
Reliability: What are the service level expectations for the site and infrastructure? Who is responsible for maintaining those service levels?
Cost: What will this cost in terms of labor hours and dollars? Beyond acquisition costs, what are the lifecycle costs for the site?
Policies: Does the hardware meet standards? Is the OS supported? Are the applications on the approved list?
Specific Concerns with Wikis
In particular, the very strengths of a wiki generate important concerns. Wikis combine authoring, collaboration, storage and update capabilities into a simple and intuitive interface--that is what they are designed to do. However, consider the value of the content handled in that channel. Corporate knowledge, proprietary information and capability, and capital knowledge assets are each subjected to what many consider a process-free, controls-free, open-access environment.
Wikis are not content or document management systems (CMS/DMS). Don't expect them to provide version management, content protection or check-in/check-out functionality unless you specifically provide it. If your company employs CMS/DMS, then you can expect those parties to be concerned.
Security can be a concern, as "anybody" can edit/delete/post. You can and should consider carefully who your authors will be. Most wikis allow you to designate specific authors if "anybody" is not an appropriate choice. Thought must be given to the risk of inadvertent loss of data. These security risks can often be sufficiently abated with procedure and frequent automated backups of the site.
Who will manage the site and technology? IT will not be happy at the prospect of project sites cropping up like mushrooms in the night, and then demanding lots of time and effort to administer and keep running. Here, the project team must accept responsibility, and it behooves them to have a low-administration/highly reliable solution. See the Best Practices suggestions below, which talk about self-administered hardware and software.
Is Open Source stable or reliable? Of course there are software companies out there buying full-page ads and fold-outs to get out their version of the facts suggesting otherwise. But note that as of July 2006, 63 percent of the Internet servers are using the Open Source Web server Apache (Netcraft survey). Google and many other huge e-commerce sites rely on GNU/Linux. The application stack that relies on Linux, Apache, MySQL and Perl/Python/PHP, known as LAMP, is mature and used throughout the Web. Especially for a small project site on a company intranet, mainstream Open Source components are well known, well supported and very reliable.
Control issues may be the most difficult to address and solve. My recommendation here is to communicate clearly and honestly with the IT department and any other agency that may not be used to hearing a project team ask to plug in their own Web server appliance on the company intranet.
Don't forget to touch base with legal and corporate communications if you think there is any chance those constituents may feel nervous about uncontrolled communication via http within the company. Get a reasonably high-power sponsor (the project sponsor?) to help open doors and, as required, minds.
Access and availability of your project content via corporate portals and search facilities may be an issue to solve. If your site's content remains invisible to such corporate resources, and they are key means for your audience to find and use your content, then everyone has a problem. If this is an issue, you will have to work with the specific details of the problem and technologies involved to resolve it.
Best Practice Suggestions
Position wikis as transient authoring environments. Upon completion of deliverables and documents containing corporate knowledge assets, promptly move them into company approved formal document management systems. Then turn around the "delivery vector" so the project site now offers links to the documents now stored in these more formally controlled systems.
Know your audience, tailor communications to that audience's needs, and stay narrowly focused. These technologies allow flexibility and control of delivery to a point where you can create a uniquely tailored page for each stakeholder group.
Consider the risks that arise from easy publishing by a wide range of authors. Do you have guidelines for your authors? Are there controls for authorship? Are there protocols and guidelines governing content and process? Does the site have appropriate visibility (subnet only, corporate intranet, or WWW)?
Closely related to the points above, keep your project site and wikis behind the company firewall. 1. Your audience is probably there; 2. The firewall keeps a lot of noise and potential security threats off of your site; and 3. Should your team publish material that is definitely not ready for primetime--it is contained within a closed community.
Provide the procedure and the means for frequent backups. Build and test scripts that allow for a rapid restore of content to any arbitrary point in time. Most wikis provide extensive revision histories and the built-in means for moving the site to a particular revision. That, coupled with formal backups at an appropriate frequency, allows granular and precise management in case of an accident or willful vandalism or sabotage. Be sure to keep enough backup generations in case you discover a problem weeks after it occurs.
Train and familiarize your team with the need to be aware of their wiki resource, so they can be quick to notice and respond to any unusual circumstance. The truth is that this is a natural consequence of a healthy and valued collaboration resource--the supported community nurtures and cares for the tool--and the community it serves.
Establish some technical expertise on the team to know and be comfortable managing the technical nuts and bolts of the site--this is not such a stretch as it might sound. Don't rely on the Corporate IT department and don't plan on having their support.
Assuming a request for your own server is not an impossible policy exception, acquire your own hardware and manage your own Web server.
Hardware is amazingly cheap. In fact, you may find that a cast-off server no longer up to the inefficiencies of another operating system and Web infrastructure may work wonderfully using GNU/Linux and the Apache Web server. The Open Source world provides the best infrastructure, bar none, for these kinds of sites. Linux, Apache, MySQL and Perl or PHP (LAMP) are available to everyone and represent a killer stack upon which many outstanding wiki systems are built.
The author offers a project collaboration demonstration site to showcase open source options for project teams. It runs on only $500 worth of hardware--an AMD Sempron at 2.3 gHz with 512 MB RAM, a system drive with 3.2 GB and a RAID 1 pair with 117 GB effective. Check out www.washburn-pmg.com/ProjectSite to review examples of these tools and kick the tires a bit.
If security and sensitivity of the information overlap and give concern, consider compiling your Apache server to employ Secure Sockets Layer (SSL) 128 bit encryption for your wiki. SSL is well-known, accepted, employed by your company in various roles, and extremely secure.
So consider these issues and questions. Formulate and document your answers and policy. Then recruit your project sponsor or your PMO to help open doors and minds. The value tools like wikis bring to your project team is just too compelling to ignore.