Although this book is packed full of solution examples and plenty of code, I've always thought it is important to frame the context of these solutions inside of the business environment they target. A successful SharePoint solution must take into account the overall direction Microsoft is going, the vertical marketplace in which your organization operates, and the willingness of end users to adopt new technologies. Therefore, I'll indulge in a little digression from my charter in this chapter. If you're just dying for some code, flip to the middle of the book and breathe deeply. Then come back and take a few minutes to read this chapter and think about the environment in which you are deploying SharePoint.
Before I begin a discussion of the details, I want to point out that the term SharePoint does not actually refer to any particular product or technology. Instead, it is an umbrella term that hangs over several products and technologies that have specific names. In general, however, most people use the term to mean any solution based on either Windows SharePoint Services (WSS) or the Microsoft Office SharePoint Server (MOSS). This is how I will use the term throughout the book, even though many Microsoft people frown on this usage.
The 2007 release of SharePoint and the Microsoft Office 2007 suite marks a significant milestone in the effort to create a single unified platform for information-based work. This is the third version of SharePoint products and technologies to be released by Microsoft, and it is substantially more powerful than any of its predecessors. Over the next three to five years the effect of this release will be felt by all organizations that have an infrastructure based on Microsoft technology.
As of this writing, the market for enterprise collaboration software is somewhere in the neighborhood of $1.5 billion and is projected to approach $2.5 billion by 2010. By all accounts, SharePoint products and technologies have the largest number of licensees in this market, with volume exceeding 30 million. However, these numbers don't tell the whole story because this release of SharePoint and Office clearly extend beyond the market for enterprise collaboration into areas such as content management and business intelligence.
WSS is at the core of SharePoint and can rightfully be considered enterprise collaboration software. However, MOSS goes well beyond this narrow definition. MOSS is a superset of WSS functionality and includes sophisticated publishing, business intelligence, and workflow capabilities. Using MOSS, organizations can not only create collaborative spaces, but can also deploy departmental intranets, public-facing Internet sites, business intelligence dashboards, formal workflow processes, and enterprise-wide search capabilities. My point is that SharePoint products and technologiesparticularly MOSSactually embody what were previously three or four separate products crossing three or four different market segments. This is why I believe that SharePoint products and technologies will have such a massive impact on organizations that choose to adopt them. Therefore, it is important to consider the people, systems, and processes into which SharePoint will be deployed. In the following sections, I present a loose framework for understanding the roles of people within a typical organization and the challenges they face, and how various SharePoint solutions may be applied.
These days everyone talks about the "knowledge economy" and "information workers." These terms were used originally to acknowledge that many economies were moving away from traditional manufacturing toward the management of information. As globalization continues to take hold, however, we are realizing that everyone needs better management of information in order to compete effectively. In fact, we now see that most workers use information within the framework of a business process, regardless of their jobs. Everyone from the controller analyzing financial data to a repair crew with a work order on a wireless device is an information worker. When building solutions for these information workers, however, it is useful to segment them into three different groups so we can better understand their needs: transactors, professionals, and executives.
Some information workers use a single line-of-business system all day long. This group is known as transactors. Transactors are front-line workers who often create or enter data into systems. For example, a designer using a computer-aided design (CAD) system to create a model is a transactor. The designer primarily uses the CAD system all day and creates new data used by the organization. Customer service representatives in a call center are also transactors. They primarily use a single system all day and enter new data about customers. Because other information workers rely on the new data produced by transactors, this data must be effectively integrated into any SharePoint solution so that it becomes available to support business processes.
Professional information workers must access multiple line-of-business systems and may use any number of them throughout the day. They have access to customer data systems, product data systems, and financial systems. Their primary work environment, however, is usually the Microsoft Office suite. Professional information workers are generally sending e-mail, writing documents, or building spreadsheets. They often log in to a line-of-business system, but they do it primarily to retrieve information so they can continue to work in an Office product. The classic example of a professional information worker is the controller who logs into a financial system simply to copy data into an Excel spreadsheet for analysis. The goal is to create a financial model in Excel, but the data is in several different systems. In fact, many professional information workers have essentially become "human middleware" that glues together seemingly disparate information from multiple sources into a single document. Eliminating human middleware is one of the primary goals of any SharePoint solution.
Executives must monitor and adjust business processes based on key performance indicators (KPI). These KPIs tell the executive information worker whether the organization is healthy and functioning correctly. When KPIs indicate that a business process is not healthy, executives must be able to analyze information in order to adjust the business process. Delivering KPIs to executives in a way that supports managing organizational performance is a key part of any SharePoint solution.
Another useful way to think about information workers is in groups of various sizes. This means giving consideration to the needs of the individual all the way through the larger organization that includes partners and customers. This is because all information workers accomplish their tasks in concert with others. Therefore, any solution you create with SharePoint should properly address these groups.
Understanding the needs and behaviors of individuals is perhaps the most important requirement for success in any project. Projects that fail do so most often because individual users fail to adopt the new system. Even if everyone believes the end users would be happier and more productive using the new systems, they often fail to change their habits. Because of this, it's appropriate to ask "What do individual users want?"
I think the short answer is a simple and repeatable way to get their jobs done. Most end users are not enamored with technology and see change as an impediment to their productivity, even if that change would eventually result in a better experience. Practically speaking, this means simplifying the virtual environment. Successful solutions will provide clean and obvious interfaces that end users can utilize to access the most important documents, information, and applications.
Although MOSS provides a specific type of site, called My Site, that is intended for individual productivity, adoption of this capability has been limited in my experience. Users overwhelmingly prefer Microsoft Outlook as their primary interface to the enterprise because e-mail is such an integral part of their day. To this end, Microsoft Outlook 2007 has many enhancements that make it a much stronger tool for individuals working with SharePoint products and technologies. I discuss these enhancements throughout the book.
As you move from the individual to a team, the dynamics of system adoption change. Because teamwork is done in a more public setting and under the guidance of a leader, it is easier to get a team to adopt new ways of working. Therefore, you have a better opportunity to make improvements.
Departmental teams typically consist of a small number of people (less than ten) working together to accomplish a goal. The goal is usually limited in scope and easily understood by the team. These types of teams typically struggle, however, with communications and collaboration. Task management and information sharing are the primary areas of need. This, of course, is a historical sweet spot for SharePoint.
At the divisional level, information workers tend to need broad categories of information that help them understand their roles in the larger organization. The type of functionality found here includes access to vital line-of-business systems, work processes such as purchasing, and information pertaining to related divisions. Additionally, management at this level becomes more complex and requires some form of electronic reporting. SharePoint solutions at this level often consist of document management, dashboard, and searching capabilities that aggregate information from many sources.
At the enterprise level, information workers are typically dealing with policies, practices, and regulations that govern their work. At this level, management communication and guidelines are critical to bind the various groups together. Furthermore, individual information workers do not spend much of their day working at this level. They might receive an e-mail from the corporate president or read a newsletter online. SharePoint solutions at this level often take the form of intranets.
Reaching beyond the boundaries of the organization to involve partners, suppliers, and customers is becoming increasingly critical. This level includes marketing, sales, support, and shared processes with partners. While these things were possible with previous versions of SharePoint, the capability was not strong. With the latest release, MOSS can be used to create a complete public Internet site as well as a secure extranet site for customer or partner interaction.
Global competition, or globalization, is now the major economic force shaping business decisions. The traditional long-term relationship between companies and their employees is extinct. Companies are constantly looking for ways to make employees more productive in an increasingly competitive marketplace, cut costs, and improve productivity. For their part, employees are typically less loyal to their companies. Today's employees are just as likely to start their own businesses as they are to bring new ideas to their employer. At the same time, technology is creating an increasingly complex work environment. All of these factors combine to create special challenges for businesses and information workers around system complexity, information, processes, collaboration, access, and management.
When the desktop metaphor was introduced, it offered a simplified mechanism for interacting with a new, complex, and often scary appliancethe personal computer. The success of the desktop metaphor was that it simplified interaction with a computer. Nontechnical people were not required to learn complex function key combinations in order to use the computer. This metaphorand, above all, its simplifying effectwas responsible for the success of graphic operating systems.
Early on, of course, there were several operating systems from several vendors that used the desktop metaphor. Each of theseApple, IBM, and Microsoftwere competing to dominate the personal computer market. As a result, vendors began to include more functionality in the operating systems. Instead of just a file explorer, computers were loaded with all kinds of applets for managing every aspect of the computer. Vendors even shipped the computer with simple games that became a standard part of the operating system.
Later, after Microsoft had established clear dominance with Windows, it used the operating system to compete against other companies that introduced new technologies. The most famous example of this is the fight over the Netscape browser. Ultimately, Microsoft was found guilty of using its operating system to unfairly compete against Netscape. However, the constant fear of a small rival suddenly taking over the marketplace has consistently driven Microsoft to add more and more features to its operating system. As a result, the typical desktop is now awash in functionality. You not only have every line-of-business application you need to do your daily job, but you also have CD players, DVD players, and games. You have three or four different document editors available to you. You have two or three ways to get e-mail. Applications have followed suit as well by adding more and more features, reports, and integration points. The desktop and the applications it hosts are complex all over again.
Along with mounting complexity, information workers are also faced with a lack of standards for application behavior and integration. The most obvious example of this problem can be seen in the use of passwords. Users are now forced to maintain upward of ten different sets of credentials to access all the client-server, browser-based, and Internet applications they need on a daily basis. Typically, each of these applications has different rules for password length and design. The result is that users are unable to remember all of their credentials without recording them somewhere, which threatens the entire network security system.
Not only must information workers manage several sets of their credentials, they also must have intimate knowledge of the data sources utilized by applications. A typical example of this intimate knowledge is when an application login screen prompts an information worker to select the database or domain he or she wants to access. This seemingly simple request actually forces an end user to understand the network topology of the organization. This is an unnecessary burden to place on an information worker. This same intimate knowledge is also required to access file servers, mapped network drives, and printers.
Considering the three categories of information workers reveals that most organizations are structured in a manner that only supports transactors. Because transactors work primarily with a single line-of-business system, they can easily log in to one system and be productive throughout the day. However, professionals and executives face a chaotic environment that actually works against them because they require information from multiple sources synthesized into documents and reports.
Because the information that professionals and executives need to support the organization is locked up in separate isolated systems, they tend to work around the systems by getting much of their information from other human beings. I find that most people will spend some time looking through systems for information, but they rapidly become frustrated and simply send an e-mail to the person they think is most likely to have a copy of the information. Typically an e-mail is sent with a query such as "Can you send me the link to that file again?" or "Do you have the latest document template?" The response to these queries is usually an e-mail with a hyperlink embedded or a document attached. The e-mail is then stored in the recipient's personal Outlook folder so he or she can use it again in the future. This situation results in information workers becoming what I call "human search engines."
I once worked with a company that hired a consulting organization to help it create formalized procedures for its information workers. The consultant that was leading the project did a great job identifying the processes, documenting the procedures, and creating the documents. Additionally, he created a special filing system on a network drive to store all of the procedures. The only problem was that no one understood the filing system except him. At the end of the project, the company was forced to hire the consultant as a full-time employee simply to help other people locate the various process documents. In fact, I can testify that this person has no other job than to receive requests for documents and respond by sending copies attached to e-mail. This is a true human search engine. How many of these do you have in your organization?
While many organizations have defined some level of business process, most organizations have no way to support it beyond attaching documents to e-mail. Professionals who are creating documents and spreadsheets typically need some form of review and approval, so they simply attach the document to an e-mail for routing. Recipients who are involved in the review and approval process have no formal mechanism for tracking comments or minding versions of the document, so they often respond by sending e-mail with suggested changes, comments, or observations. The document creator must subsequently synthesize all the mail into a set of changes and route the document again.
Nearly all organizations can force the processes to work, but the processes never improve. The people involved in the process will continue sending e-mail, attending meetings, and working late until the document is completed and approved. However, two problems result from this approach. The first problem is that the organization typically loses all of the historical knowledge generated in the process. This means that when a similar document is created, the organization cannot benefit from any previous work. The inefficient process is simply started all over again. The second problem is that the inefficient process delays the time to market. Organizations may miss critical deadlines, work overtime, or hire additional people as they wrestle with an unsupported, chaotic process.
Increasingly, information workers are being asked to work on teams where the members are located in other geographies and time zones. However, most organizations have no means beyond e-mail to facilitate the work of these virtual teams. Consequently, e-mail is functioning not only as a process engine, but also as a collaboration tool. You can see this in the dozens of conversational e-mails you receive every day. A large part of all corporate e-mail traffic is being used to facilitate collaboration, reach consensus, and make decisions.
More recently, many organizations have adopted some form of instant messaging system to try and cut out the conversational e-mails clogging the system. Unfortunately, for most information workers, however, this has become yet another task master demanding attention. Because it is so easy to send an instant message, I often see desktops full of multiple conversations. Furthermore, many of these conversations are not urgent, but they constantly interrupt the information worker with sounds and pop-up windows. The result is that low-level conversations actually get more attention because of the intrusive nature of instant messaging.
Just as organizations lose information when they use e-mail as a process engine, the same thing happens when e-mail is used as a collaboration engine. Information is duplicated in e-mail messages sent to multiple recipients, and no one really knows which copy is the true working version. When comments come back from recipients, they must be placed back in the original document by hand.
Along with facilitating collaboration, e-mail also serves most people as their global task list. When I describe e-mail as a global task list, I am referring to the practice of keeping an e-mail as a reminder to take an action. You might, for example, keep an e-mail from a customer as a reminder to follow up on a sales opportunity. It doesn't even matter if the e-mail you keep has anything to do with the action you want to take. Keeping the e-mail makes you think about the customer and reminds you to follow up.
People use their e-mail as a global task list because they have no other tool that shows them all the tasks they have to perform for an organization. But this results in the average professional information worker having dozens or even hundreds of e-mails in their inbox with no organization or prioritization. Add your instant messages to that burden and you'll do nothing except answer mail all day.
Along with e-mail, shared file systems are often routinely misused to facilitate collaboration. Nearly all organizations have some form of shared file system that is made available to information workers for storing documents. In most cases, the information workers have complete read/write access to these servers. They can create directories and save documents at will. Unfortunately, once a file server is open to information workers, it quickly becomes a chaotic mess.
Most file servers are exposed to information workers as mapped network drives. Information workers can access these drives directly from their own computers and are encouraged to store critical files on the drive so that they can be properly backed up. However, the directory structure of these file servers is a nightmare. No one can remember where they are supposed to create new directories and often don't remember where they have previously stored a file. This results in different versions of the same file being stored in several directories with no one able to determine which one is the most recent.
Increasingly, information workers are working from locations other than the central company headquarters. Workers today are highly mobile; they work from home, they work from the road, and they work from other countries. They need constant access to systems even when they are completely disconnected from a network. Information workers carry BlackBerry devices, smart phones, and wireless computers. Partners and customers increasingly expect to be able to access appropriate information contained in your systems. All this means that solutions built for information workers must have a well-conceived access strategy that exposes information to the appropriate audience.
As if the complexity and variety of information systems were not enough, organizations are also faced with an explosion of data contained in these systems. A typical organization might have as many as eight customer databases crossing several isolated systems such as customer relationship management (CRM), enterprise resource planning (ERP), multiple spreadsheets, and documents. Each of these systems has a reporting mechanism to access the data, but there is generally no way to see all of the data together to create a single view of a customer, a supplier, or a partner. Consequently, organizations are forced to create manual systems to collect and analyze information.
Executive information workers need visibility into business processes in order to judge the health of the organization and make adjustments. This process of analyzing KPIs against goals followed by adjusting the business processes is known as performance management. Most executives really have no effective means beyond simple reports to manage the organizational performance. Furthermore, these reports are often nothing more than spreadsheets created by professional information workers who route them to executives via e-mail. As a result of this situation, many executives have simply given up trying to proactively manage organizational performance. Instead, they examine financial data and try to make strategic adjustments after the fact.
All of this is to say that the computing environment for most end users has become unbearably complicated. In this environment, end users are crying out for simplicity and consolidation. They need tools that give them a more personal view of enterprise resources to cut through the layers of complexity and make them more productive.
Stop for a moment and consider the role of Microsoft Outlook in most organizations. Microsoft Outlook is truly the workhorse of corporate America. Outlook is often the first application an end user opens at the beginning of the day and the last one closed at night. Why? The answer is because end users are trying to impose simplification by using Microsoft Outlook to access their enterprise resources.
Think about it. Your organization may have a document management system, but you generally get your documents as e-mail attachments. Your organization may have an enterprise reporting system, but you get your reports through e-mail as well. This is because end users do not want to use the document management client or wade through the hundreds of reports available in the enterprise reporting system. These systems are too painful to access and too complicated to use. What's more, the end user has probably forgotten her password for the document management system and isn't about to spend 30 minutes on the phone with the help desk to get it reset.
System complexity and variety, overwhelming amounts of data, and work-style challenges have all led end users to a frustrating relationship with their computers. They are begging for simplification, but each new effort rolled out by the IT department only seems to add to the problems. The key to solving this problem lies in creating a user experience that truly consolidates and simplifies.
No one in business has to be told these days about the impact of regulations. This is especially true if you are part of a public company, but it is increasingly true for everyone. Not only is compliance a necessity, but organizations must also be much more vigilant about identifying and maintaining records so that they are available for audit or discovery. This has become a significant problem in a world where e-mail is functioning as a process and collaboration engine.
Most organizations have no effective way to understand what information is contained in their e-mail systems. Yet, estimates are that as much as 50% of all organizational knowledge now resides in e-mail inboxes and public folders. For organizations trying to comply with record retention regulations, this is an impossible situation. There is no way to know what e-mail is important, so many organizations simply save it all. This is a massive amount of information to store and will be nearly impossible to search later.
SharePoint products and technologies form a versatile set of building blocks that you can use to solve a variety of business problems. Unlike most technical solutions, however, a SharePoint implementation has the ability to transform the way in which an organization works. This is because SharePoint touches nearly all aspects of daily operations. SharePoint solutions can bring together information in the form of documents, forms, records, scheduling, communications, transactions, and reporting. This information can then be delivered to employees, partners, and customers.
Perhaps the most obvious and straightforward scenario involving a SharePoint deployment is the improvement of personal productivity for employees. I have already addressed in detail the system and data challenges that are facing users of the Windows desktop, but a productivity solution based on SharePoint products and technologies can also be used to make relevant applications, documents, and data available to end users more quickly.
The typical end user spends a significant amount of time searching for documents and information each day. This is essentially lost productivity, while users browse document management systems, reporting systems, or the Internet. Documents are easily lost on file servers because no standards for file taxonomy, naming, or version control are in use. What's more, business users are often frustrated by technical barriers such as mapped network drives or server names.
A SharePoint solution can bring immediate relief to this situation through the use of enterprise search capabilities. MOSS ships with an enterprise search feature that allows you to search nearly every information repository in your organization. This includes documents, people, databases, and web sites. Figure 1-1 shows a view of the Search center with results.
Along with personal productivity solutions, SharePoint products and technologies can also create team productivity solutions. Increasingly, team productivity is a vital part of business success. Today, most organizations have some combination of formal teams and ad hoc teams. The formal teams are often fixed and departmentalized whereas the other teams may form spontaneously or for a limited time. SharePoint products and technologies support both kinds of teams.
Because formal teams are generally long-lived, a SharePoint solution may contain several fixed sites for these teams. These sites may be created during an initial rollout and then enhanced over time. For these types of teams, SharePoint Portal Server (SPS) supports both document and meeting workspaces where team members can collaborate even if they are not physically present. Along with meetings and documents, team members can also take advantage of threaded discussion forums that facilitate collaboration even if team members are not present in both time and place. Figure 1-2 shows a typical team site in WSS.
Ad hoc teams can benefit from the same collaborative features enjoyed by formal teams, but the sites that host these groups may be created on the fly. SPS is a truly decentralized model. The philosophy is intended to support team building and productivity from the boardroom to the company softball team. A collaborative solution focused on team building may give site-creation permissions to many individuals who can then easily create team sites from directly within the portal.
At the division and enterprise level, SharePoint products and solutions can be used by management personnel to better understand performance and make adjustments. Figure 1-3 shows a management dashboard created in the Report Center. The Report Center is designed to be the single place in the enterprise that provides information on organizational performance.
Beyond performance management, SharePoint sites can also be used to improve communication within the organization. This can be accomplished by using SharePoint as the basis for the corporate intranet. In support of this role, MOSS also has special publishing capabilities that allow intranetand Internetcontent to be created, routed, approved, and published.
Increasingly, the concept of a central place where employees commute to perform work is fading. Organizations today have more telecommuters, distant offices, and mobile workers than ever before. For organizations, this has typically meant an increase in support costs. Remote workers often require high-end laptops, remote synchronization, wireless connectivity, and more client-side software. Using a SharePoint solution focused on remote workers, organizations can eliminate some of the maintenance required to support them.
Solutions built around SPS may be made accessible outside of an organization's firewall. Using this type of approach, an organization can make sites and services available to employees as long as they have an Internet connection. This means that telecommuters can easily access required resources with less software installed on their local machine. For mobile workers, such a solution can ease the burden of data synchronization by integrating such operations within the portal. Figure 1-4 shows a SharePoint solution running on a mobile device.
Because SharePoint solutions can be safely exposed outside the firewall, they make excellent platforms for integrating with customers and partners. SharePoint now supports forms-based authentication so that external users do not have to be members of the organization's domain in order to log in. This means that you can place an entire SharePoint site within the DMZ and safely publish information for partners and customers. Figure 1-5 shows a typical SharePoint login form.
Records management has become an increasing concern for organizations that need to comply with regulations. Identifying critical e-mail and documents, applying retention policies, and protecting documents from change are all key parts of a record management strategy. In this version, MOSS provides a record repository template that you can use to store and control key documents. Documents can be sent to the repository manually or as the result of a workflow process. When documents expire, they can be automatically deleted or initiate a workflow process. Figure 1-6 shows an example of the records repository in MOSS.
SharePoint can be remarkably easy to install. In fact, if you follow the single-server deployment strategy, you can have SPS up and running in 45 minutes. However, that does not mean that it is simple to create an effective business solution using SharePoint products and technologies. The key to properly designing a SharePoint solution is to spend the required time to identify the business problem to be solved and the expected result. Once you understand the solution, you must document the roles, policies, and systems that constitute the solution. Finally, you must design a solution that incorporates all of the elements in a way that solves the original business problem.
For as long as I have been involved in designing software solutions, teams have always agreed in principle that identifying the business problem and understanding the return on investment (ROI) are critical to the success of every project. However, I have rarely seen a team actually engage in these activities, and in the end, this often is a leading factor in the failure of a project.
Shortcutting required analysis is a fact of life in the information technology world, and it is driven equally by managers and engineers. On the management side, project sponsors are frequently unable to articulate the expected return from a technology project. When interviewed, managers are incapable of explaining the productivity increases or cost savings that are expected from a technology effort. Instead, they rely on a vague feeling that the mere presence of a tool, or portal, will surely help the organization be better.
On the technical side, most engineers are not trained to look at technology issues as essentially business problems. Instead they look at business issues as primarily technology problems. The typical technical thought process asks the following question: What data does the end user need? Then it asks this: What application provides that data? The solution then is to deploy the application that provides the data and declare the problem solved.
A solution based on SharePoint products and technologies is a web of solutions to a myriad of problems. Organizations considering such an implementation would do well to begin by interviewing key project sponsors to document the expected company benefit from such an effort. Sponsors should be clear about the expected productivity increases or cost savings associated with the effort. Use this exercise as a litmus test for the entire project. If a significant return cannot be envisioned for the project, it may not be worth the effort.
If the return is determined to warrant the project effort, the correct process is first to create a vision document. The vision document is the first deliverable of the project. This document articulates the business problem, proposed solution, and expected benefit. This document is the highest-level guidance for the project. It acts as the beacon to which the team is headed. In well-run projects, the vision is periodically revisited to ensure that no extraneous effort is expended and that the team is correctly implementing the vision and achieving the desired results.
Once the vision document is completed, the next step is to document the policies, practices, and regulations that will constrain the use of the solution. Policies, practices, and regulations act as boundary conditions for the solution. Successful projects exist within these boundaries while solving the original business problem.
Policies are restrictions placed on the organization by its management and articulated as simple statements. For example, the statement "company credit cards are not to be used for personal expenses" is a policy that restricts the use of a company credit card. Similarly, the statement "only port 80 will be open on the firewall" is also a policy. This policy restricts the use and configuration of the company infrastructure. Policies are not easily changed; therefore, a successful project must identify the policies that constrain it.
Practices are similar to policies in that they act as boundary conditions on the solution design. However, practices are more closely associated with the tactical processes used by the organization to do business. For example, the use of an approved vendor list to simplify the purchase process is a practice. Practices are less formal than policies, but they can easily be just as limiting on the final design.
Policies and practices exist at many levels in an organization. Some policies may apply to an entire organization whereas others may be specific to a single process. Initially, you should try to identify the policies and practices that are most likely to constrain the general use of a solution. As the effort matures, you will identify departmental processes constrained by additional policies, practices, and regulations. As a starting point, consider the following common areas where policies, practices, and regulations may affect the initial deployment: allowing external access, negotiating service-level agreements, accessing the application, managing content, and addressing regulatory requirements.
Allowing External Access
If external access will be allowed, then document the policies for authentication. Determine whether a simple username and password will be sufficient, or whether stronger measures will be required. Specifically, you should determine whether Secure Sockets Layer (SSL) and certificates will be required.
Along with system policies, determine whether users will be required to access the solution utilizing a two-factor authentication system such as RSA SecurID. SecurID tokens act as virtual ATM cards for the portal. In order to access the portal, users must possess the token and know a personal identification number (PIN). The passcode generated by the token changes every 60 seconds, so a user must be in possession of the token at the time of login. The PIN is a fixed set of numbers known only to the user. The combination of these two elements to complete a login request is the reason it is called two-factor authentication. When combined with SSL and certificates, such access schemes are exceedingly hard to hack.
In addition to considerations about personnel access, you should document policies for system deployments. Determine what parts of the system will be deployed behind the firewall or in a DMZ. All of these issues arise early in a development project and will affect the final design significantly.
Negotiating Service-Level Agreements
Based on the business vision, you should determine the expected availability for the solution. If the solution is functioning as little more than an intranet, perhaps no significant impact will occur if it goes down. On the other hand, some organizations are utilizing the portal as the primary workspace for employees. In this case, a formal service-level agreement should be negotiated for the system.
Along with a service-level agreement, the solution may have to be part of the disaster recovery/business continuity plan. Again, based on the business vision, determine whether the criticality of this system warrants a replicated site on the disaster recovery network. If so, make disaster recovery an integral part of the project plan. I have seen many organizations ignore this point and roll out a solution as "just a pilot." These same organizations turn around a few months later and realize they have a single point of failure in their system architecture and a gaping hole in their disaster recovery plan.
Accessing the Application
Determine the policies and practices you will use to provide application access. This includes both internal and external access along with the method of authentication. Additionally, the Microsoft vision of SharePoint incorporates tight integration with Office 2007. If this is in line with your company vision, you must evaluate your current Office deployment. Give thought to any planned upgrades and how you will handle installation and maintenance on the client machines.
Managing Content
Documents and other content are a significant part of a SharePoint solution. Therefore, organizations must document the policies and practices that determine how the content is created, posted, and managed. Determining the policies and practices surrounding content will have a lot to do with the culture of the organization. In its heart, SharePoint is a distributed solution. This means that it is structured to allow easy content creation and posting. Additionally, sites and subsites can be created without necessarily requiring centralized approval. Many organizations find this philosophy incompatible with the traditional centralized approach to information technology.
Administrators do have significant control over permissions granted to portal users; however, every organization will have to determine which people will be responsible for creating and maintaining content. This may be a formal system where each department has a content manager, or it may be a freewheeling approach that lets nearly anyone create a site on the fly and populate it with relevant content. In any case, you should consider these issues carefully before you begin designing the portal.
Addressing Regulatory Requirements
SharePoint solutions allow you to create and manage content through its entire life cycle. In order to properly design a solution, you should identify the content that must be retained for regulatory or historical purposes. For each type of content, you should gather the retention requirements and define what to do when the retention period ends.
SharePoint products and technologies are best thought of as a solution platform. This means, however, that it is impossible to define exactly what constitutes a SharePoint solution and therefore what design deliverables are required. I have seen many SharePoint projects that are nothing more than installing WSS and turning a departmental team loose. While this approach may violate several planning and change principles, it certainly is not a project that requires layers of design documents.
On the other hand, I have also been part of unique projects that utilize forms, documents, search, and workflow to implement specific processes. In these projects, good documentationspecifically use casesis invaluable. Furthermore, SharePoint solutions are iterative by nature; as users become more familiar with the environment, you end up fine-tuning your solution.
As a result, you must decide for each project how much documentation is needed. The danger here, however, is that it's just so easy to start customizing in SharePoint. While this is not necessarily a bad approach for small projects, it can also lead to a maintenance nightmare if entire departmental or enterprise solutions are approached in this way. Instead of customizing many sites individually, for example, creating a single site template that can be used over and over will be much more efficient.
During a presentation, a customer once asked me to describe the most difficult issue surrounding a SharePoint deployment. My answer was immediate. I responded "It's the same issue as every other projectmanaging the change for the end users." Change management is the process that helps end users adopt new ways of doing business, and it is never easy.
Despite its ability to affect the success of a project, change management is rarely considered in sufficient detail. In my experience, this is because the team is primarily concerned with correctly implementing the technical solution. What's more, technical teams really are not trained to help users through the change management process.
Successful change management is about educating and assisting end users. Every good project must involve some key elements to help end users adapt and be productive. Scheduling end-user training is an obvious first step, but it is rarely enough to ensure success. Instead, consider the entire group of end users and have a complete plan to manage the change.
Begin by mentally dividing the end users into three groups. The first group is the set of people who are excited about the project. This group can be a strong ally in your effort to bring others through the change process. The second group is the set of people who are neutral about the project. This group is waiting to see if the project will be successful before they get behind it. The last group is the set of people who are openly hostile toward the project. This group does not want to change and is typically very vocal about it.
Although the third group is the loudest and cries for the most attention, it should be largely ignored. Instead, I like to start a pilot with the first group. Don't worry about the traditional approach of piloting your project with a particular department. This approach is too narrow and invites people from all three groups into the pilot. This will surely result in someone from the third group declaring the project a disaster. Just locate the most enthusiastic people you canregardless of departmentand start a pilot.
Piloting with enthusiastic people guarantees good press. This means that the people in the second groupthe ones who are waiting for successwill begin to hear good things about the project. This will result in more people from the second group becoming enthusiastic and joining the first group. Now you can expand your pilot to include more people. In this way, you can continue to build momentum for the project. This strategy can save you a lot of heartache when rolling out something with as much organizational impact as a portal.