Skip to content

February 24, 2013

Build an Enterprise Wiki


Wikis have been around for over a decade. Dur­ing this time they have proven to be an ex­treme­ly use­ful tool for many or­ga­ni­za­tions and the in­ter­net at large. Wikipedia.​org is one of the top ten web­sites and the poster child of what a suc­cess­ful wi­ki should be. It is no ac­ci­dent that an im­mense num­ber of web­sites ref­er­ence Wikipedia via hy­per­links; in­clud­ing this one. Nev­er­the­less, cre­at­ing a vi­brant and suc­cess­ful wi­ki with­in a larg­er or­ga­ni­za­tion is not a triv­ial task. We will de­scribe many of is­sues to con­sid­er while en­gag­ing such pro­ject.

To download a PDF copy of this article, go to the Download menu or click here.

What is a wiki?

It is the some­what sub­tle cor­po­rate strate­gic ad­van­tages that are worth their weight in gold.

A wi­ki is a web soft­ware ap­pli­ca­tion which al­lows peo­ple to cre­ate, ed­it, pub­lish and search in­for­ma­tion via wi­ki web pages on a net­work. The net­work could be the world-wide-web or an in­tranet. These pages are gen­er­al­ly in­ter­linked to one an­oth­er, thus mak­ing nav­i­ga­tion easy. A per­son on­ly needs to use a cur­rent web brows­er such as Fire­fox, Google chrome, Sa­fari, In­ter­net Ex­plor­er, etc., in or­der to cre­ate wi­ki pages and/or mod­i­fy ex­ist­ing pages.

Since soft­ware tracks and backs up ev­ery change made to a wi­ki page, it is ex­treme­ly easy to un­do changes, restor­ing the wi­ki back to a pre­vi­ous state. Wikis are based on the premise that lit­er­al­ly any­body with­in the or­ga­ni­za­tion can and should con­tribute to the wi­ki: Col­lab­o­ra­tion is Key!

Of course, one could set up se­cu­ri­ty per­mis­sions which would re­strict the view­ing or mod­i­fi­ca­tion of por­tions or all of the wi­ki. How­ev­er, this is gen­er­al­ly not the cor­rect ap­proach be­cause col­lab­o­ra­tion is Key.


There are many tech­ni­cal ad­van­tages to a wi­ki such as:

  • Wide range of data types; text, video, sound, images, files, etc.
  • Wide accessibility since anyone can edit it
  • It is easy to train people on how to use a wiki
  • Universal access to up-to-date information
  • Ease of simultaneous collaboration
  • Unlimited number of document revisions
  • Non-techies can create content and publish it quickly
  • Widely available Open Source software offerings

As com­pelling as the tech­ni­cal ad­van­tages are, it is the some­what sub­tle cor­po­rate strate­gic ad­van­tages that are worth their weight in gold. Over time, wikis can em­body the or­ga­ni­za­tion’s in­tel­li­gence, pol­i­cy, di­rec­tion and cul­ture: An im­por­tant com­po­nent of En­ter­prise 2.0.

By read­ing a wi­ki new­com­ers to the or­ga­ni­za­tion can quick­ly come up to speed as to the “how to” and “why’s” of the or­ga­ni­za­tion with­out re­ly­ing on a hand hold­ing pro­cess.

Wikis can quick­ly be­come con­sen­sus builders through col­lab­o­ra­tion. This is an area that should not be looked up­on as the “tyran­ny of the mob” but rather as an or­ga­ni­za­tion’s Col­lec­tive In­tel­li­gence, Even­tu­al­ly, the wi­ki repos­i­to­ry will be ma­ture enough so that one could per­form da­ta min­ing on it and dis­cov­er or­ga­ni­za­tion­al trends.


We should be mind­ful that there are sev­er­al caveats, if we are to achieve a suc­cess­ful wi­ki pro­ject.

