ADDING TO MADER'S 8 THINGS TO DO WITH ENTERPRISE WIKIS
/
In August 2009 Stewart Mader wrote a blog post focused on expanding our thinking of enterprise wikis beyond wikipedia-style documents. As I think about many of the E2.0 projects my organizational design students are taking on this quarter, I'd like to share Stewart's 8 ideas here and see if we can't add a couple.
Here are Stewart's 8 (please see his full post for his explanations. Comments and links here are my own):
- 1. Meeting Agendas
- 2. Meeting Minutes & Action Items
- 3. Project Management These top three are my top three as well. A wiki is "a website that allows the easy creation and editing of any number of interlinked web pages via a web browser...." They are my top three partially because the use is so straight-forward. We all know what the task is; this is just expansion of how the task gets done. They are also my top three because they are so important -- and yet often overlooked in organizational practice. No agenda means that it's impossible to come prepared to the meeting, yet agendas are left out every day. A wiki approach is emergent and social (and thus at the heart of Enterprise 2.0) and intertwines a simple technology into the critical organizational practices of good project management. Please see an earlier post for some basic examples.
- 4. Gather Input -- Keep in mind that wikis are all editable websites/documents. This means Google Docs and Google Spreadsheets are in the mix (as well as other web-based document tools provided by other companies). I see at least two dimensions here: gathering input from a group of people (Stewart's focus) and gathering information from yourself. Regarding the latter, I recently avoiding paying over $100 for an iPhone/on-line logbook capability by building it myself using Google Forms. Any basic survey can be built in Forms and then the form tool deposits the information directly into the on-line spreadsheet (also available off-line if you are using Google Gears.) The iPhone/smartphone capability comes from saving the survey's web address as an icon on the screen.
- 5. Build Documentation - I see this one as being useful both in terms of meeting output and in terms of all written work-products. I have moved from being an evangelist of wikis as how to run group writing efforts to being not so passively aggressive about wiki-based group writing as my only approach. I'll be the first to acknowledge that you often eventually have to move the document into a real word processor for final formatting - but I bet this won't always be the case (and I suspect isn't the case for purpose-built tools like ZOHO Writer - hmmm. I'll have to check out the Microsoft Word support...). I'll also be first to acknowledge that you and your co-authoring team have to become comfortable with sharing "alpha drafts."
- 6. Assemble and Reuse Information - Link away! Not only can you cut and paste easily if you have access to all of your organization's documents -- but you can also help your documents live through links. Linking (rather than cutting and pasting) means that the material stays in sync.
- 7. Employee Handbook - I was in a waiting room for a while Sunday night and happened to sit by a TV playing Undercover Boss -- Waste Management. In the episode, the President & COO of Waste Management, Larry O'Donnell, anonymously takes on a variety of entry-level jobs within his company. This is an eye-opening experience for him and he seeks ways to reduce some of the frustrations he finds in the field. What if he opened the Employee Handbook up as a wiki, at least for comments (and maybe they do...)? Is there risk for misuse? Sure there is a risk, but according to Andrew McAfee (Chapter 6), the incidence of bad behavior on wikis and blogs seems to be inconsequential -- these are typically not anonymous.
- 8. Knowledge Base -- Stewart distinguishes this use from Documentation in that he faces it externally. He gives an example of a moderated (the company checks changes before they are added) wiki that allows customers to see the help wiki and make contributions.
- 9. Make Decisions - Not only can we gather input, but we can make the decision via the wiki as well. The result is that we can always go back and track how we got to the decision we made.
- 10. Work -- Over the last year, my bias has become wiki unless proven otherwise. My documents are in the cloud and I share files or full folders as default. As a result I am pushed to practice TOP Management (weaving together technology, organizations, people) as I think about the tools I have available, the practices the working group should focus on, and the skill set of the people in the group (see discussion of how to do a team audit here). Ideally our transfer of material to the cloud/wiki/team portal occurs passively -- as part of just doing the task -- rather than as a separate action. For example, if we are communicating via email with attachments of our working document, we have to actively save and sync our work. If we instead just work via the cloud/wiki/team portal the work and conversation are already there -- passively with no extra effort. What I missed? Common Craft's Explanation of Cloud Computing:
