Companies are addicted to PowerPoint. It's hard to imagine how anyone ever sold an idea or proposal prior to digital presentations. This has resulted in mountains of bloated slideware files clogging our email and file servers. Microsoft Office SharePoint Server (MOSS) 2007 now includes a slide library feature that goes a long way toward improving the way we work with PowerPoint presentations.

The out-out-of-the-box slide library leverages all of the standard content management features inherent in MOSS, including as check-in/check-out, versioning, alerts, and workflow. The difference between a slide library and a standard document library is that when you upload a presentation from PowerPoint or MOSS to a slide library each slide becomes a unique SharePoint item, which is managed independently.

The real magic begins when you create a new presentation from the slides stored in the library. First, you select the slides to include. You have the option of creating a brand new presentation or importing the managed slides into an existing PowerPoint presentation, providing it is already open. You also have a choice whether or not to keep the formatting. Finally, you can choose to be notified if the managed slide in the library ever changes.

Think about it. As you open a presentation, it automatically checks the authoritative source of record to see whether any managed slides have been updated. That's powerful! If there have been updates, you can decide whether to replace the old slide or simply append a copy of the updated slide. Obviously you can ignore the update all together, if you wish.

So here's an example: We maintain an overarching Unified Communication and Collaboration (UCC) Strategy presentation. In addition, we have several sub-strategies for specific services within UCC. There are some redundant slides and some unique slides across each of these presentations. By using the slide library we can manage a single copy of each unique slide. Then, when we open a presentation it checks to see whether each slide is current with the version in the slide library. Before, if we needed to update one of the redundant slides, we would need to remember to replace the old version in each of the presentations. That takes time and is prone to human error. The MOSS slide library results in a much more efficient means of managing PowerPoint slides.

Although the advantages of using the MOSS slide library are clear, there are some things to keep in mind:

• The MOSS site type must be a 'team site' or 'document workspace.' Other site types may not support slide libraries. Slide libraries cannot easily be added later unless you create a new sub-site based on the 'team site' or 'document workspace' site type.
• All slides should be uploaded to the root of the slide library. It too difficult to create a new slide show from slides scattered across different folders in the library, since you lose your selections when navigating between folders.
• Whenever you create a new, unique slide it should be uploaded to the slide library so that it will be managed.
• All slide edits should be done on the managed copy stored in the library. Do not edit slides directly in the presentation. This will ensure that every presentation using that slide will be kept up to date.

The MOSS slide library is valuable to any team that manages a large number of dynamic presentations. I hope that Microsoft will continue to develop and enhance the slide library. Here are some most wanted improvements:

• Larger thumbnail graphics - The tiny thumbnails in the main slide library view are so small it is impossible to read the content. Unless you are very familiar with the content, you will need to click on the slide to see a larger image or perhaps even open the slide in PowerPoint.
• More safeguards - There are not any built-in safeguards to ensure that a presentation made from slides in the library will stay in synch. Someone could easily break the link with a slide in the library and not know it, resulting in the Presentation becoming stale.
• Support for templates - A document template based upon slides in the library does not maintain the connection between the slides in the template and the slide library.
• Deletion support - If you delete a slide in the library, you should be prompted to have it removed when you open presentations containing that slide. This would make it much easier to retire an obsolete slide across all presentations that contain it.

Have any of you used the new MOSS slide library? How does it work for you? What improvements would you like to see?

I came across an article in Social Computing Magazine by Venkatesh Rao which asserts that there is a war between traditional knowledge management (KM) and the new social media (SM). Rao sees SM as the Gen-X solution to the problems that boomers were trying to solve with KM, but failed. Boomers and Gen-Xers come from complete opposite approaches. KM stresses strict order, hierarchy, taxonomy, and content. SM stresses openness, collective knowledge, folksonomy, and people. Regardless of whether you buy into Rao's thesis or not, he raises some interesting observations. Who will win? Rao believes that SM will prevail quietly by default as the boomers slowly retire from the workplace.

In a companion piece by Jeff Kelly, Rao's position is refuted. Kelly not only doesn't believe there's a war, he thinks that SM actually represents a logical evolution of KM. Kelly accused Rao if trying to instigate a war that doesn't exist.

Personally, I've struggled to reconcile the relationship between KM and SM. I'm old enough to have experienced KM and find that a lot of my boomer colleagues still use the term. However, you never hear a Gen-Xer refer to KM. Rao's article made me realize, in a way I had not previously noticed, that KM and SM are diametrically opposed in many ways. At the same time, KM and SM have so much in common, especially in terms of the goals they strive to achieve.

What do you think? Is there a war? Or just a quiet evolution? Does it matter?