Such or­ga­ni­za­tions might not be will­ing to co­op­er­ate to make in­for­ma­tion read­i­ly avail­able and it might even sab­o­tage the pro­ject.

To be­gin with, we should dwell for a mo­ment on the im­pli­ca­tions. For ex­am­ple, some or­ga­ni­za­tions are overzeal­ous about their in­for­ma­tion. Fur­ther­more, de­part­ments with­in such or­ga­ni­za­tions might not be will­ing to co­op­er­ate to make in­for­ma­tion read­i­ly avail­able and it might even sab­o­tage the pro­ject. They might feel threat­ened by the seem­ing loss of con­trol and/or ad­van­tage, to what they con­sid­er their in­for­ma­tion. Up-to-date wi­ki in­for­ma­tion may con­tra­dict the in­for­ma­tion com­ing from a giv­en de­part­ment and in some cas­es this might make them look bad.

For larg­er or­ga­ni­za­tions, set­ting up a wi­ki is not a triv­ial mat­ter. In fact, the tech­ni­cal as­pects of it are not the prob­lem. As we said ear­li­er the wi­ki soft­ware has come a long way. In­stead, the non-triv­ial as­pects of a wi­ki pro­ject have to do with is­sues such as: cor­po­rate pol­i­cy, de­part­ment tasks or roles, ob­so­les­cence, le­gal / li­a­bil­i­ty, se­cu­ri­ty, wi­ki con­tent re­spon­si­bil­i­ty, wi­ki re­li­a­bil­i­ty, ed­i­to­ri­al roles, scrap-da­ta, tech­ni­cal sup­port, train­ing, in­cen­tives, etc.

Your pro­ject may re­quire the cre­ation of new func­tion­al roles and re­spon­si­bil­i­ties which en­cour­age or­ga­ni­za­tion-wide col­lab­o­ra­tion and vol­un­teerism.


Without a doubt, a good strat­e­gy will in­creaseTop management team the chances of suc­cess of a wi­ki pro­ject. Top man­age­ment’s ear­ly buy-in is high­ly de­sir­able. As such, man­age­ment should ask a) How im­por­tant is the wi­ki pro­ject to the man­age­ment of the or­ga­ni­za­tion and b) Is this pro­ject viewed as crit­i­cal to the over­all well be­ing of the or­ga­ni­za­tion by all? It is al­so im­por­tant to iden­ti­fy the Cor­po­rate Stake­hold­ers and per­haps draft a sim­ple but con­cise Mis­sion State­ment for the wi­ki pro­ject.

We could al­so in­crease the pro­ject’s vi­a­bil­i­ty by ty­ing part of the ex­ec­u­tive team’s bonus­es to the suc­cess of the wi­ki, such as: num­ber of ar­ti­cles post­ed and num­ber of page views with­in the ex­ec’s span of con­trol. We will dis­cuss in­cen­tives to­wards par­tic­i­pa­tion lat­er on.

Next, one needs to iden­ti­fy a mem­ber of the top man­age­ment team to be­come the pro­ject’s cham­pi­on or ex­ec­u­tive spon­sor. His or her role is crit­i­cal in smooth­ing out any bu­reau­crat­ic hur­dles and keep­ing the nec­es­sary en­thu­si­asm; mov­ing the pro­ject for­ward. Of course, this is al­so true of any ma­jor pro­ject.

Al­though at first, there might be the temp­ta­tion to make IT the pro­ject’s cham­pi­on since it seems like a shoe-in, one should con­sid­er an al­ter­na­tive pro­ject driv­er in­stead. IT’s fo­cus might be to nar­row and tech­ni­cal­ly in­clined to­wards its needs. In­stead, an or­ga­ni­za­tion-wide-wi­ki should strive to­ward a broad base au­di­ence.

Open­ness must be a key strate­gic pol­i­cy.

