Hi Perian, I'm wondering why/if you decided against using a forum for this purpose? Is it the editing capabilities of the wiki?
I used a forum for conference planning last year and it was like pulling teeth to get people on the site. Similar problems with the forum we used for a research cluster. I think the main issue was that people would forget about it if it didn't come in the inbox. I eventually switched to a google group so that we would have an archive of everything on one site while allowing users to receive emails. I think you can set this up with most bb software, too, though I've never tried it with a wiki. You have one huge asset on your side: these are employees you're dealing with, not volunteers, so they have the whole day to focus on their work rather than doing it on their own time. I think that it's important to treat the switch like its own project, rather than "just a tool," and dedicate a portion out of each week to work on it since it is such a big change for some people. While I don't have experience using a wiki in this way, I do have some suggestions based on tech support and workshops I've done in the past (and I think this would be helpful for any tech changes). Hopefully, it will be useful! Make the advantage obvious. Show examples of other wikis. Set up a topic on your wiki for a previous project--one with which they're still closely familar--add in several of the old emails on the wiki, and show them how much better it is than "just email." Because they already know the project, they'll be able to focus on the features of the wiki and imagine its use concretely. Make it a team effort. Don't just send the link in an email--get everyone together in a board room or something so that they feel like they're talking to a real person about it, and it doesn't require them to take time individually out of their daily work. Go over each step with them, preferably in front of computers so that they can follow along, then provide them with a quick reference guide. Make sure that (unlike this email!) the information is highly organized and that you go through step by step. Start from things that seem so obvious to you, you'd assumed they already knew it. Make it accessible and comfortable. Bring snacks. Imagine you are teaching the wiki to your grandmother. Allow them to have input into the project, but emphasize why everything needs to be in one place. Show them how to search the help files. I always say that, "It's not about knowing all the answers, it's about knowing where to find the answer." Assure them that you are willing to help at any time, and prove it by dropping everything to guide them through difficult spots. Put the address to the wiki in your email signature and tell them it will be there. This approach should take care of the late adopters by making them feel supported and capable, and it should also help those who need an email notice by putting the wiki right in their faces with sugar and coffee and official-ness. Keep it on the radar. For the first few weeks/months of the wiki being open, I would send out periodic updates to everyone on how it's successful, what's being changed, and best practices. Link to examples to get them in the habit of reading it like a newspaper. As for information organization, the format I used on our bulletin board was: 1 forum per project, ex. "conference" 1 section per team, ex. "submissions, marketing" 1 topic per project element, ex. "recruiting submissions readers, designing call for submissions poster, press release, etc." Depending on the size of the project, this may not translate as well to the wiki format. I thought I'd throw it out there in case it's helpful! Good Luck! Shana On Fri, Jul 18, 2008 at 9:42 AM, Perian Sully <psully at magnes.org> wrote: > Hi all: > > > > Ok, I'm feeling a few days late to the party, given that there was just > a discussion on this topic at VSA, but since I didn't go, I'm hoping > someone here went and can give me some ideas for how we can use our new > internal wiki to help keep discussions OUT of email and onto the > static/fluid format which is the wiki. > > > > We're moving our website into a content management system and I'm hoping > I can collect all of the information from the seven workgroups into one > location, especially for our collective sanity as we move forward. But > I'm kind of stumped as to the format, and with getting buy-in. Many of > the staff are not familiar with using wikis, so I need to train them. > Plus I'm having a bit of trouble conceptualizing how the organization of > the information should work. > > > > Does anyone use a wiki for project management and would be willing to > share information about organization? and how did you get everyone using > it? > > > > Perian Sully > > Collection Information and New Media Coordinator > > Judah L. Magnes Museum > > 2911 Russell St. > > Berkeley, CA 94705 > > Work: 510-549-6950 x 357 > > Fax: 510-849-3673 > > http://www.magnes.org > > http://www.musematic.org > > http://www.mediaandtechnology.org > > > > _______________________________________________ > You are currently subscribed to mcn-l, the listserv of the Museum Computer > Network (http://www.mcn.edu) > > To post to this list, send messages to: mcn-l at mcn.edu > > To unsubscribe or change mcn-l delivery options visit: > http://toronto.mediatrope.com/mailman/listinfo/mcn-l > -- Shana West Master of Arts, Museology University of Washington shana at u.washington.edu