A little more than a year ago we learned that people in our company were standing up wiki solutions on their own because IT did not have a wiki standard. At that point we identified three wikis, all built on a different open source platforms, including OpenWiki, MediaWiki, and Flexwiki. Clearly we missed the opportunity to anticipate demand. However, it wasn't too late to limit our risk.

In less than two months we identified stakeholders, gathered requirements, evaluated wiki solutions, and selected a standard. The goal of the standard was to prevent (at least going forward) the proliferation of disparate wiki platforms. We selected Screwturn Wiki because it was open source, built on Microsoft .Net and SQL Server, and met our functional requirements. However, due to our need to establish the standard quickly we did not have time to operationalize it. This meant that there was no centralized infrastructure, no internal support team, and no guidance on how to implement a Screwturn wiki to work well within our company. Development teams were basically on their own to build and support their Screwturn wiki instance.

While the Screwturn wiki standard met our goal of building new wikis on the same platform, the way we implemented the standard did not meeting the needs of our end-users. They wanted a standard that was fully supported by IT and on a centralized infrastructure. Self-provisioning of wiki sites was also an important requirement. They didn't want to engage IT people to create a wiki. They wanted to simply push the "new wiki" button.

As all of this was going on, we were in the process of implementing Microsoft Office Sharepoint Server (MOSS) 2007. We had heard that MOSS included its own wiki out-of-the-box. This was intriguing to us since it would mean that we could leverage our MOSS infrastructure and support structure. It also would meet the self-provisioning requirement. However, we immediately learned that the MOSS wiki is a really a WINO: Wiki In Name Only

The out-of-the-box MOSS wiki lacked many features that had become standard in today's open source wikis, including table of contents, sections, sectional editing, and intra-page linking. This perplexed us. It was as if Microsoft had thrown their "wiki" into MOSS at the last minute so that they could check the wiki box on the feature comparison chart. While the MOSS wiki may have some value for people who had never used a wiki before, those who had find it utterly lacking.

So, we had a problem. Do we try to use the MOSS wiki for the masses and allow people that need a real wiki to continue to use Screwturn? This would require us to address the operational shortcomings of our Screwturn standard, which would take time and money. It would mean that we would need to operate and maintain two separate wiki solutions, which is complex and redundant. We needed a better solution

Our research revealed very few full-feature wikis built on MOSS. In fact, we only found three possibilities: Kwizcom WikiPlus, Community Kit for SharePoint (CKS) from Codeplex, and WikiPoint by Neoworks. We ended up dropping the CKS from consideration because it lacked sectional editing and intra-page links. We also eliminated WikiPoint because it appeared to only be supported on WSS 2.0. That left WikiPlus. If that didn't work, we were prepared to do what was necessary to operationalize Screwturn wiki.

Our initial evaluation of WikiPlus was not great. While they did add a few interesting features, such as reporting, lifecycle management, and an enhanced editor, they were missing critical features, such as a table of contents. We contacted them and learned of a new release that would not only include a table of contents, but sectional editing and intra-page links. Over the next several weeks we worked closely with Kwizcom to address our unmet requirements. They were very responsive to our needs. The result was a feature-rich wiki solution built on MOSS. Our people who evaluated WikiPlus liked it better than Screwturn, primarily due to the WYSIWYG editor.

Someday Microsoft's wiki may grow up and eliminate the need for a 3rd party solution like Kwizcom WikiPlus. Until then, its nice to know there's a viable alternative.

Check out Lauren McKay's article at destinationCRM.com which summarizes some recent research by Forrester. Not surprisingly, they find that blogs, mashups, RSS, and wikis are experiencing the most growth, in terms of enterprise adoption. The part I found most interesting was the assertion that enterprise podcasting and social bookmarking have run their course, failing to take off as predicted. I'm not sure I would be so quick write them off. They may simply follow blog and wiki in terms of enterprise adoption, as this is where the big enterprise vendors are focusing right now. Our end-users are asking for podcasting and social bookmarking. However, we're telling them to wait. We beleive that the future enterprise 2.0 suites will include this functionality out-of-the-box. What's your experience with enterprise podcasting and social bookmarking?

Ray Sim's Learning Connections blog posted one of the best wiki use case lists I've seen. In addition to those on Ray's list, I thought of a couple more. I came away from the exercise with the sense that it is possible to do almost anything in a wiki, whether it was the best tool or not. It goes back to the idea that if there's nothing in your toolbox other than a hammer, then you'll try to fix everything with a hammer. That being said, I think the following list has some creative and interesting use cases:

• The Wikipedia use case: "community creates consensus-based truth regarding a particular topic."
• Documenting a business process (step by step instructions) — either as an initial draft for what is later to be "locked-down" in a document form (e.g. as required by government regulations), or not.
• Sharing tips and personal experiences related to a business process that is documented elsewhere.
• Creating a Frequently Asked Questions (FAQ) to support a software application or business process.
• Creating a glossary of terms that are specific to the project or company.
• Creating a "portal" to commonly used resources within a team or community, e.g. frequently used URLs to applications, documentation, contact information, etc.
• Creating a bibliography of team/community member's reading that they found valuable for the project or topic.
• Preparing for a face-to-face or virtual event. Gathering participant input (e.g. proposing and finalizing agenda topics) and defining logistics for the event (e.g. when participants flights land, arranging car-pooling to the venue, selecting dinner locations, etc.)
• Supporting weekly (or other periodic) face-to-face meetings. For example, conference room(s), phone numbers, facilitation assignments, agenda, minutes, etc.
• Augmenting live conversation, e.g. taking jointly visible notes during a virtual meeting — either as part of a web conferencing solution, or independently.
• Maintaining a "lab or project notebook" to share across shifts (teams working different hours on the same project) and/or physical locations.
• Collaborative writing - For example, user documentation, proposals, policies, etc.
• Collaborating on product or solution development including design, features, and technical specifications.
• Disaster management site – Real-time communication and coordination of recovery efforts.
• Strategic Marketing / Competitor Information - Document marketing strategies, results of market research and comprehensive information and analyses of competitors and link them to supplementary information – before, during and after the product launch.
• Knowledge-base or support site – support questions, issues, solutions, how-to guides. comprehensive documentation of so-called ad hoc expertise to assemble a network of unstructured knowledge, for example, of specialist knowledge about corporate processes, guidelines, recurring organizational processes, checklists, etc.

Let me know your thoughts on these use cases and if you've encountered others.

In my last post I listed nine benefits of internal employee blogs. In addition to the potential benefits, internal employee blogs may pose some risks, including the following:

• Potential disclosure of false, personal, sensitive, or embarrassing information that could put the company at risk – Assuming these blogs are only accessible inside the firewall, this risk is somewhat decreased. However, when you give every person the ability to publish content that could be accessed by every other person in the company, there is good chance that someone will eventually post content that should not have been published. The biggest deterrent to intentional abuse is to ensure that the name of the author is always clearly visible. The lack of anonymity assists most people in making the right decision. Additionally, a strictly enforced policy with real penalties is a good practice. Many companies today have adopted the simple policy of "don't do anything stupid. And, "if you do, you will be fired." Then they follow through on that threat quickly and decisively.
• Difficult or impossible to monitor or control blog content – The old model of having a corporate gatekeeper edit and approve any content that it published to a large audience cannot support the scale required by social networking technologies. It remains to be seen if automated, rules-based content scanners will be able to flag and perhaps quarantine risky content. Making authorship explicit and having an enforced policy should sufficiently mitigate this risk.
• Loss of productivity – Of course the big fear from many managers is the potential loss of productivity. Are people going to stop doing their "real job" in favor of posting to their blog? It's unlikely. This sounds like the worry that employees would abuse telephone or internet access. Most companies at least seen clear to allow every employee to have access to these technologies. In reality, only a small percentage of employees will consistently write to their personal blog anyway. Of those, an even smaller percentage will develop a following beyond their immediate team. In the end, every person's performance should be measured against quantifiable job objectives. Effective performance and compensation systems will help ensure that people do what is in the best interest of the company.
• Increased support costs – With any new application there are ongoing support costs. That is also true for internal employee blogs. In addition to looking for a solution that is supportable and robust, consider the offsetting benefits and base your decision on the total value of the technology, not just the cost. In my current company we plan to leverage the blogging functionality built into Sharepoint (MOSS 2007), which should keep the support costs in check. When you compare the relatively low cost of internal employee blogs with the potential benefits outlined in my previous post, the decision should be clear.
• Content will become stale – With any content repository, one of the greatest risks is that the content will lose its value over time. It is difficult to automate the process of assessing content value on any basis other than age. We assume that the older the content is, the greater the potential is for being stale. While that may be true, it is equally true that some content is stale within hours and other content retains its value for years. This risk should be considered as part of an overarching content and records management strategy. Of all the risks, this one may be the most difficult to mitigate adequately. To date, the most common approach is to accept this risk or enforce a draconian retention rule to the entire repository instead of basing retention on the content itself.

While there are some risks related to internal employee blogs, most of them can be successfully mitigated with an effective risk management strategy. Can you think anything I missed?