Open­ness must be a key strate­gic pol­i­cy. It should be em­pha­sized in or­der to counter the al­most knee-jerk re­ac­tion of try­ing to im­pose a strict hi­er­ar­chi­cal form of or­ga­ni­za­tion­al con­trol on the wi­ki. For many peo­ple who are ac­cus­tomed to view­ing the work en­vi­ron­ment as a gi­ant or­ga­ni­za­tion­al chart in which peo­ple’s du­ties and re­spon­si­bil­i­ties are neat­ly packed in­to lit­tle box­es, the idea of a self-or­ga­niz­ing and self-reg­u­lat­ing wi­ki, which is based on a trust-hon­or sys­tem, is sim­ply not fea­si­ble. It may take some men­tor­ing ef­fort to bring most par­tic­i­pants on board to an open-world view.

Fi­nal­ly, we need to fo­cus on the wi­ki pro­ject goals. Ef­fec­tive­ness, ef­fi­cien­cy and cre­ativ­i­ty should be promi­nent on this list. We should al­so in­clude wi­ki met­rics, such as the num­ber of wikis con­trib­u­tors, which al­low mea­sur­ing the lev­el of suc­cess or fail­ure and per­haps, in the lat­ter case, al­low us to in­sti­tute cor­rec­tive ac­tions.


Sim­i­lar to oth­er soft­ware pro­jects, the wi­ki 1-2-3-blockspro­ject team will draft a de­tailed plan with its cor­re­spond­ing time-table, tasks and de­liv­er­ables. Some tasks will be di­rect­ly defendant on the par­tic­u­lars of the or­ga­ni­za­tion in ques­tion. For ex­am­ple, the or­ga­ni­za­tion may be op­er­at­ing in mul­ti­ple coun­tries and it may be nec­es­sary to sup­port mul­ti­ple lan­guages. Train­ing may have to be con­duct­ed in mul­ti­ple lan­guages as well. It could be that a phased ap­proach is used where­by dif­fer­ent or­ga­ni­za­tion­al units are rolled in­to the pro­ject based on a sched­ule.

The le­gal and se­cu­ri­ty teams will be re­spon­si­ble for guide­lines on wi­ki us­age, dis­claimers, li­a­bil­i­ty is­sues, slan­der, dis­crim­i­na­tion which should be dis­cussed ear­ly on. The ob­jec­tive is to cov­er all the le­gal and se­cu­ri­ty bases with­out ham­per­ing the open­ness or wi­ki col­lab­o­ra­tion ef­forts. On the se­cu­ri­ty side, guide­lines should be draft­ed which will pre­vent, for ex­am­ple, pub­lish­ing ex­treme­ly sen­si­tive or­ga­ni­za­tion­al in­for­ma­tion. Once again, this is not much dif­fer­ent from oth­er soft­ware pro­jects. In a way, there could be a lot more lat­i­tude in a wi­ki pro­ject, pro­vid­ed that the wi­ki re­mains on the in­tranet away from the pub­lic.

Wi­ki soft­ware se­lec­tion will take some time. Be care­ful not to fall prey to de­ci­sion-by-com­mit­tee where a lot of com­pro­mis­es and per­son­al bi­as­es will come up with a less than op­ti­mal prod­uct for your or­ga­ni­za­tion. There are many com­mer­cial and Free Open Source (FOSS) of­fer­ings. Most pro­vide a ro­bust ba­sic func­tion­al­i­ty. Some may in­ter­face bet­ter with oth­er soft­ware prod­ucts cur­rent­ly used by the or­ga­ni­za­tion. One of the ar­gu­ments that come up time and again re­gard­ing com­mer­cial prod­ucts ver­sus FOSS prod­ucts is that of sup­port. For some peo­ple, the sup­port el­e­ment is more press­ing and for oth­er peo­ple the abil­i­ty to mod­i­fy the code is more im­por­tant. Fi­nal­ly, the wi­ki soft­ware cho­sen should first and fore­most work for the whole or­ga­ni­za­tion.

