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.

Like a lot of people in the collaboration and communication space, I'm extremely interested in the Software as a Service (SaaS). Here are my notes from a recent Gartner webinar on SaaS and cloud computing. It was originally broadcast on May 27, 2009, from 1:00 – 2:00 p.m. EST. The presenter was Daryl C. Plummer, Managing VP & Gartner Fellow.

Cloud Computing

• Cloud computing definition: "A style of computing where scalable and elastic IT-related capabilities are provided 'as a service' to external customers using Internet Technologies"
• When you say "cloud", always include another word, like "computing", "storage", "services." "Cloud" by itself really doesn't mean anything.
• The customer doesn't have to understand how a service works. They are "abstracted from provider concerns through service interfaces."
• For the most part IT thinks they need to know how a service works, mostly because we've trained them to do that. Instead, focus on outcomes, measurements, and contracts that mitigate risk.
• Focus on the outcomes you need, not on whether or not the service included the "cloud" label or not.
• Cloud computing is a provider-consumer relationship, instead of a vendor-user relationship.

Cloud Computing models

• Acquisition model: Service – "All that matters is results. I don't care how it's done."
• Business model: Pay for use – "I don't want to own assets; I want to pay for elastic use, like a utility."
• Access Model: Internet – "I want accessibility from anywhere from any device."
• Technical Model: Scalable, elastic, sharable – "It's about economies of scale with effective and dynamic sharing."

Risks of Cloud Computing

• Availability, capacity, and performance
• Security, privacy, disaster recovery policies and procedures
• Service metrics, reporting and analysis
• E-discovery and investigations
• Data ownership, recovery, and migration
• Integration with on-premise systems
• Commitment requirements (terms, minimum use)
• Setup, training, and integration fees
• Difficult to customize
• Switching costs
• Governance of sourcing process
• Data/process location and isolation
• Regulatory requirements
• Transparency to provider operations
• Hidden supply chain impact

Common cloud computing use cases

• Prototyping/Proofs-of-Concept
• Web application serving
• Email / Collaboration
• Application appliances
• Application testing resources

Software-as-a-Service (SaaS)

• A "form" of cloud computing in almost all cases.
• SaaS is misnamed - It should be called "Application"-as-a-service, as opposed to "Software"-as-a service.
• Delivers an application based on a single set of common code in a one-to-many model.
  Uses a pay-for-use or subscription licensing model.
• Beyond simply "bleeding edge" and "good enough", it is now viable and ready for consideration.
• Almost all software vendors will have an SaaS offering

Upsides to SaaS

• Use operating budget instead of capital budget
• Only pay for what you use
• Platform homogeneity
• Lower Total Cost of Ownership(TCO) in mid-term; Long-term TCO is yet to be determined
  
• Faster implementation
• Increased innovation

Downsides to SaaS

• Governance issues
• Release management dictated by provider
• Limited 3rd party tools
• Vendor management
• Security
• Long-term TCO
• Integration between on premise and SaaS

Four things you can do today

• Savings: Compare your cost of capital expenses versus cloud services
• Portfolio: Find three workloads which you can experiment (Move workloads, not applications)
• Migrate: Move existing apps into cloud (Served from the cloud, versus cloud services)
• Use: Consider cloud email and collaboration (Get immediate feedback)

Gartner Bottom-Line Recommendation
Now is the time to consider cloud computing model for delivering services to employees, as well as customers and business partners.

A SharePoint My Site is a central location for you to view and manage documents, links, colleagues, and other information. It is also a way for coworkers to learn about you and your expertise, projects, and work relationships.

A My site consists of two tabs: My Home and My Profile. Additionally, it is possible to create various sub-sites:

My Home is a personal, private web site. You have control over which components (web parts) you include on your My Home page. Some web parts provided initially. However, you can move them around, remove them, and add new ones. Configure it to meet you personal needs. No one else can see your My Home page. However, depending upon how you setup access control, some content within your My Site may be accessible by other people through your Profile page. Examples include shared documents, shared pictures, blog, and wiki.

My Profile is a "public" profile page. All Progressive people have a profile page by default. The entire company shares a single layout for the profile page. You do not have access to change the way your My Profile page looks or works. Using the people search capability in SharePoint, you can locate the profiles of other people. The profile is prefilled with information such as name, location, phone number, etc. Additionally, you may decide to add other optional details, such as your picture, text that describes you, projects, and areas of expertise and interest.

Below your My Site, you can create sub-sites, providing you are within your 100MB storage limit. Common sub-sites include a blog or wiki. However, you may also create sites using one of several site templates. Templates give you a starting layout and web parts that you can configure to meet your specific needs. With sub-sites, you have a high degree of control over the way they look and function, and who has access to them.

I created the following diagram to help illustrate the relationship between My Home and My Profile:

Two weeks ago we started piloting SharePoint My Sites. Although I’ve been using My Sites in a sandbox environment for several months, it was really nothing like using My Sites in the production environment with real security limitations and real people. Here are my first impressions:

People do not understand the differences between the My Home and My Profile tabs

For starters, people don’t understand that no one else can see their My Home tab. The My Home tab of the My Site is a personal workspace. You have the ability to add, remove, and configure web parts. However, any web part on the My Home page is inaccessible to other people. You can think of the My Home page like you would My Yahoo or iGoogle. You decide what the page looks like. It’s for you. We have implemented a 100MB quota on the size of a My Site. List, libraries, and sites must fit within that limit.