I work for a Fortune 500 company with nearly 30,000 employees scattered across the U.S. We have been experimenting with internal employee blogs for a couple of years. However, to date only senior business leaders have been allowed to have a blog. These popular sites have gone a long way toward improving transparancy and providing a way for the masses to provide feedback. We’re now on the cusp of deciding whether or not to open up internal blogging to every employee.

To be clear, these are internal blogs. They would be accessible only to employees and contractors inside the firewall. Although the capability would be made available to all employees, we assume that a large majority would never actually make the effort to create a personal blog. And, of those that do, only a small percentage will ever attract much of a following. Even so, there are a number of people, mostly business leaders, who have a hard time grasping why we would even consider letting any employee write his or her own blog. After all, how is letting our employees blog going to reduce expense or increase revenue?

• Publish content instantly and efficiently. Sure, there’s always email. However, email lacks context. Whether it is a line manager who needs to get the word out to his team or a thought leader who wants to float a new idea while its fresh, there is power in self publishing.
• Capture and search knowledge that would otherwise only exist in the heads of our people. There’s a lot of knowledge burried in email. Unfortunately, it is completely useless to everyone except the person who happens to have a copy. Even for them, its unlikely they will find it when they need it. Email retention policies and quotas result in deleting messages that still have residual value. When an employee leaves a company, his or her email account is deleted within days of their leaving, and a long with it, the embedded knowledge. Blogs, on the other hand, are accessible to and searchable by everyone in the company. The knowledge contained in a blog could remain as long as people are accessing it regularly, even when the original owner has long since left.
• Provide a communication platform for thought leaders, regardless of where they are in the official corporate hierarchy. As I mentioned, only a few leaders at the top of the food chain have the privilige of blogging in our company today. This sends the message that we have a traditional, top-down hierarchy. To our people, it can appear that we don’t value the thoughts and ideas of people unless they happen to be an executive. By opening up blogging to the masses, that all changes. Thought leaders will emerge from any level in the corporate hierarchy. What matters is the value of their ideas, not the size of their pay check.
• Build internal, business related communities of interest that would not otherwise exist. People naturally converge around known likenesses. In a large organization, even the most unusual interests are shared with several other people. Until now, finding those people has been next to impossible. In my own experience there are people scattered throughout our company who are passionate about collaborative technology. Most of them have no idea what’s happening in this space and who is on point. If they had an idea, they wouldn’t know who to contact. By writing a blog, I could begin to biuld a community of interest around collaborative technology. I could share ideas and expect truthful feedback from people were previously invisible to me.
• Allow people to market themselves internally, demonstrate the value they have to offer, and gain status and exposure. We all have the responsibility of marketing ourselves. In the past, each person’s potential sphere of influence was limited by their position in the corporate hierarchy and geographic location. With a blog, smart people can market themselves and their successes much more broadly. However, they need to be careful. No one likes a self-promoting bragger.
• Allow people to subscribe to the blogs that interest them through an RSS reader. Thanks to syndicated content, we don’t need to visit our ten favorite of blogs looking for new posts. Instead we can monitor our favorite blogs efficiently through a single RSS news reader.
• Create an efficient feedback loop between the blogger and readers/subscribers. A blog is not a broadcast, it is a dialog. Blog feedback is a gift. By putting an idea out in the open, a blogger opens herself or himself to feedback from the masses. Almost all feedback has some value, even negative feedback.
• Support openness and transparency when any employees are empowered with the ability to publish content. The executives in our company who post to their own blogs have received extremely positive feedback from their staffs. Employees feel like they now have a direct line to the business leader instead of waiting for messages to trickle down and morph through the management layers. They know that the business leader will read and respond to their comments in public. Almost no front line employee would dare send an email to a CxO. However, commenting on that CxO’s blog feels much less threatening. This sense of openness and transparency grows exponentially when all employees are allowed to blog. Suddenly I’m able to benefit from the ideas of a person across the country who happens to be in a completely different business unit.
• Encourage people to blog internally instead of externally, where the risks to would be much higher. Okay, I know. I’m blogging externally. Ideally, however, we would always prefer employees to blog internally, as opposed to on the Internet. We want to secure our intellectual capital and ensure that our best interests are protected. Most employees will find that an internal blog will satisfy their need to share and build a following. Without an internal option, however, more people will turn to public blogging.
  

Okay, I know what you’re thinking. I’ve still not answered the question of how letting our employees blog will reduce expense or increase revenue? I can’t do that, at least in terms of hard dollars. In my experience, however, the costs and risks are low enough to stand up to soft benefits.

Are there benefits I missed? Have you been built a business case for employee blogging on hard benefits?