planningWe men­tioned Wikipedia.​org ear­ly on. It is an ex­cel­lent wi­ki and a good choice for dif­fer­ent or­ga­ni­za­tions. Their wi­ki en­gine is a FOSS ap­pli­ca­tion built by Mediawiki.​org. It is based on the PHP lan­guage and runs on the LAMP plat­form which is al­so FOSS and very com­mon on the In­ter­net. This wi­ki ap­pli­ca­tion is con­stant­ly be­ing up­grad­ed to make the soft­ware more se­cure, to elim­i­nate bugs and make it more re­li­able. Be­cause one has ac­cess to the source code, this wi­ki can be cus­tomized to in­te­grate it with oth­er ap­pli­ca­tions. LDAP is sup­port­ed out-of-the-box and this would al­low an or­ga­ni­za­tion to in­clude the wi­ki in­to its sin­gle sign-on strat­e­gy.

Oth­er IT plan­ning con­sid­er­a­tions in­clude:


Plan­ning should al­so in­clude the wi­ki per­mis­sion or edit­ing struc­ture which is con­trolled via an ac­cess con­trol list or ACL. Us­ing the wi­ki’s ACL you will as­sign the sys­tem ad­min­is­tra­tors, sysops, up­daters, view­ers, page cre­ators, etc. Much care should be tak­en so that the per­mis­sion re­stric­tions do not sti­fle the wi­ki’s growth. Re­mem­ber the val­ue of a wi­ki is its broad base open­ness. How­ev­er, some wi­ki pages, by the very na­ture of their con­tent, may re­quire lim­it­ed or no edit­ing ca­pa­bil­i­ty oth­er than that con­ferred to their orig­i­na­tors. Some su­per users may be al­lowed to over­ride changes.

De­pend­ing on the wi­ki’s de­sign ar­chi­tec­ture you should plan for growth. For ex­am­ple, you may choose to have mul­ti­ple wikis with­in your or­ga­ni­za­tion. Plan­ning to link them so that a search on one can al­so search the oth­er wikis, should be con­sid­ered. But even if you on­ly have one large wi­ki, you may in the fu­ture, al­low your cus­tomers, sup­pli­ers and peo­ple from out­side of the or­ga­ni­za­tion to have ac­cess to por­tions of the wi­ki. You may choose to im­ple­ment named spaces to this ef­fect.

Let’s not for­get to plan for train­ing. Some wi­ki soft­ware ap­pli­ca­tions re­quire us­ing a sim­ple markup lan­guage which might con­fuse and de­ter some peo­ple from col­lab­o­rat­ing. Train­ing ma­te­ri­als such as videos can be made avail­able on the wi­ki it­self.


We usu­al­ly think that vol­un­teer work Show of handsis as­so­ci­at­ed with not-for-prof­it or­ga­ni­za­tions. We as­sume that for pri­vate en­ter­prise, work ac­tiv­i­ties such as con­tri­bu­tion are reg­u­lat­ed by com­mer­cial in­ter­ests. In oth­er words, em­ploy­ees are paid to per­form a job and that’s all there is to it. One could be tempt­ed to view an en­ter­prise wi­ki in the same man­ner. But is this ac­tu­al­ly true? If we stop and think abou it for a minute we could come up with count­less in­stances where ac­tions per­formed by em­ploy­ees for the bet­ter­ment of the “com­mon good” are not man­dat­ed by their job de­scrip­tions. This is es­pe­cial­ly true when deal­ing with cus­tomers in which an em­ploy­ee will go the prover­bial “ex­tra mile” to help a cus­tomer; over and above his or her job’s re­spon­si­bil­i­ties.

We be­lieve that vol­un­teer work with­in the or­ga­ni­za­tion will make or break a suc­cess­ful wi­ki pro­ject; it is that im­por­tant. This is true for Wikipedia.​org which re­lies al­most 100% on vol­un­teer ef­fort, and it’s al­so true for any oth­er wi­ki im­ple­men­ta­tion, as well. There­fore, we should ded­i­cate a great deal of ef­fort to en­cour­age vol­un­teerism un­til the wi­ki reach­es crit­i­cal mass.