The My Profile tab, on the other hand, is what everyone else sees. Think of it as detailed listing within the corporate directory. All of the profile pages take their look and feel from a single site definition. So, our end-users don’t have the ability to change the look and feel of their profile page. However, people do have the ability to control access to some of the information and resources that are exposed through their profile page. Given our current state of a My Site immaturity, maintaining the profile is more important than maintaining other parts of a person’s My Site. The profile is the key to expertise location. In our pilot we have seen broad participation in adding photos and updating the profile fields, such as interests, skills, responsibilities and about me. Far fewer people have been uploading documents, creating lists, and creating sub-sites. I don’t see this as a problem.

The out-of-the-box site definition for My Sites is inadequate for most people

For the pilot, we intentionally left the My Site site definition as it is out of the box. Consequently, people get a My Site with an Outlook calendar web part that doesn’t work in our Lotus Notes environment, and an RSS reader web part that is not pointing to a feed. The initial My Home page is more or less blank. Although this blank My Site has potential for being configured to meet the individual needs of the user, most people do not have the skills, time, or desire necessary to do that. We now believe that a custom site definition for My Sites is critical to adoption. The initial My Home page should contain functioning web parts that deliver immediate value, without configuration by the end-user. Then, if someone wants to further personalize their My Home page, they can always do that. We are looking at providing the following web parts as part of the initial My Home page: email inbox, today’s calendar, company news, stock price, personalized weather, and an external RSS news feed.

It is not helpful to market MySites as internal Facebook

People like Facebook. They understand Facebook. So, it is very tempting to compare My Sites to Facebook. It’s not a good idea to do that. First, it builds an unrealistic expectation. Facebook is a Web 2.0 application designed from the ground up as a social networking platform. My Sites are built on MOSS and WSS. Facebook is relatively intuitive. Probably very few people feel the need for Facebook training. On the other hand, My Sites are about as easy (or hard) to use as any other Microsoft application. Frequently functions are hidden deep within complex menus. Seemingly simple functions, such as deleting a list or library throw people off. They invariably come away thinking a My Site is nothing like Facebook.

The second reason that comparisons to Facebook are problematic is that the feature sets don’t align. Sure there are some slight similarities. However, there is nothing in My Sites equivalent to status updates, the comment wall, or friend activity tracking. (No, the colleague tracker web part doesn’t even come close.) That’s fine. My Sites do a lot of cool business-related stuff that Facebook cannot do, like document management, approval workflows, and lists. So, the point isn’t that one is better than the other; it is that while there may be some loose similarities, they are two completely different tools, designed for different uses. It is better to market My Sites for what it is, a document-based, personal workspace with some basic social networking capabilities.

People do not understand the idea of My Site sub-sites

It’s clear that people are confused by the idea of sub-sites. When they create a blog, they expect it to be part of their My Site, instead of a completely separate sub-site. They don’t expect it to have its own settings that work independently of their My Site settings. It is probably a good idea to not communicate a lot about sub-sites to the masses.

It’s okay if most people never leverage My Sites

For some reason, there are a lot of people worried about what will happen if people don’t create a My Site. “How do we get people to create a My Site?” “How do we show them how to get value from their My Site?” I’m not sure it makes sense to put a lot of effort into forcing My Sites down the throats of our end-users’. My Sites are a cool capability that some people will understand and be able to leverage very quickly. However, most people may not need a My Site any time soon. That’s fine. Most people don’t need all of the capabilities within the Microsoft Office suite either, and that doesn’t keep anyone up at night. Instead of focusing on My Sites, focus adoption efforts on updating and maintaining personal profiles. The usage and value of profiles is more intuitive than that of My Sites. Make the My Sites capability available. However, let it grow organically, at least at first.

Most people are not going to leverage training and support resources

Before we kicked off our pilot we made sure that we had web-based training, and a support site with FAQs and other resources. We found that most pilot participants don’t utilize these training and support resources. Instead, they expect to learn My Sites as they play with them. Truthfully, this is how people in our company learn most applications.

In summary, we should focus on getting people familiar with using the profile page well. We can allow people to create a My Site, if they want. However, we should provide them with a My Home page that is instantly useful and that doesn’t require training. Microsoft tells us that only 8% of their employees use My Sites extensively. Most of their employees utilize Team Sites far more than My Sites. Now that we’ve started our own pilot, the reasons for this are clear.

Well, it's official, Microsoft has announced SharePoint 2010, which was formerly known as "MOSS 14." Here are some highlights:

• The "MOSS" accronym is dead. MS has decided to remove "Office" since the term means Office client to most people. A this point, it will be known simply as "SharePoint."


• Even though "Office" has been removed from the name, there will continue to be tight integration between Office and SharePoint.


• SharePoint 2010 will be 64-bit only and require 64-bit Windows Server 2008 and 64-bit SQL Server 2005 or 2008.


• SharePoint 2010 will require MS Internet Explorer 7 or 8. (MS IE 6 support expires in July 2010.)

Sources: Microsoft SharePoint Team blog

• Click here for the information about the SharePoint 2010 annoucement.


• Click here for the preliminary system requirements.
  

This is the Enterprise 2.0 presentation that I wanted to create, but now I don't have to. It was created by Oscar Berg and Henrik Gustafsson at The Content Economy for a seminar they have been doing. It is an excellent overview of what Enterprise 2.0 is, why it is important, and how it is changing the way we work. Great job guys!

Enterprise 2.0 - Efficient Collaboration and Knowledge Exchange

View more presentations from Acando Consulting.