Who's the guy with the blue head?

Recently, the organization I work for acquired another company within the same industry. Because the acquired company is very successful in their own right, all employees were retained and we are currently sharing best practices and working towards integrating what is now two separate divisions within a larger company. The end goal is to implement the best practices from each division, companywide. For the purposes of this article I will refer to the acquiring company as “Division A,” and the acquired division as “Division B.”

As human nature dictates, each division believes that there way is the best way and that any change would be counterproductive. However, senior management see’s the big picture and has done a great job of uncovering the best practices from each division. The first major change we are going to implement is integrating Division B into Division A’s Information Systems. This is going to be a big project for me because I am the guy from Division A, who trains everybody on the Information Systems. Therefore, I will be the guy who trains everybody from Division B on the new information systems being implemented in their organization.

In order to develop a training plan I needed to familiarize myself with Division B so that I know who to train on what and to get to know my audience so I can start thinking about what the best delivery methods may be. So, I put on my consultant hat and made a trip up to Seattle to spend a day in Division B’s corporate office for a scouting trip.

Boy did I feel like the guy with a blue face in Division B’s corporate office. I could hear the whispers of “Who’s that guy?” “What’s he doing here?” “Ohhhh! He’s from Division A!” There is definitely a level of resentment rooting from fear in Division B towards Division A. Although Division A retained all of the employees from Division B and gave them more perks then they had before there is still a fear of the impending changes. Because I come from Division A and play a key role in implementing these changes I am not exactly welcomed with open arms.

Prior to this scouting trip I thought my biggest challenge was going to be the timeline we are working on. Little did I know I was in for a rude awakening. I now know that my biggest challenge will be establishing credibility and overcoming Division B’s fear of the change. I can have the best training plan in the world but that won’t make any difference if I cannot gain their acceptance of the change.

This leads me into territory I am not familiar with. In my role I have a history of implementing change in Division A but that change was usually welcomed with open arms because they know I am there to make their job easier. Unfortunately my batting average doesn’t mean squat to Division B. Division B doesn’t have the understanding that this change will make them more efficient and is a huge improvement for the company as a whole.

At this point I need to come up with a plan for overcoming this fear and helping the general staff of Division B to see the big picture. If I can sell them on the benefits of these changes then my training efforts will go much smoother. This project is giving me a good taste of what an external consultant goes through when trying to sell their services to a client. I am usually the client so hopefully I can track down advice from somebody who feels my pain : )

Cheat Sheets

I stumbled upon Tim’s Blog which is chock full of “One Page Guides” that are simple, one page job aids covering a variety of topics. Browsing through these one page guides reminded me that simpler is better most of the time. A well designed job aid such as the one page guides can be much more effective than a day long training course.

I routinely create PDF’s similar to the one page guides and make them available on the company intranet which works out great but after looking at the one page guides I know I can do better. By keeping the job aids down to one page and laying out the information in a more user friendly format I can get much better results. Keeping these principles in mind, I am going to start creating one page “Cheat Sheets,” rather than long documents covering everything under the sun regarding the topic.

Here are a couple of my favorite one page guides from Tim’s Blog:
Online Video Editing
Introducing Wikis

Off and Running

We’re off and running with the Wiki. It’s installed and running like a dream. Now we are dealing with the task of writing the content which is turning out to be quite a task. I have no prior Wiki experience and I was under the impression that I could just copy and paste sections of training manuals that I have written into the Wiki and have it ready to go in no time. Little did I know that Wikis have a whole language of their own. With the help of a cheat sheet I picked up the Wiki formatting language pretty quickly and I am basically copy and pasting a line at a time then adding the formatting.

So far we have written about 20 articles and I really like how it is all laying out. We’ve been playing around with the categories which appear to be a huge factor in user friendliness. From my small amount of Wiki experience I have learned that if the Wiki is going to be effective then it will need to be constantly maintained and updated. I know the whole idea behind a Wiki is that the users will keep it maintained and updated but let’s get real here; very few people will be able to see the big picture of the Wiki. It is going to be crucial to have a team of people that understand the big picture and can keep the contents maintained so that it is well structured.
This has lead me to the idea of starting a Wiki team that not only maintains the Wiki but does most of the writing of new articles and updating of older articles. Due to the formatting language it doesn’t seem feasible to have just anybody doing this. The average user will have no idea what commands they need to enter for headings, etc. I envision having a team of “Wikivangelists” that maintain a watch list for certain subjects. I can take experts from different areas of the company and train them on the Wiki so that they can be responsible for their area.

Before I get started on developing my team of “Wikivangelists” I need to get some more content pumped out. Once I get a good base of content I will be able to help potential “Wikivangelists” get an idea of the overall big picture.

Next Steps:

• Keep pumping out content – Once I get a base of content, it will all start coming together.
• Advertise – Once the content is there I need to advertise it. I am going to have a Wiki naming contest, scavenger hunt, and make a “Wikivangelist Wanted” ad.
• Develop – Develop team of “Wikivangelist” and get them fired up about it. Think of possible name for role other than “Wikivangelist.” Wiki Guru or something?
  

Wiki Research

Through my research into Wiki implementations in corporate settings I have found that there is just not a lot of info out there. I am having a hard time finding good and bad examples of Wiki implementations and how they are best used in corporate settings. I have found a few blog posts regarding Wikis in corporate settings but overall I am going at this blind. I am assuming this is because Wikis are not being used in many corporate settings at this point and there are not many people with this type of experience.

Once I have the Wiki off and running I will begin working on a case study that will hopefully benefit somebody else looking for help with Wikis. Hopefully a good description of my wins and losses will benefit somebody else.