Crit­i­cal mass is a point in time where­by the wi­ki be­comes self-sus­tain­ing. We will know that this point has been reached when large num­bers of peo­ple ac­cess the wi­ki pe­ri­od­i­cal­ly in or­der to ob­tain in­for­ma­tion that per­tains to their job. At the same time a fair num­ber of peo­ple con­tin­ue to add new in­for­ma­tion (con­tribut­ing) to the wi­ki, thus mak­ing it fresh and rel­e­vant.

For ex­am­ple, a ra­tio of 100:1 tells us that for ev­ery 100 users on­ly one per­son con­tributes to the wi­ki repos­i­to­ry.

Iden­ti­fy­ing the vol­un­teer ra­tio ear­ly on will al­low for mak­ing ad­just­ments which will im­prove the suc­cess of the wi­ki pro­ject. This im­por­tant met­ric is based on the num­ber of peo­ple who con­tribute ver­sus the num­ber of peo­ple who use the wi­ki. It is well known that a sig­nif­i­cant­ly small­er num­ber of peo­ple ac­tive­ly con­tribute. If the ra­tio of con­trib­u­tors is too low then pro­ject might be jeop­ar­dized.

For ex­am­ple, a ra­tio of 100:1 tells us that for ev­ery 100 users on­ly one per­son con­tributes to the wi­ki repos­i­to­ry. If your or­ga­ni­za­tion has 1,000 peo­ple, on­ly 10 peo­ple will con­tribute in the cre­ation and main­te­nance of wi­ki pages. At first glance it may not be enough. We have to re­mem­ber that these vol­un­teers are not ded­i­cat­ed full time, so in prac­tice the ra­tio might be much small­er, say 200:1. If on the oth­er hand we have a vol­un­teer ra­tio of 10:1 then in an or­ga­ni­za­tion with 1,000 about 100 peo­ple are reg­u­lar con­trib­u­tors; a much dif­fer­ent pic­ture emerges.

We need to cre­ate in­cen­tives to stim­u­late wi­ki col­lab­o­ra­tion. For ex­am­ple, we could keep track of those in­di­vid­u­als who are top con­trib­u­tors and pro­mote them as em­ploy­ee of the month. Men­tion them in a month­ly newslet­ter. If no newslet­ter ex­ists then cre­ate an e-newslet­ter for the wi­ki and men­tion these peo­ple there. Al­so, we could cre­ate a healthy com­pet­i­tive en­vi­ron­ment where­by top con­trib­u­tors will be list­ed on the wi­ki’s land­ing page. Peer recog­ni­tion is very high on the list of in­cen­tives which have worked out well be­fore.

Oth­er forms of vol­un­teer in­cen­tives in­clude awards, prizes, bonus­es, free tick­ets to an event, comp-time, fa­vor­able em­ploy­ee re­views, etc. You could add many oth­er forms of in­cen­tives to stim­u­late col­lab­o­ra­tion.


Set­ting up a suc­cess­ful wi­ki with­in a large or­ga­ni­za­tion can be a chal­leng­ing pro­ject. A wi­ki pro­ject will par­al­lel many oth­er IT based pro­jects. From the tech­ni­cal per­spec­tive these are not ma­jor chal­lenges. How­ev­er, the or­ga­ni­za­tion­al chal­lenges are more dif­fi­cult. These chal­lenges can be met by a good strat­e­gy, plan­ning, ex­e­cu­tion and a lot of ded­i­ca­tion to­ward stim­u­lat­ing col­lab­o­ra­tion across the en­ter­prise.


Share your thoughts, post a comment.


Note: HTML is allowed. Your email address will never be published.

Subscribe to comments