We began our pilot of SharePoint My Sites almost two months ago. Of the more than 400 people we invited, 320 created a My Site. For many of them, however, this was the last time they used their My Site. To put it bluntly, they don't need a My Site to do their job. So, many perceive that time spent working on their My Site is frivolous, or worse, wasteful. At the same time, there are a few pilot participants who, for whatever reason, have the vision that their My Site will improve the way they do their job, and will make them more valuable employees. It's not easy being a pioneer. They have to figure out how to do things on their own, often on their own time. In this post I will share some of the interesting business-related use cases for internal employee blogs that have surfaced in our pilot.

Of the 320 people who have created a My Site, 20% created a blog site. However, when you take a look at how many people are actually posting to their blog on a regular basis that number drops to only about a dozen. Here are some of the creative ways they are using their blogs:

• A knowledge worker shares job-related information with colleagues, such as summarizing articles from the Internet.


• A software developer shares code snippets with other developers.

• A software developer uses his blog like a personal notebook to keep track of how to do routine tasks, such as calculating time-zones and zip codes from address data.


• A knowledge worker writes entertaining stream-of-consciousness posts about a project that he is working on.


• A summer intern keeps a daily journal of what he has learned, observed, and accomplished.

So, even though only 4% of the pilot users are blogging regularly, we are seeing tremendous creativity and resourcefulness among the My Site bloggers. As we deploy My Sites to the enterprise, we don't expect the percentage of active internal bloggers to grow beyond 4% for a long time, and we are comfortable with that.

Have you seen any other interesting use cases for internal employee blogs?

Social Computing Enables Knowledge Capture and Sharing
One of the primary benefits of Social Computing is that it enables knowledge capture and sharing. Unlike e-mail, social computing platforms, such as blogs and wikis, places content in an environment where other people can find, access, and use it. Consequently, it’s often better for people to post to their blog than send an email. Granted there are still times when an email is the right medium. Before sending an email, we should all ask ourselves whether the content has potential value to people beyond the original distribution. If it does, put we should put it in our blog. Likewise, we should use a wiki instead of creating a word processing file whenever possible. It is easier to collaborate with a wiki and then be assured that other people see the most current version. Again, there may be times when a word processing file is necessary, such as when special formatting is necessary. However, in most instances it is just as easy to capture content using a social computing tool so that they can be leveraged as knowledge assets later.

Protecting Knowledge Assets
Social computing is new to the enterprise space and it demands a new approach to protecting shared knowledge assets. Traditional approaches of deleting terminated employee content do not apply well to shared social computing content. Take this example: Bill accepts a position with another company. Shortly after leaving, a termination process reacquires his computer, and deletes his mail file and personal network drive data. Within days or weeks of leaving, Bill’s personal content is purged from the enterprise systems. With data on computers, personal network drives and in e-mail, this probably makes sense. After all, no one else in the company had access to this content when Bill was around. Social computing knowledge assets, on the other hand, should be treated differently. They are shared. Bill’s blog, for example, does not necessarily become less valuable when he leaves. It may contain pertinent information about his role and responsibilities that could be invaluable to the people who remain after Bill’s departure. In fact, Bill’s blog may be more valuable to the company now that they no longer have access to Bill the person. Therefore, companies need to put some thought into how they manage the knowledge assets of terminated employees.

Recommendations
What is the best way to protect the knowledge assets of terminated employees? Here are some ideas:

• Don’t automatically delete content of terminated employees – The content produced by a terminated employee is an asset that belongs to the company. Separate the termination process from the retention policies relating to shared knowledge assets.
  
• Don’t expect managers to review the content of terminated employees – Not only are managers usually too busy to review the knowledge assets of terminated employees, they also cannot necessarily judge the potential value of the assets on their own. Expecting managers to take the time to isolate and protect knowledge assets of terminated employees is unreasonable.
  
• Do approach the challenge like a project – Identify stakeholder (including legal, compliance, and human resources), gather requirements, and design an approach that will best meet the requirements.
  
• Do gather metadata when knowledge assets are created – This metadata will help you determine the value of the knowledge asset. There will probably be a point in time when each knowledge asset loses its value and needs to be purged. Knowledge assets located in social computing platforms should adhere to a company’s electronic data retention policies, just like information in any other repository.
  
• Do flag the knowledge assets of terminated employees – If I were to find the knowledge asset of a terminated employee, it would be helpful to know that it was created by someone who no longer works for the company.
  
• If nothing else, delay deletion…as long as possible – For most companies, accurately assessing the value of social computing knowledge assets is difficult. This makes it impossible to apply a retention period independent of the termination process. So, if saving everything forever is not an option, consider preserving knowledge assets for a predetermined period after termination, preferably 12 months or longer.

In conclusion, take care when deleting social computing knowledge assets of terminated employees. Implement a retention process that protects content based on its value the company, and don’t just delete it because the creator of the content has left.