K-Log Pilot Recap

A K-Log Pilot Recap

by Rick Klau
Originally published: November 11, 2002
Comments/questions: E-mail me

To any who are interested, I thought I’d give an update on our month-old pilot of a Radio-based k-log. (For more on k-logs generally, check out the archive of the K-Logs group at Yahoo. In short: it’s a network of weblogs throughout an organization designed to facilitate knowledge sharing.)

My company is a 125-person software company based in Chicago, Illinois. We develop CRM software for the professional services market (law firms, consulting firms, investment banks, etc.). Aside from Microsoft Office, the only application we use across the company is our own, which we use to track all customer and prospect activities.

I’ve been a Radio user for nearly a year, and maintain a public weblog at http://www.rklau.com/tins/. I am part of the senior management team at the company, and I tend to be seen as the “web guy” inside the company. For that reason, I didn’t want to simply mandate that people use this - anything coming from me about technology is taken with a grain of salt. Of course I’d find it cool - if it blinks, has buttons or makes noise, I’ll give it a whirl. The question was whether others in the organization would find weblogs as useful as I had.

Our IT department recently rolled out a new version of the corporate intranet, which today exists as a largely static site that houses much reference information (sales documents, HR info, customer support database, announcements) but not much “active” content that changes often.

Ultimately, my goal was to make the intranet more of a destination – a place where individuals throughout the company are able to easily share their observations, questions, and experience.

I picked twelve people in the company to serve as the pilot group. The individuals were picked from a cross-section of the company: QA, Sales, Marketing, Professional Services, Development, Product Management. They also represented various “levels” within the company, from the CEO on down. If successful, the hope was that each person could then serve as an evangelist to their groups inside the company.

We evaluated Radio for 30 days for free. My goals:

• Get Radio installed on twelve desktops.
  
• Create custom look & feel that mirrors the rest of the company intranet.
  
• Meet individually with each participant to ensure they understand how Radio works and what we expect out of the pilot.
  
• Periodically e-mail the group with tips and tricks about using Radio.
  
• Have a full group meeting at half-way mark to identify initial feedback, flesh out questions and problems.
  
• Prepare an end-of-month evaluation form that will assemble feedback of pilot team:
  
  
  
  • Did this help you disseminate information about your job more easily?
    
  • Did you learn something about the company you didn’t already know?
    
  • Do you check your news aggregator once per day?
    
  • Are you more effective in your job as a result of the k-log?
  
  
  

• Decide whether to purchase licenses for initial team.
  
• Decide whether to purchase licenses for broader group within the company.

Getting Radio up and running was our first hurdle. Setting it up for my own weblog was painless – even tweaking the settings to publish it to my own domain instead of to the default Userland domain weblogs.com was a matter of minutes.

During initial setup, we discovered that many browsers’ cache settings were set to check for new versions of the page “automatically”. (Automatically is apparently a Microsoft euphemism for “whenever we feel like it”.) As a result, several settings that were made in the browser were passed through to the Radio server, but did not show up in the browser when the page refreshed because the browser was loading the version of the page from the browser cache. This led to some confusion from the users (I already updated my username and password! Why does it still show the old setting?) that needed resolution – once we set the browser to check for new versions of the page every visit to the page, we solved that issue.

The second issue related to security on our intranet. Our intranet is powered by IIS, and relyies on NTLM authentication. This means that the web server (IIS) would only “trust” Microsoft applications requesting files and deny any other applications requesting files. While Internet Explorer can communicate with the web server without a problem – it is, after all, a Microsoft product – Radio could not. This meant that anytime a user tried to subscribe to another user’s XML feed, we got an error that was less than clear. What the server was saying was that Radio was not passing the appropriate authentication information to the server, so the server would not return the requested file to Radio. Our fix was to change the authentication scheme on the XML files to not require Microsoft’s security information. That fixed it. (It should be noted that this is not a Radio problem, strictly speaking, but a Microsoft problem. Nevertheless, it was Radio that was affected. Many thanks to Jake Savin from Userland who ultimately helped identify the cause of the problem and identify a couple possible work-arounds.)

Our web development guy built a Radio Theme that copied the overall look and feel of our intranet – giving users a comfort level that they were dealing with something that was ours. Radio does a great job of supporting template-based design, so the end result was a look and feel that was identical to the other pages on the intranet.

I then met with each user individually to ensure they understood Radio basics. Here’s how you post, here’s where it goes. Some wanted more, so we set individual preferences to enable post titles, a few liked the idea of being able to automatically add a web page to their blog, so we installed Radio Express, etc.

Following those meetings, I sent an e-mail to everyone to reinforce the basics. No need to get too fancy – just ensure that they know what’s here and how to extend it. I explained the Aggregator in more detail, and uploaded an outline of about 100 RSS feeds broken down by category so that people wouldn’t have to spend time learning NewsisFree or Syndic8. Each link in the outline was formatted to automatically add the URL to the Radio aggregator. (Many thanks to John Robb for doing some of the heavy lifting on this already; I simply added that info, combined with some of my own, to an OPML-based outline that activeRenderer made easily browsable in the browser.) An edited copy of that outline is here; I edited out some specific internal information.

At the beginning of the second week into the pilot, I sent a second e-mail that explained a bit more about the aggregator and how to subscribe to each other’s sites. Our web developer configured IIS to index all weblogs so that all content was searchable, and set up a multi-author weblog so that all posts were aggregated into one page that visitors could browse to see what various people were saying.

At the beginning of the third week, I scheduled a meeting with the pilot group. It was a productive brain-storming session. First, some of my observations about the reactions of users to weblogging so far:

