Mark Suter. Mark works for Unisys in Aus, and as well as general documentation problems, they have a boatload of compliance to deal with as a result of having Government clients.
This is the Perl sense of lazy.
Mark kicked off by checking everyone knew what a Wiki was, and noting most of us have them or have had them. They started with a small group, all in physical proximity. Change was easy, easy to communicate, easy to create buy-in. Now they’ve pushed out they need to be mindful of natural resistence to change.
I’m afraid this braindump was a bit spotty, since my laptop actually spat the dummy and shut down to stop itself from overheating at one point. Also had some mediocre speeches prior and bad sleep last night causing me to flag a bit.
Posibilities
- Full revision history.
- Scripting possibilityes.
- Semi-automation of regular reports.
- Export ODF/PDF
- Analyse stats, produce usage/metrics.
Make sure that the people supporting the Wiki are positive, flexibile. Wiki will stand or fall on how well it’s implemented and supported. Sharepoint failed at their site because it wasn’t supported.
Business Case
“Put our documentation in one place and keep it up to date.”
Start small, JFDI. Wide adoption in the organisation happened almost by mistake; it’s gone from an internal tool something mentioned in business pitches as evidence of being properly set up.
Advantages
- One source of truth—everyone knows where to look and everything as a home. This is especially useful where there’s high turnover of the phone meatshield.
- “It’s in the wiki” is both true and a joke. If it’s not in the wiki, why isn’t it?
- Keeps documentation alive; in a high-documentation environment this is critical. There has to be a doument that says “we follow policy x”, even thought the policy is written somewhere else.
- Wiki early, wiki often. Update when brainstorming. Update when things change. Put 0.1, 0.2, etc it there so people can see it before 1.0. This is a big advantage of locked-down workflows that result in finished documents appearing to an audience that feel dinenfranchised.
- Documentation drives behaviour; the availablity of information makes it easy for staff to do the right thing. Search even if you know the answer—because you can that way broadcast critical information.
Culture
Challenge: Ownership. Everyone owns the wiki. Separate the author from the document; don’t take edits personally.
Get culture right from the start—once culture has been created, it’s hard to shift.
Champions: early adopters, believers, internal marketers. Will need the most support.
Put everything in; design, config, system notes. Only the legal stuff needs to be non-editible. It the wiki isn’t the right place, it’s the right place for directions to the right place.
JFDI: Don’t ask why it’s not there, stick it in yourself.
Ontological problems: They rely on search to get the right results. Search is critical - that’s my experience. Get people to log dupes on the discussion to remove dupes, move.
Revisions: Scripts create reports for old documents go to people whose job is reviewing and deciding what to do with the doco.
Success: Success solves the problem of multiple implementations, as long as your managers are prepared to pick a winner.
Quality: One person has a tagging facility on Twiki, and the tags people put (good/bad) show up as part of the search results.