It is not unusual for those implementing Microsoft Office SharePoint Server 2007 to experience a fair amount of change and conflict as part of their deployment process. Other than e-mail, no other product that you will implement will have as wide or personal "touch and feel" as Office SharePoint Server 2007 if you intend to implement this product in a wide, deep, and pervasive way. When SharePoint Server 2007 is implemented in your environment, you’re not just implementing a simple document management or Web-based collaboration solution. You’re implementing change. Culture change. Business process change. Information management change. And usually, when change happens within an organization, power balances get shifted and conflicts can ensue.
In this chapter, we’re going to explore the less-talked-about side of SharePoint that many encounter during deployment—the change that SharePoint introduces to an organization with the predictable effects that such a change imports. You should note that the problems we’ll discuss in this chapter are not about your SharePoint implementation per se. Yet changes that can cause conflict that result in power wars, if not anticipated, discussed, and managed properly, can kill your deployment. We’re not kidding.
Since this book’s focus is on deployment best practices, we’ll be offering some best practices regarding change, power, and conflict. Like several other chapters in this book, this chapter can be read as a single best practice about a SharePoint Server 2007 deployment. But in another sense, we’ll discuss several best practices about how to manage change, power, and conflict as part of your overall SharePoint Products and Technologies deployment. Before we discuss the changes that this technology introduces that are specific to SharePoint, let’s consider the more general concept of change within a corporate environment.
It was once thought that a manager could simply tell everyone that they were going to do things a certain way and everyone would salute and follow. In today’s corporate environment, that is a misconception. In fact, there are several misconceptions about change that need to be recognized.
The first misconception is that a great idea, like SharePoint, will be accepted just because it is a great idea. When it comes to SharePoint, it might be a great software product with lots of helpful features that solve many existing information management and collaboration problems, but that doesn’t mean it will be readily accepted. The fact is that even some of the best ideas are not readily accepted. Remember the old Sony Beta technology for videocassettes? Sony had a clearly superior technology to the VHS videocassettes, but due to poor marketing and other factors, the VHS became the adopted standard. If we borrow from family theory for just a moment, family therapists will tell you that the family system will put pressure on the individual who is changing to remain the same—even if the change is for the better. Human beings are wired to resist change. Just because it’s a good (or even a great) idea doesn’t mean the idea will be automatically accepted.
Another misconception is that all you have to do is explain the new idea and the explanation, by itself, will remove the resistance to change. Explain it. Do some training. Get people excited and you’re done. No follow-up is needed. No care and feeding is warranted. If you’re thinking this way, please be prepared for a long, sustained effort. The reality is that introducing change in an organization requires persistence. You need to be in this for the long haul if you’re going to be successful.
New software roll-outs always represent change at the desktop. (You need to consider SharePoint to encompass a similar effect as updating the Office suite at the desktop because of its pervasive and persistent touch and feel.) Have you ever rolled out a new software product only to find that, over time, the product is not persistently used and the old methods are still the primary methods of accomplishing work? In many organizations, change can be an illusion while the old reality persists.
A third misconception is that implementing change slowly while building grassroots support will result in nothing getting done. In fact, the opposite is true. What research has shown is that while bottom-up change is more gradual, it addresses resistance more effectively. The emphasis in bottom-up change is on participation and on keeping people informed about what is going on, so uncertainty and resistance are minimized. Furthermore, research has revealed that people are not resistant to change, they are resistant to being changed. People are better at coping with change if they have participation in bringing the change to reality. This is why—with or without grassroots support—the best way to introduce SharePoint into your environment is through a gradual, collaborative process where your users, managers, and executives all have input into the overall deployment objectives and direction.
Experts in change management tell us that organizations can experience several common types of change:
Structural change. This type of change looks at the organization as a set of functional parts that need to be restructured. The parts are re-configured (re-organized) to achieve greater overall performance. Mergers and acquisitions are two examples of structural change.
Cost cutting. This type of change focuses on the elimination of nonessential activities or on other methods of squeezing costs out of operations.
Process change. This type of change focuses on altering how tasks and activities are accomplished. Examples include re-engineering processes or implementing a new decision-making framework. The introduction of new software products onto the desktop clearly falls into this type of change.
Cultural change. This type of change focuses on the human side of the organization, such as a company’s general approach to doing business or the relationship between its management and employees. Cultural change nearly always involves relational change. Since relationships are built on personal interaction, how people communicate and interact helps build the culture. Introducing SharePoint Products and Technologies into your environment introduces culture changes because SharePoint Products and Technologies introduce new communication paths and new ways of relating to co-workers, partners, vendors, and customers.
We believe that SharePoint represents change in three out of the four areas: structural, process, and cultural. It is structural in that the major parts of the business (however this is defined) will need to adjust their work habits to incorporate SharePoint’s features into their daily work routines. For example, end-users will be managing Web sites while power users will be managing a range of Web site administrative tasks including the security of the information that resides in SharePoint. Another example is managing documents in a library versus a file server. This is a significant change that will be felt by everyone in the organization.
SharePoint represents huge process change because we’re now going to ask everyone in the organization to (more or less) get on the same page when it comes to information management and information process management. And since SharePoint has a huge touch and feel at the desktop level, the process changes will be experienced by nearly everyone in your organization who uses a desktop computer.
Finally, SharePoint represents significant cultural changes because of the way it handles information and the new communication paths that are created by its introduction. Collaboration moves from e-mail threads to team sites. Discussions are handled online while offline synchronization involves Microsoft Office Outlook or Groove. Workflows introduce an electronic way of gaining document approvals, and communication about approvals involves both e-mail and the browser. Hence, implementing SharePoint Products and Technologies in your environment represents significant, pervasive change. If this aspect of your deployment is not managed correctly, the chances are increased that your deployment will either fail or not be as successful as initially envisioned.
Not everyone in your organization will accept change in the same way or at the same pace. This thinking has been around since the early 1900s, but was refined in 1953 by E.M. Rogers in his book, Diffusion of Innovations. Rogers defined diffusion as the process by which innovation is communicated through channels to the members over time. In this thinking, diffusion included four main elements:
Innovation. The new idea is incubated and defined.
Communication channel. The methods or paths that messages flow over between individuals.
Time. Three factors were mentioned here, but for our purposes, the innovation’s rate of adoption is the one factor that is most important. How fast the new idea is accepted and utilized is part of the diffusion process.
Social system. The set of interrelated groups that are working toward a common goal.
The overall thrust was that a new idea or an innovation needed to be defined, communicated, and, over time, adopted within the social system of the organization. From a diffusion viewpoint, SharePoint represents the new idea or the innovation. The communication channels that currently exist in your organization will need to be utilized to introduce SharePoint Products and Technologies to your environment. The rate of adoption will likely depend on how adept you are at working with the five groups described below and meeting each of their needs. And a solid understanding of your social system, the stakeholder’s needs, and your overall culture will enable you to manage the potential pitfalls along the way. As you look to implement SharePoint in your organization, you’ll need to be aware that these four factors cannot be avoided: You must define, communicate, be patient, and work within the social structure of your organization if you’re going to be successful.
The theory of diffusion holds that a new idea will be adopted faster when the following is present:
The new idea is perceived to have more value than the current system.
The new idea is compatible with existing values, past experiences, and current needs.
The new idea is not overly complex.
The new idea is testable before its production implementation.
The new idea results in visible, measurable positive outcomes.
Critical mass is achieved once enough individuals in the organization have adopted the new idea so that the idea is commonplace and self-sustaining. In short, critical mass means the new idea will survive. The problem with achieving critical mass is that there is a time lag in how fast new ideas are adopted. This is why it is important to understand the different groups that naturally exist in your environment as you try to introduce SharePoint Server 2007 into your environment:
Innovators. This group makes up about 2.5 percent of the overall population. They accept new ideas quickly and need little persuasion. They often like new ideas simply because they are new. They tend to be venturesome, daring, and risk-takers. They also tend to have the financial resources to absorb a loss if the new idea proves to be unprofitable. Finally, this group has the ability to cope with a high degree of uncertainty about the innovation along with the time to understand and apply the technical knowledge the innovation represents.
Early Adopters. This group represents about 13.5 percent of the overall population. They are open to new ideas, but will accept them only after serious consideration. This group usually holds the greatest degree of opinion and thought leadership within an organization. They tend to look for the strategic opportunity an innovation can provide. They serve as role models for others in the organization and they tend to be highly respected.
Early Majority. This group represents about 33 percent of the overall population. These folks frequently interact with one another and tend to be followers, not leaders. They want to see that others have been successful with the innovation before they adopt it themselves. Critical mass is usually achieved once this group has adopted the new idea.
Late Majority. This group is also about 33 percent of the overall population. These folks tend to be skeptical and cautious and will usually adopt new ideas only when pressured to do so.
Laggards. This is the last group to adopt a new idea, which by the time they adopt it, is a current or fading idea. This group possesses no opinion leadership at all. They tend to be isolated and suspicious of new ideas and will filter these ideas through referential points in the past. Their acceptance of a new idea results from other’s pressure coupled with the certainty that the innovation cannot fail.
Once we understand the basic ideas in Rogers’ (and others’) work, there is an opportunity to apply how change should be managed when it comes to doing a SharePoint implementation.
First, in some environments, SharePoint will be perceived as a huge step forward by the decision-makers because of the features and benefits inherent in the program, such as collaboration, information aggregation, or publishing. Many customers with whom we work don’t have a problem seeing the obvious advantages that SharePoint brings to the organization. Yet sometimes, there is little grassroots, managerial, or information technology support; when this support is absent, the task of working within existing communication channels and the social culture will be foundational to success.
Second, SharePoint is rarely seen as a system that is incompatible with the organization’s values and goals. Because the system is so flexible, it can be used by nearly any organization. We have yet to encounter a customer who found that SharePoint was inherently in conflict with his organization’s goals and values.
Third, SharePoint is sometimes thought to be a system that is highly intuitive for non-technical people who work with it on a day-to-day basis. This assumption needs to be challenged. While SharePoint’s interface is rather easy to use and is somewhat self-explanatory, we still find that users need a solid base of education on how to use the product and the scenarios in which certain features would be used. Some customers have balked at purchasing SharePoint until they knew their user-base would be adequately educated to use the software appropriately. In short, everyone in your organization will need education if you are planning on obtaining a robust Return on Investment (ROI) for the money your organization has spent on SharePoint licenses.
Fourth, SharePoint can be (and should be) tested in a proof-of-concept (POC) before it is deployed into production. POCs can be great tools to learn about a new software product and simulate a production environment. In our experience, however, the danger is that the POC often morphs into a production environment because the test team members tend to really test SharePoint, find that they like it, and then dump all sorts of mission-critical information into the POC. After that, they have little interest in pulling out the information and re-doing their work in a production environment. So while a POC or some type of pre-production test is a good idea, you should also have clear agreements about when the POC will start and stop and the expectations that users will have regarding the information they have placed into their POC sites.
Finally, the ability to measure SharePoint’s ROI is probably the highest pain point in this entire discussion. How "success" is defined is elusive and this results in measurements that tend to be more emotional or anecdotal in nature as opposed to being more structured and objective. But there are some ideas you can work with to help understand if your implementation is successful or not. First, count the number of site collections in your farm. Just add up the number of "sites" on your content databases and this will be a rough equal to the actual number of site collections in your farm. Second, you can measure database growth patterns and determine if the growth rate is what you had hoped it would be. Third, you can count the number of people who have attended SharePoint training as another metric of success. Or you could use one or more of these metrics plus others that you develop yourself and then use those numbers to determine if your implementation is successful or not. While still a subjective measure, it will add some statistical support to your conclusions.
Most organizations don’t roll out SharePoint to everyone on the same day. Most IT personnel would strongly advise against this. Given that there are five types of people in your organization (from an adoption-of-innovation standpoint), best practice is to find one or two groups that like to work with new technology and roll out SharePoint just to those groups. Not only will they enjoy having a new technology with which to work, but you will have the opportunity to refine and mature your rollout processes so that by the time you’re rolling out to the Early Majority, you’ve fixed the bugs in the rollout process and have better defined how to use SharePoint in your environment and how to present its usage to your users.
So find out who your Innovators are in your environment. Go to them with SharePoint. Let them use it and get excited about it. They tend to be opinionated, so get their feedback on how to use SharePoint better in your environment and then use them as your first "win." Others will see what is happening, the Early Adopters will likely want to get going with SharePoint, and your adoption will spread. In our experience working with customers, most have a hard time throttling their deployment because the demand for this product is so strong. Don’t give in to the large demand. Stay methodical about your deployment and ensure that you move along at the rate you had hoped. Don’t let demand push you into going too fast. If you do, you might find that the demand was more vocal than serious. Going more slowly will help you resolve nagging problems early in the deployment so that those in the Early and Late Majority groups will have better experiences once they start using SharePoint.
Having said all this, it is highly probable that you’ll roll out SharePoint Products and Technologies to a departmental team composed of people from all five groups. If possible, try to avoid this scenario. But if you must roll out to a group that is mixed in their attitudes about adopting SharePoint Products and Technologies, then please take the time to communicate with them about the "hows and whys" of SharePoint Products and Technologies and ask for their input and help in adopting SharePoint Server 2007. While bottom-up changes take longer, the resistance will be less and, in the end, you’ll have a more successful deployment of SharePoint in your environment.