Addison Wesley Professional
Portals are a great facilitator of collaboration because they provide the forums and tools for individuals, independent of location, to come together virtually to access and alter a single source of content. Collaboration is not simply content creation but also the means of getting there—the process that people use to work together. Microsoft Office SharePoint Server (MOSS) 2007 introduces a number of new tools to take organizational collaboration to a new level. The tools themselves are not new in concept, but the notion of introducing them and connecting them within corporate firewalls can have a dramatic impact. Moreover, the fact that the tools are so easy to use, combined with the integration with the way people already work, is downright revolutionary. They offer a new paradigm of unstructured knowledge capture. By making it very easy to capture an expert’s thoughts electronically, information that typically goes undocumented or stays in an expert’s head will likely get shared more often, benefiting entire teams if not entire organizations.
Team sites, blogs, and wikis all offer different means of allowing individuals or teams to store, share, and alter structured content (for example, documents) and unstructured content (commentary) in a single environment. It also enables organizations to quickly share information across organizations—for example, a regular communication with suppliers, partners, or customers. The return on investment associated with collaboration initiatives is typically measured with two main metrics:
The ability to effectively store information that was not being documented
The ability to retrieve and reuse that information to accelerate a highly repeatable business process
Collaboration is less a science and more a philosophy. In the business world, it is the belief that providing tools for knowledge sharing offers competitive and measurable benefits.
Getting Started with Collaboration
Why is collaboration difficult? If the results are so compelling, why do so few organizations have good collaboration strategies? The answer is a combination of technology and methodology. Knowledge workers, the individuals within an organization who interact with and execute business processes, need the right tools to allow them to document information that is potentially useful to peers. In that same sense, organizations need to ease rules around content approval in order for this information to flow freely into the knowledge system. It’s actually harder than that. Even with the right tools and permissions, these knowledge workers need guidance on what information is truly useful and where it should go. Additionally, beyond the technology and processes that foster good collaboration, incentive structures need to be in place to encourage knowledge workers to take that extra step to contribute and categorize content for later reuse.
Challenges of Knowledge Placement
The challenge of knowledge placement is significant because most employees have multiple roles around corporate content. An individual can be an employee of the organization, a member of a department, an expert in a practice area, or a contributor on multiple project teams. Each role is associated with different corporate data and business processes. How does one know when to share?
One approach is to segment the multiple levels of corporate information into three main categories:
Organization. This is highest level and represents the collection of all employees. From a content perspective, information at this level pertains to all or most users. It may contain corporate news and announcements, mission statements, human resources and benefits information, and any broadcast information.
Communities. Communities are collections of individuals with similar interests, expertise, or business roles. They can be departments or practice areas. From a content perspective, information at this level is mostly interesting to members. It may contain templates, best practices, white papers, and training materials.
Virtual teams. Virtual teams are small groups of employees who come together for some fixed amount of time to complete an objective. The “virtual” part of this is a new concept to many people. Teams are becoming less fixed and are forming instead to accomplish a set of tasks and then dispersing again.
A team could consist of project members or product teams. From a content perspective, information at this level is very interesting to members and potentially interesting to members of other virtual teams looking to complete a similar objective. It might contain document deliverables, discussion threads, and meeting notes.
Think of your collaborative organization as a hierarchy with users playing a potential role at each level (see Figure 8.1). An individual can have responsibilities at one or more levels. His or her knowledge contribution is based on the role that the user plays within a given virtual team or leadership position. For example, an analyst might be very active in contributing documents and commentary at a project level but has no need to contribute at the organizational level. An executive might not be on any project’s team but needs to understand what the team is doing and offer strategic guidance and vision at the organizational level. One of the biggest challenges around any portal and collaboration strategy is how to take the best work products from virtual teams and communities and expose them to the wider organization once those teams and/or communities have disbanded.
Figure 8.1
A user can play roles at one or more levels of collaborative responsibility within an organization.
Developing a Collaboration Strategy
The first step in developing a collaboration strategy is defining the levels at which you wish employees to contribute. This will help from a security perspective in terms of defining rules around who can or cannot contribute at each level. It will also offer the needed guidance to individuals about knowledge placement within the framework.
The next step is to define the type of content (remember, both structured and unstructured) that maps to each level. As stated earlier, collaboration is just as much about the process of building content as it is the end result. At the virtual team level, as an example, this means providing an environment where members can incrementally write a document, each contributing content and commentary, with all of the steps and results being stored. In addition, collaboration also includes the capability to capture information that indirectly influenced the end result. As an example, this could be research about a set of products that lead to a competitive analysis document. The goal is to tie all this information together into one logical environment.
The final step is tool selection. What is the best way for the CEO to periodically address employees? How can a practice team effectively work together to write a paper on project methodology and share the results of their efforts? How can several team members contribute to the same document and not inadvertently lose changes? This is where we introduce WSS 3.0. team sites, wikis, and blogs. Each maps well to a specific knowledge- capture scenario. The goal is to leverage these tools to meet the specific objectives in a collaboration strategy. To ensure high user adoption, they must be easy to use and easy to access. This is the value that the connected environment of a MOSS 2007 portal offers. It becomes the single source of corporate information. It is an enabler in that it delivers on the objective of making all users consumers and producers of corporate content.
Working with Team Sites
Team sites are not a new concept to SharePoint users. SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 both had site templates to support virtual teams. WSS 3.0 has extended the use of virtual team sites or workspaces by introducing added features and functionality to enhance the collaboration experience for site members.
If you’re unfamiliar with the previous version of SharePoint, team sites are containers that allow you to store documents, lists of data, and other information. Think of it as a file share combined with an Access database, but with lots of additional features. The content that you store may include documents, hyperlinks, custom lists, contacts, and other team data. The value of a team site (remember, this is a small group of peers coming together to complete an objective) is measured at three levels:
Individual. An individual can leverage a team site as a single repository for all team-related material. It is the place to go to get up to speed if the individual joins the team in mid-project, and it is the one place to go to add or access the content generated by the team. An individual can be a contributor to all, some, or none of the content. Security associated with the site, from the page down to the content group (or Web part), is managed by the site administrator.
Team. Teams can leverage a team site as a means of sharing without using email or other methods. Document libraries have version control to monitor changes as well as check-incheck-out to ensure there is always only one active version of a document. Geographically dispersed teams don’t have to struggle with how to share their work.
Organization. All members of an organization can leverage the information within a team site by allowing direct access to all exposed team content. Because sites are template-driven, organizations can ensure that all project or product sites are organized in the same manner, thus giving users a consistent look and feel and a quicker path to finding relevant content.
Getting Started
To create a site for a virtual team, you will likely want to create the site from the MOSS site directory page. The site directory is a special SharePoint list that keeps track of URLs to SharePoint sites along with some information about the site. This is one of the sites that is automatically created for you when using the MOSS Intranet Site template. To navigate to the site directory, click the Sites tab on your intranet navigation (or go to http://server/sitedirectory, which is the default location for the site directory). If you are using WSS 3.0 and not MOSS 2007, you can simply create a new site from wherever you are, but it will not have the site directory available for keeping track of the site you created.
Note – To add categories to the site directory, navigate to the site directory. Then click Site Actions ‘ View All Site content. Then click the Sites list. Then click Settings ‘ Create Column from the toolbar. If you want the category values to appear as “browseable” filters on the site directory page, make sure you use a Choice data type when you create the column.
Use the Site Actions context menu to select Create Site (see Figure 8.2). Note in WSS 3.0 that you will want to do this from the parent site (or the site that will logically represent the level above your new site).
Figure 8.2
Creating a new site from the MOSS site directory.
You’ll see a section for template selection that contains multiple tabs. The first tab is associated with collaboration templates. The first item in the list, Team Site, is selected by default. Team sites and workspaces are very similar, with the concept that team sites are long-lived, while workspaces are shorter-lived and geared toward a specific work task. But in the end they are pretty much the same. Figure 8.3 shows the site creation page. Supply a site title and URL to complete the creation process. Notice that the creation page also allows you to deviate from the parent site security model. This would be done in cases where you want to establish specific permission for site users.
Figure 8.3
Provide a title, description, and URL, and select which template to use.
Figure 8.3 shows the newly created team site. By default, the site contains no data and has a few default Web parts on the homepage. If the site inherited security from the parent (this is the default), the list of site users matches the parent, and the creator of the site is the site administrator and the only person who can access the site.
Note – SharePoint sites may not include the following characters:
/ : * ? ” | # { } % &
. The following characters cannot be used in the naming of files to be uploaded to SharePoint:
” # % & * : ? { | } ~ .
SharePoint file names cannot exceed 128 characters in length.
How Do SharePoint Team Sites Work?
To add users to the team site, use the Site Actions context menu and select Site Settings. The first column is titled Users and Permissions. Click Users and Groups to add more members.
Let’s look at how the default presentation of a team site is organized. The left side navigation gives users quick access to specific lists (things like document libraries, custom lists, and calendars). The main body of the page contains Web part zones (or placeholders for Web parts). Additional Web parts can be added by using the context menu associated with Site Actions and selecting Edit Page. Note that you need specific permissions on the site to do so. Figure 8.4 shows a team site in edit mode. There are boxes around Web parts that allow for drag and drop into other Web part zones. There are also hyperlinks in each zone labeled “Add a Web part” that allow you to introduce a new Web part from the Web part gallery.
Clicking Site Actions ‘ Edit Page enables you to make changes to the shared version of the site, which means everyone will see your changes.
Collaboration within a team site is facilitated with the following out-of-the-box Web parts:
Document Library. A document library is a collection of documents that are organized together based on their subject matter. A document library has specific lists of metadata (or attributes) that it manages for each document in the collection. Default metadata (managed by SharePoint) includes items such as Title, Author, and Last Updated. Users can add metadata attributes (for example, Document Type, Industry, Language, and so on). Document libraries also have two main features related to multiuser collaboration:
Check-inCheck-out. SharePoint enforces rules around document ownership. A document can be edited by any member with proper permissions, but only one person at a time. This is accomplished by “locking” the document while it is being edited. A contributor checks out a document (thus locking it from further edits) and checks in that document when changes are complete.
Version Control. SharePoint also manages all activity around document revisions. If versioning is enabled for the document library, SharePoint stores a copy of each version and maintains a version history for that document. Users will always have access to any version of the document, throughout and after the document collaboration exercise.
Team Discussion. Discussion threads are an effective means of capturing dialog between users. A discussion can be any number of levels deep, with all users participating in responses. The value of a discussion thread versus email communication is that it is logically stored within the context of the team site and can be more easily navigated. In effect, it becomes part of the overall knowledge capture associated with the objective. WSS 3.0 extends the capabilities of the discussion Web part by allowing users to email content directly into the discussion thread. This allows for easier transport of email-based information directly into the team site. A conversation that starts in email can be moved into the discussion Web part if it should be shared with the team.
Tasks. Task lists are an effective way of sharing responsibilities across the team. Members have easier access to outstanding items and manage the state and level of completion of assigned tasks. For highly repeatable project scenarios, a fully prepopulated task list can be part of the default template. For example, a fixed set of tasks might drive a proposal writing project.
Custom Lists. Custom lists are a great place to store “everything else.” Lists can include virtually any data. Remember from Chapter 3, “Introduction to the 2007 Office System as a Collaboration and Solutions Platform,” that we used a custom list to track contributions that people made.
A team site is an effective way to organize content and people around a specific objective. The value is measured not just during the site’s life-cycle but for some time after as other virtual teams can leverage the information captured in the environment to better accomplish their goals.
Working with Wikis
The wiki, which comes from the Hawaiian term for “quick,” has been around for more than 10 years. In its simplest form, a wiki is an online destination where users can freely create or edit Web page content using only a Web browser. The goal of a wiki is to provide a space where members of a virtual community can edit any page, with full freedom to introduce, alter, or remove any content that was created by previous authors. Unlike blogs, which are designed more for knowledge exchange and communication, wikis are designed more for collaboration and creation. In the corporate world, wikis are used to create help desk pages, capture product information, and document research team findings. Consultants use them to drop quick notes about problems encountered in the field.
Much attention has been given recently to the next generation of online tools, dubbed “Web 2.0.” The premise is that barriers surrounding content creation will be lowered, allowing all users to be producers as well as consumers of online information. This phenomenon is true not just in the Internet world but within corporate firewalls and from company to company. Think of it as intranet 2.0—tools that make content creation easier for all employees. Technologies such as blogs and wikis will go a long way in changing how companies think about, store, and recycle corporate knowledge by making all users active contributors to the corporate knowledge base. The hardest obstacle is cultural—most organizations have a hard time with the concept that any employee could update a company Web page at any time.
Getting Started with Wikis
If you’ve worked with SharePoint 2003, the use of site templates should be very familiar. Site templates are a framework for the layout of a particular type of page (for example, a team meeting or social event) that presets placeholders for specific content. WSS 3.0 extends the use of site templates by introducing a new collection of template types. One of these is wiki. Figure 8.5 shows the New SharePoint Site page used to create a page in SharePoint. Notice that the template list has an item for Wiki Site. By selecting this template, you can quickly and easily create your first wiki. Take a look at Figure 8.6, which shows an example of using a wiki to create a community-based how-to and help desk reference. Everything on the site is editable, encouraging users to not only consume information, but contribute as well. The structure of wiki is such that this default page is the homepage. Properly authorized users, your virtual community, can make edits on this page or create new pages.
Creating a new wiki by using a site template definition.
A wiki page enables any user who has access to make edits, encouraging community updates of shared information.
Wikis have existed, on the Internet or through third-party tools, for a number of years. For the most part, however, the use of wikis has been highly specialized and has grown quietly through word of mouth. WSS 3.0 is looking to change this by promoting and offering this functionality to all intranet users. This is a very powerful (and potentially scary) proposition! How do you explain the value of a wiki to a nontechnical, nonInternet- savvy coworker? Don’t think of a wiki as simply content collaboration. The end result is not a document. In fact, a wiki is not a document or a chapter but rather more like a never-ending book. It’s like a book written by a group of authors (versus one author), each one building on what the others have written. It is intended to foster creative exchanges of opinions and ideas in an environment that is free enough to offer all users a voice. It’s not an idea that applies to every content creation exercise, but it is a powerful tool in the right circumstances.
For first-time wiki users, online guidance is available via the How to Use This Wiki Site hyperlink. Figure 8.7 shows that the default Wiki template comes with sufficient documentation to get new users comfortable and contributing quickly.
Figure 8.7
Online help for first-time wiki users.
How Does a SharePoint Wiki Work?
On every wiki page, you will notice action buttons on the upper-right side. One of them is labeled Edit. By clicking this link, you are directed to the page associated with content editing. Figure 8.8 shows an example of an edit page. It is important to point out a couple of key things. The first is that all editing happens in the browser. There is no use of external tools, such as Microsoft Word. All edits happen online and in real time (once saved). The second point is that no technology or Web design skills are required. The edit interface allows for full rich-text creation (such as bolding, color, bullet points, or images), all with the use of standard buttons. No HTML skills are required. A user simply opens an existing page in Edit mode and adds or edits content.
Figure 8.8
Making edits in a wiki environment.
In an environment where content is always evolving, how do you manage the changes? While you may not necessarily feel the need to police all contributions, you probably want some means of maintaining a version history and tracking changes. WSS 3.0 wikis offer that. Figure 8.9 shows what a standard page looks like after you click the History button. In the center, you’ll notice that all edits to the text have been tracked (from original to current). On the left, you can see the history of changes, tracked each time a change was made, with auditing for who made those changes. The community has full power to review, track, and even roll back changes as needed. This is a powerful concept. As you’re building and changing, WSS 3.0 is tracking that movement.
Figure 8.9
Version history in a wiki environment highlights content that was added, deleted, and changed, providing a way to see what changes were made when and by whom.
Here’s one last point: As mentioned earlier, a wiki is not your typical Web page. It is a collection of limitless pages. As a member of a wiki community, you might decide to introduce a new idea or discussion point. The best way to do this is to find an existing page that makes sense to link to your new topic, adding it with double brackets ([[new term]]). This creates a link to a new page that doesn’t exist yet. Click the new term and you are taken to a new, clean page that can host content about your newly created topic (see Figure 8.10). Start adding content, and you’re well on your way!
Figure 8.10
A new wiki page.
While WSS 3.0 does not introduce the concept of a wiki, it does make wikis, given their wide availability, much more available. They are now built into your existing framework—automatically part of your existing portal environment, enterprise search, and so on. Wikis will transform the way information workers collaborate as they are no longer bound by the limits of a document. Wikis encourage unstructured thinking and broader collaboration. This also folds nicely into the broader concepts associated with the intranet 2.0 philosophy. Wikis are enablers; they allow all users to participate and not only follow along but forge new paths.
Working with Blogs
Blogs (from Web logs) are a very popular tool on the Internet for individuals to share knowledge and opinions in a public forum. While many blogs on the Internet seem somewhat personal and random, in the business world, they have become a prime source of information on specific topics, and bloggers have become public-facing gurus. WSS 3.0 introduces the blog site template as a means of initiating knowledge capture at the individual level within corporate firewalls.
With wikis, we talked about communities and contribution sharing in an open forum. Blogs have one source—the author. The subject matter associated with a specific blog is usually limited to a collection of few topics. The blogger is the expert. He or she shares experiences and opinions in the first person. The value of a blog is measured in the quality of the content and the capturing of information that can accelerate repeatable tasks. Blogs can be used both internally and externally. Sometimes blogs are an email replacement—you can post a blog entry instead of sending a note to your team. That way, it’s easy to find later. It can also replace a regular newsletter that goes out to customers or partners. It’s also a great way for an expert to capture random thoughts about a current assignment. In other words, blogs are a way of communicating to the rest of the organization what people are working on.
Getting Started
As with wikis in the previous section, WSS 3.0 provides a template for blogs. Figure 8.11 shows the New SharePoint Site page used to create a page in SharePoint. Notice that in the template list there is an item, Blog. By selecting this template, you can quickly and easily create your first blog. Take a look at Figure 8.12. This is the default view of a blog site. The author can add content right away.
Creating a new blog site by using a blog template. You can create blogs from the site directory, from a top-level (or any level) site, or from a user’s MySite.
Figure 8.12
A blog enables a user to informally convey information and allows users to subscribe using RSS feeds.
How Do Blogs Work in SharePoint?
For first-time blog users, online guidance is available via the How to Use This Blog Site hyperlink. Figure 8.13 shows that the default Blog template comes with sufficient documentation to get new users comfortable and contributing quickly. Writing a blog is easy. You simply add text in a rich-text box and are allowed to tag the entry with a specific category so that all your similar blogs can be grouped. The left side of Figure 8.13 shows the category listing.
Figure 8.13
Adding a blog post.
Figure 8.14 shows an example of the more advanced features of blog creation—specifically, managing categories for blog postings. Bloggers can manage the permissions and content associated with their blogs. For those using Word 2007, bloggers can actually write and post blogs directly from Word.
The SharePoint Blog template enables you to manage categories for your postings. The categories are simply a list within the Blog template.
Note that an individual does not need to be limited to a single blog. In a highly collaborative organization, contributors have multiple roles and therefore manage different types of corporate content. An individual can have a blog associated with a team site that is dedicated to his or her work on a particular project. That same individual might have another blog to share thought leadership ideas within a particular practice area. The goal of the blog is to give the author a forum for information sharing. The great thing about WSS 3.0 is that it facilitates this sharing and connects all the content back to the original source.
WSS 3.0 provides the capability to set up a blog site quickly and easily. Within the corporate environment, blogs give subject matter experts a way to talk about what they know in such a way that all interested parties can benefit. People can monitor others’ blogs that are aligned with their interests. Blogs can persist over time and provide a way for the organization to capture what people know and have it available even after the author has moved to another company.
Putting It All Together
At this point, you have appreciation for how team sites, wikis, and blogs work within a MOSS 2007 environment. The challenge from a collaboration perspective is putting it all together. This means deciding what tool works best in specific collaboration scenarios. In addition, there is the notion that an individual may participate in multiple collaboration efforts and therefore have access to the same tool in different sections of the knowledge hierarchy. Complicating this further is the desire at the corporate level to “manage” this information. How do we put this all together?
Think back to the beginning of this chapter, and take a look at Figure 8.1. While we can define three main levels of corporate content, in some ways, this picture is different for every employee. Let’s consider three scenarios:
Knowledge Worker
Job
Execute specific business processes
Work independently and on teams at a project level
Build expertise with tenure
Collaboration Points
Contribute to project deliverables
Share lessons learned and best practices
Act as an expert when needed
Tools of Choice
Team sites at the virtual team level
Wikis at the community or virtual team level
Blogs at the virtual team level
Practice Area Manager
Job
Define specific business processes
Lead teams
Set strategic direction
Collaboration Points
Contribute to methodologies
Share lessons learned and best practices
Tools of Choice
Team sites at the virtual team level
Wikis at the community level
Blogs at the community or organizational level
Executive
Job
Define business strategy
Set plans and initiate action
Highly knowledgeable
Collaboration Points
Thought leadership
Influence direction of practice areas
Tools of Choice
Blogs at the organizational level
Here we have three different employees, each with his or her own role and responsibilities. The role sets the participation in the collaboration process. Yet everyone is participating. That’s the goal! MOSS 2007 provides the core set of tools across the employee base to effectively capture and store corporate knowledge—in one place. This makes data highly accessible and reusable. Built around these tools is an environment that is template- driven for consistency and highly secure.
Creating a Highly Collaborative Environment
How do you create a highly collaborative environment? It’s not enough to simply install WSS 3.0 or MOSS 2007 and make the templates available. You need a plan. You also need a few restrictions. Here are some key points:
Have a collaboration strategy. Identify what information is useful and where it is best captured.
Identify the owners of the information and enable them, with collaboration tools, to share and exchange information—freely.
Place few bounds on collaboration. Enable bloggers and wiki contributors, and then step out of the way. Communities are self-policing.
Reward contributions. Have a system to measure the value of knowledge captured.
Flow the collaboration strategy back into corporate training to keep fresh eyes on the content. Enable trainees to be contributors.
Key Points
Blogs, wikis, and team sites can be useful collaboration tools in an organization. This chapter has provided some fundamental information regarding the use of SharePoint for collaboration. In summary:
Providing collaboration to employees using SharePoint team sites, wikis, and blogs may seem simple, but you should back it up with an organizational strategy.
Have a collaboration strategy that enables all employees to participate.
Understand the differences and the value of team sites, wikis, and blogs to logically map them to corporate data collection.
Set few bounds for knowledge capture. Enable knowledge workers to contribute freely and build a portal around the data to take advantage of MOSS 2007 navigation and search capabilities.
Copyright © 2007 Pearson Education. All rights reserved.