This is a case study that helped me get my head wrapped around this project. It really reminded me of how important marketing the Wiki will be to its overall success.


http://www.e-gineer.com/v2/blog/2007/08/our-intranet-wiki-case-study-of-wiki.htm

IT Comes up Huge!

Last week my chances of getting a Wiki installed behind the firewall were looking terrible. I actually refocused on hosted solutions because the notion of installing MediaWiki behind the firewall was shot out of the water at first. Luckily we have a fired up tech support guy who is dying to get a Wiki up and going so that he can update it with the latest tech support issues that come up. He was persistent enough to find a solution that all parties are happy with and MediaWiki is now installed behind the firewall. The ball is now in my court to make it useful. Where do I begin?

I was so focused on just getting buy in for a Wiki that I didn’t put much thought into the actual development and implementation of the Wiki. So, what are the keys to success in a Wiki implementation? Based on experience I would say the most important factor is creating a great base of content to show the organization what the possibilities are and then come up with a way for them to be excited about it so that they will jump in and use it. It would be a good idea to come up with some kind of contest or release event that brings a lot of attention to the Wiki.

One idea I have had so far that should generate a little interest in the Wiki is to create an online scavenger hunt that will require the participants to find certain information in the Wiki. This would help them realize the great information that is available and how easy it is to access. Quia makes it really easy to make an online scavenger hunt that would be perfect for this exercise.
In addition to a scavenger hunt I will need something that requires them to post or edit information in the Wiki.

Once they see how easy it is to find answers to the Wiki they need to see how they can contribute to making the Wiki better. This is where some kind of contest could come in to play. The organization has a large sales force and a good contest idea would be to enter their most effective sales technique. The techniques entered into the Wiki could be judged by the VP of sales and the winner could win some kind of cool prize like an iPod.

But before I worry about getting people to use the Wiki I need to start writing out the content. I am going to start out by cruising through Wiki’s and developing opinions of what works and what doesn’t. I need to see how the information is presented so that it is made useful. I have plenty of material to work with but I am not exactly sure of the best way to present it. My goal for now is to research what makes a good and bad Wiki and develop a content layout plan from there.

Just in the nick of time!

Just as I was looking into purchasing Camtasia Studio by Tech Smith I came across a blog posting on Tony Karrer's eLearning Technology blog just in the nick of time. Tony posted links to free downloads of Snag It and Camtasia. I have been a long time user of Snag It and love it for screen shots. It is very handy for creating software training materials. I recently used the demo version of Camtasia to complete a software simulation project and it worked out great. I just installed Camtasia and can't wait to put it to use on a larger scale project.

Post about free Snag It and Camtasia downloads

We Need a Wiki in a Wiki

It’s obvious that a Wiki would be a great help in my organization. A few years ago we started using SharePoint and now we are SharePoint junkies. The problem is that our SharePoint intranet has grown so immensely that it is now difficult to find information you need in a pinch. The search features are weak and there is now so much information available that we need a quicker way to get an answer in a pinch. I believe a Wiki would be a great addition to our systems so that it is easier to access commonly needed information quickly. People don’t want to look for the manual then scroll through the manual to the appropriate chapter to find their answer.

So, we know we need a Wiki. Now, how do we make it happen?

Here is what I have identified as our options:

• SharePoint Wiki – SharePoint 07 offers some basic Wiki options that would probably satisfy our needs. The problem is that we will not be upgrading to SharePoint until the end 0f 08 and we can’t afford to wait that long. Plus it would be nice to have some more robust options.
  
• Install behind firewall – One of our tech support guys has experience with PHP and MediaWiki in particular so I am hoping to leverage his experience and install MediaWiki behind the firewall. I proposed this to IT management and I am hitting some roadblocks that I might not be able to get through. Our server farm is stretched too thin and we are preparing for an infrastructure upgrade so it wouldn’t be a good time to install anything additional to any of our servers. This is still being discussed but not looking good.
  
• Hosted solution – This is what I am leaning towards at this point. There are a ton of free hosted solutions that will most likely get the job done for us. The problem is that there are so many options that it is overwhelming. There are quite a few hosted solutions that specialize in Media Wiki and I have also been referred to PBWiki and Project Forum.
  

At this point I am leaning towards a free hosted solution that will let us get started and prove the value of a Wiki. Once I can prove its worth through a pilot Wiki and we complete our system upgrade I am sure that IT will not have a problem with installing media wiki behind the firewall so we can expand our Wiki. If I am able to prove the value and IT agrees to install MediaWiki behind the firewall it would probably be best if my data is already in MediaWiki so the data can be easily transferred and I am familiar with MediaWiki options.

I decided a good topic to cover for the “Pilot” wiki would cover how to find and use what you need on our SharePoint intranet. We recently acquired another company who will be integrating into our intranet next month and this might be a good tool to help them familiarize themselves with SharePoint. By using a Wiki for this topic I can decrease the amount of time it will take for them to become familiar with the new tool.

Now I just need to figure out how I am going to measure its effectiveness. This is going to be tough because there is no baseline to improve upon. They are not using SharePoint now so it is impossible to say if people have been making more efficient use out of it. The best option I can think of is to track the number of hits and relate that number to a number of unnecessary emails or phone calls that would have been made if it were not for the Wiki. If I can prove that the Wiki is being used then the benefits should be evident.

After I finish this initial project it should be easier to prove an ROI for other projects. In particular I would like to use a Wiki for tech support questions and it will be easy to show a decrease in the number of tech support tickets opened. Our tech support staff tracks all of their tickets through a program called Bridge Track which should make this easy.

Great blog post on starting a blog