• People were somewhat overwhelmed at the prospect of starting with a clean slate. There wasn’t any there there (with apologies to Getrude Stein) – and this gave several people pause. They didn’t know what to put “there”.
  
  
  

• Some people were confused about what should go where – should an interesting piece of information go into the intranet (i.e., via Radio), in the CRM application (our own product, InterAction), or be sent by e-mail?
  
• Some users, conditioned to the conventions of e-mail, were worried that simply posting something wouldn’t ensure people would read it – if it was really important (a subjective assessment, to be sure), they were more comfortable sending it by e-mail.

Some specific requests were made by the pilot group. Interestingly, one – the ability to get the newest posts from the Aggregator in his inbox – was recently released as an enhancement to Radio (Radio users can click here to set this up). But other requests followed a similar logic – the prospects of having to go somewhere else for data was daunting to many. People are already comfortable in Outlook – they didn’t want to have to learn another interface.

Many were in agreement that the k-log would be a great vehicle for senior execs to share wisdom with others in the company. Oddly enough, those same people were uncertain whether they as individuals would have information that would be valuable outside of their team. Somewhat contradictory, however, was a comment made by one user (and echoed by others) that it would be really nice to learn what was going on “on the other side of the house.”

Given the flexible nature of weblogs (unlike structured applications, weblogs really can be what you want them to be), it wasn’t entirely surprising to see users shape their own expectations in testing out the software:

• A senior developer saw Radio as a great annotated bookmark tool – a way to save URLs and provide his own commentary for others in his team.
  
• A marketing manager saw Radio mostly as a clipping service – the ability to snag snippets from other web sites to save to her own site.
  
• A sales person used Radio to distribute industry news relevant to other sales people.
  
• A QA tester who frequently lunches with customers in training often provided recaps of discussions at lunch – sharing the customers’ interests and inquiries.

At the end of the fourth week, I sent an e-mail surveying the users about their experience with the project. Some observations:

• Most users had posted between 5 and 10 items in the first month. This relatively low number isn’t terribly surprising, as weblogs represent a new paradigm for sharing information. It was, however, lower than many expected. Reasons for the low posting rate included busy schedules and an uncertainty about what to post.
  
• Though people understood the value of the Aggregator, few used it. Most subscribed to 1-2 other weblogs inside the company (if that), and only a handful subscribed to any external sites. On the other hand, many did take advantage of the k-log “home” page (which was the multi-author weblog that subscribed to all users’ weblogs).
  
• More than 3/4 of those surveyed indicated that they believe the company would benefit from a broader implementation inside the company. That said, those same individuals questioned what the focus of such an implementation would be, and whether people would actually contribute.

In all, I was pleasantly surprised at the variety of ways in which people used the k-log.

Some more mundane, but important observations (these are mine; your mileage may vary):

• Thirty days is not long enough to evaluate a project like this. You’re competing for time, and successful participation in a k-log requires a shift in how people work. To accomplish that, I think a more realistic timeframe is probably 90 days.
  
• Iron out any technical kinks before involving other users. I naïvely assumed since I’d had no trouble setting up my own weblog that it would be equally simple on our intranet. We have a fairly standard setup (as intranets go) but encountered some dificulties. (As mentioned earlier, these challenges weren’t related to Radio but to how our intranet was configurd – but you’d be well-served to test these things out beforehand.)
  
• Get a good handle on how people work. I under-estimated the desire of most people to remain in Outlook – and this translated into a lack of comfort working in the browser. (This is even more surprising when you realize that our own product has a fully-featured web client.) If your users expect to work within a particular interface, do what you can to make it easy for them to stay there. (For us, we could have implemented Radio’s mail-to-weblog feature, or spent more time building Outlook-friendly web pages that could render within the Outlook interface.)

Some lessons I learned from this experiment:

• Have a problem to solve. Just telling people “things will be better” when they don’t know that there’s a problem is tricky. As mentioned above, weblogs are many things to many people. In our pilot, we started out by simply saying we wanted to see if people found them useful. In other words – we weren’t trying to solve a problem.
  
  
  

• Reward participation. A number of people stated that they had trouble working blogging into their daily routine – that they had a number of other priorities competing for their time. Not surprisingly, they tended to gravitate to things for which they received recognition. A successful deployment of a k-log will need effective rewards to help reinforce the desirability of participation.
  
• Define what you’re looking for. This is related to the first point, but I think it’s important enough to discuss on its own. I was surprised at the number of people who understood conceptually what the weblog did but who were still unclear on what they could contribute. People are very used to a fairly formal communications format – and weblogs are highly unstructured. Without a focus, inertia seemed to dominate.
  
• Ensure senior participation. I tend to believe that grass-roots KM is the most difficult to achieve. When a program like this is supported from the top down, people are more likely going to appreciate the importance of the project – and appreciate the connection between the project and the company’s overall success. If we are to increase the k-log’s success, we will need to involve more of the senior management team.

Bottom line: we learned a lot about how we want to share information internally. Noone in the company had a bad experience with their weblog. Some gravitated to it, while others found themselves more as a “consumer” of information rather than a “producer”.  This experience provoked a number of excellent conversations about what kind of information would be valuable inside the company. Sales people started thinking about what they did that might be useful for product management; development started thinking about what marketing was working on that might make them more effective.

At the end of our first month, it’s not a slam dunk. To be successful long-term, we will need to expand the number of people with access to Radio as an authoring tool. We will need to define our objectives – with more specificity than simply identifying how we can improve communications. But this was a helpful start – and a good first step to better understanding how weblogs might make us smarter.