KEY TOPICS:
 
Introduction While SharePoint is a broad and diverse platform, when many people think SharePoint they think collaboration. Team collaboration is one of the most popular and powerful uses for Microsoft SharePoint Server. Collaboration is such a core part of SharePoint that the majority of what most organizations need for fostering better communication and execution among teams can be found in thebase WSS version of the product, which is included with Windows Server. In other words, any organization using Windows Server has in its possession a powerful team collaboration platform. However, even when operating in this “sweet spot” of SharePoint, where an organization is able to heavily leverage out-of-the-box capabilities, it pays to think a few steps ahead. In this white paper, Northridge—a business consulting and technology services firm dedicated to enabling enterprise excellence through collaboration, insight, and productivity on the SharePoint platform— presents ten “best practices” for success in leveraging SharePoint for improved team collaboration in your organization. The ten best practices are:
You may have noticed that these practices are not especially technical in nature. While certainly a successful SharePoint implementation requires attention to technical detail, and while there are additional technical “best practices” we could name, the fact is that successful adoption of SharePoint for team collaboration has a lot to do with people, process, and change. Working with an experienced partner on the technical parts of the equation, and paying close attention to the ten best practices introduced here, can pave the way for better communication, closer collaboration, and more organized and accessible information with SharePoint—and also for more sophisticated and advanced uses of SharePoint in the future. This paper focuses as much as possible on the out-of-the-box capabilities of Windows SharePoint Services (WSS), whether in the 2007 or 2010 version. Unless otherwise noted, you should be able to assume that the advice and information contained hereapplies equally well to WSS 3 and above as well as Microsoft Office SharePoint Server (MOSS) 2007 and SharePoint 2010. 
1. Adopt a Mindset of Managed Empowerment Because SharePoint has grown a reputation for ease of use, flexibility, and powerful, out-of-the-box capabilities, in a team collaboration scenario it is tempting to conclude that installing SharePoint and setting it loose will produce quality results. People will feel empowered, and, in pure bottom-up fashion, your employees or members will adopt SharePoint and do great things with it. Over time a site structure and content collection will emerge organically from all that activity. People will naturally gravitate from their existing processes and tools to SharePoint. Innovation and efficiency will increase. This is the Web 2.0 promise, after all—create modular tools, make it easy to combine them, and people will do amazing things with them on their own. We do not mean to paint this as a total fantasy. We wholeheartedly support the idea, in the right context, of harnessing the forces of “crowdsourcing” to drive innovation and produce superior results. The problem is that there is no guarantee that the ideal conditions for producing organic bottom-up results will all come together at the right time in your organization. Even if those conditions do exist, there is no guarantee that the result will address the full scope of the organization’s concerns (for example, regulatory compliance or globalization). Ironically, because SharePoint has grown a reputation for ease of use, flexibility, and powerful, out-of-the-box capabilities, and because many organizations have tried installing SharePoint and just “setting it loose,” it is also tempting to conclude that SharePoint is like the Wild West. That empowering people too much creates chaos. That top-down control and rigid structures are required to maintain order and security. For example, what if one of your key business goals is to put more control and governance around certain areas, such as those affected by regulatory bodies, industry standards, or litigation concerns? A SharePoint free-for-all can’t be the answer. These concerns are legitimate, but unfortunately misguided. SharePoint in no way inhibits the opportunity for this kind of structure and control. In many ways, it was designed with exactly that in mind. However, SharePoint was also designed with openness and empowerment in mind. Control or empowerment with SharePoint is a false choice. You can have control and empowerment. That balance is what Northridge calls managed empowerment. The basic idea of managed empowerment is to create enough top-down structure within SharePoint to keep things from becoming a mess, with tighter controls in the areas where it makes the most difference, while at the same time leaving enough space for people to experiment, communicate freely, and get things done with as few hurdles as possible. Each organization will strike the managed empowerment balance in its own way. That is, the line between too much and not enough is different for each organization. Striking this balance, finding where the line should be, is a key factor for the successful adoption of SharePoint for team collaboration scenarios. Northridge recommends putting thought into the balance of structure, control, and empowerment prior to jumping with both feet into SharePoint. However, adoption of a managed empowerment mindset is overall more important than identifying, from day one, exactly where to draw the lines. Empower your people to do the business of the organization, give them tools they can use, and trust them to do their work (with a little auditing and administration to keep things in line). Do your best with the structure and control. There will be time to get the balance right. (See also #2, #4, #8, and #9.) 
2. Involve As Many People As You Can In the process of working out the balance of structure/control with empowerment/capability, it’s a good idea to seek input from multiple quarters. Department heads can communicate what’s important to them. Knowledge workers can communicate what tools and processes make the most sense to them. Top management can communicate goals and constraints, and often point to other stakeholders that might need to be consulted. Technical personnel can make design suggestions and point out possible potholes. Longtime employees can recount past change initiatives that were undertaken and what influenced their success (or lack of it). There are at least three goals here:
A key phrase in the wording of this suggestion is “as you can.” In other words, we recognize that you may be working under unique circumstances, particular political and strategic considerations, and limits on resources. Talking to everyone is not always practical. Increasing the visibility of the project too much is not always desirable. The long term plan may include limited input for the first phases, with the intention of increasing the scope of input at a later stage. Previewing a theme we introduce in practice #3, “scale” is a factor here—the breadth of input you seek would ideally be proportional to the size of the planned SharePoint implementation, whether to a single department or multiple divisions and locations, and also to the size of the impact if the rollout were to be less than successful. 3. Develop a Plan From Clear Business Goals Our recommendation to “develop a plan from clear business goals” follows not only from the idea of managed empowerment (achieving that balance would naturally require exploration and planning early in the process) but also from Northridge’s belief that business drives technology. Investments of funds, time, and other resources in technology initiatives should ideally be tied to business drivers. SharePoint is no different. One way to look at this is through the lens of strategy and tactics. We don’t mean to suggest, before you can get started with SharePoint or any other technology, that you must first figure out a grand strategy at the highest levels and know exactly where SharePoint fits in the big scheme of the organization and its plan for the next five years. It’s obviously great if you can achieve that, but “having a strategy” can be as simple as stating some straightforward goals:
Within your strategy, you have a context for working out the tactics—for example, setting up the site hierarchy and site templates a certain way, planning out content types and approval workflows, and designing an appropriate security configuration. Scale is a factor in how broad your strategy must be (the goals) and in how much effort must be expended to work out the tactics (the plan). Rolling out SharePoint for departments and teams in a single office is one thing. Rolling out SharePoint for a multi-location, multi-division company is something else. The latter case would require more comprehensive (though not necessarily more complicated) goals and a wider process for ensuring that you have worked out the tactics. If you’re not sure what all of the goals are, or if you are concerned that it will require too much to bring all the parties together to work out the ideal tactics, don’t be afraid to take the leap. We don’t mean you should take a leap without a plan, but you can work out a plan that takes into account the pieces of the puzzle that will be missing at first. Certain decisions in SharePoint (such as the deciding of site collection boundaries) are hard to reverse later, but in many ways SharePoint makes it easy to change your mind later, to move a few things around as you learn more. Returning to the theme of managed empowerment, the main thing you want to avoid is the install-it-and-hope-for-the-best approach. (See also #4, #5, and #10.) 4. Treat a SharePoint Project Like Any Software Project At Northridge we recommend treating a SharePoint rollout “like any software project.” At the highest level, this means following the basic sequence of requirements, design, development, testing, deployment, training, and support. This may seem counterintuitive if your plan is to adopt the out-of-the-box collaboration, communication, and content management functionality of SharePoint. However, our experience is that, even in the most straightforward cases, it is essential to go through a series of deliberate stepssimilar to what you would go through for a custom software development project. The important thing is to avoid skipping the steps while “right-sizing” the approach to the situation. Each project is unique, and there’s no need to add more formality and process than is needed. For example, when deploying a purely out-of-the-box WSS implementation, it may not be necessary to set up the full set of separate physical environments for development, QA, UAT, and production. However, even in that case, we stand by our advice (see practices #2 and #3) to work from a plan, gather requirements, develop a design, implement that design in a deliberate fashion, and do a little testing and training before going into production mode. Please also see the Northridge True North Methodology™ white paper, which introduces Northridge’s approach to projects and engagements of all types, including SharePoint projects. 
5. Be Proactive With Training and Adjustment to Change Possibly the most crucial factor for success with SharePoint in a team collaboration scenario is adoption—that is, actual use of the new tools and processes by the people in your organization. Failure of adoption is a risk in any new process or software application, but the risk is particularly high for team collaboration projects, where the goal is to improve things like communication, collaboration, issue tracking, planning, and content management. The trick is that the people in your organization most likely already have solutions for those things that work pretty well. For example, they probably have email for communication, Microsoft Excel for keeping lists, file shares for storing documents. The fact that these tools are clearly less than ideal, or that they lack certain advanced features such as approval workflows and document versioning, does not change the fact that inertia is a powerful force. Even people who are not already busy will tend to stick to what’s comfortable and familiar and what has been proven to work in the past. It’s just human nature and not a failing of your employees. Not only do habits need to change, but the operating paradigm for how people work must change also. Really, we are talking about two overlapping problems: first, fostering a willingness to change, and second, achieving actual abandonment of current practices and tools in favor of the adoption of the new practices and tools. The Northridge approach these challenges is threefold:
Keep in mind that change of this sort is likely to be gradual. After you’ve done your best to train and prepare your people, keep an eye on what seems to be working and what seems to not be working. It’s a good idea, for example, to set up some specific checkpoints in the future and to give one or more people in your organization a mandate to audit and encourage the changes the organization is seeking to achieve. Some combinations of carrots and sticks may be necessary. Set realistic targets and limits and use your normal management techniques and communication channels to achieve them. Plan to monitor activity and nudge people in the right direction when they fall into old habits. For example, when a discussion starts in email, a project leader can take the initiative to move it to a discussion list in SharePoint. (See also practice #9.) Training plays an important role in a least three ways. First, at a mechanical level, many people will simply need to learn how the tools within SharePoint work, what steps they should follow to perform key tasks. Second, at a conceptual level, some of the concepts in SharePoint like document check in/out, discussion threads, and RSS feeds will be new to some people. And third, at an even deeper conceptual level, the whole concept of SharePoint as a unified platform and interconnected suite of tools and content will be hard for some people to grasp. For some, training will need to start at that most fundamental level. Finally, another aspect of training and adjustment to change to consider is at the infrastructure level: IT people in your organization will need to become familiar with how to configure, administer, troubleshoot, backup, and recover your new SharePoint platform. 
6. Build Bridges to Existing Tools and Practices One way you can be proactive in the area of encouraging adoption and easing adjustment to change is to “build bridges” to current tools and processes. A “bridge” in this case could be something physical, like taking advantage of the capability for SharePoint to integrate discussion lists into Microsoft Outlook so that people can participate in discussion activity from a familiar tool (Outlook). You can also encourage people to use RSS feeds from Outlook or Internet Explorer to keep up with project updates. Another example would be encouraging the use of “My Sites,” where people can personalize a home page that includes web parts that expose their Outlook calendars, address books, and email side-by-side with the SharePoint collaboration tools and content.1 A “bridge” can also be more conceptual, such as using metaphors to encourage and steer people towards the adoption of the new tools and processes centered around SharePoint. In other words, provide explicit guidance that says, “You used to do X this way, and now we do X this other way.” Help your people understand what is similar between the current tool (for example, email in Outlook) and the new tool (for example, discussion lists in SharePoint). When you have bridged that gap, you can explain how the old and new tools are different and how you can do even more with the new tool. Once the bridge helps them understand and appreciate the new tool in light of something they already understand, their minds will hopefully open to the new possibilities. But as we intimated in the previous section, in this type of situation a combination of carrots and sticks may be required; that is, in some cases you may need to just lay down the law that change is required while also doing what you can to ease the transition. 7. Cultivate a Power User in Each Group A “power user” is not only someone who has gained proficiency with a software tool or platform such as SharePoint, but is also someone who is enthusiastic and motivated to use the software and to whom others come when they need help. With one power ser you create the opportunity for multiple simultaneous benefits. Adoption can increase because the power user leads the charge in the use of SharePoint, starting discussions, creating content, and responding to issues and tasks posted to the project sites. A power user can also encourage others in the adoption of SharePoint merely by spreading their enthusiasm and positive attitude. Peers of the power user have someone close to them, someone they know and trust from working together, someone to approach when they have challenges or questions. Project leaders have someone to delegate to. IT and support personnel have someone they can leverage as a point of contact. If you’re lucky, some of these power users will pop up spontaneously. However, we’d like to have power users in as many departments and teams as possible, and it would be better to not leave that to chance. What does it mean to “cultivate” such a person? First, try to identify one or more people in each group who are influencers and established natural leaders in their peer groups (particularly those you suspect might take a negative view by default). Second, enlist these people in the organizational strategy around SharePoint and achieve their buy-in on policies, goals, and designs (so that they may advocate and defend them to their peers). Third, provide these people with an extra level of training, and perhaps other resources such as online knowledge bases or reference books. And fourth, consider officially designating these employees as a “first line of defense” for user support questions and possibly also as an official communication channel between user groups and IT. 1Note: “My Pages” and integrating Outlook into SharePoint are not included in the base WSS features (higher versions of SharePoint are required), but the ability to share from SharePoint to Outlook is included with WSS. 
8. Engage With IT and Corporate Communications This suggested practice may seem redundant with #2, “Involve as many people as you can.” Indeed, there is some overlap between this practice and that one. However, the intent here is a bit different. In advising engagement with IT and, if applicable, your corporate communications department, we are focusing less on the requirements and design for team collaboration in SharePoint and more on logistical, strategic, and, in some cases, political concerns. Rather than try to advise you on how to navigate and strategize within your own organization, we will highlight three areas to consider. First, this white paper is focused on the team collaboration scenario for SharePoint, which is only one of the many facets of SharePoint. Many organizations are also adopting SharePoint for “enterprise portals”—meaning company-wide adoption of SharePoint for corporate communications, access to resources, business intelligence, reporting, marketing, time tracking, enterprise content management (ECM) and enterprise search, custom productivity and line-of-business applications, and other similar functionality that fits within SharePoint. Also, many organizations are using SharePoint for public websites and web content management. And finally, many organizations are also using SharePoint for “extranet” scenarios such as portals opened up to external partners, suppliers, and customers. There may be logistical or strategic concerns related to these other uses of SharePoint within your organization, and you may find that you are one of an increasing number of organizations leveraging (or planning to leverage) SharePoint in all of these ways. Second, your corporate communications, and possibly human resources, departments may have logistical, policy, or content concerns related to your team’s use of SharePoint for team collaboration. This could be as simple as preferring a certain color scheme and approved use of company logos. It’s a good idea to cover these bases, even if only to reassure these groups that their input was considered. Third, you may need your IT department sooner or later for logistical and infrastructure needs, such as servers, security, user accounts, Active Directory groups, storage allocation, database configuration, or backups. Even if you’re pretty sure you can handle these concerns, plan for the right time to address them with your IT team. 
9. Create Feedback Loops for Continuous Improvement As we noted previously, full adoption of your new SharePoint team collaboration platform may be gradual, and it may take a few iterations to get your design and configuration just right. People may take some time to adjust to the changes, and there may not have been time in the early stages to gather all the input you would have liked. And sometimes people have good ideas later that they were not able to conceive of before starting to use SharePoint. Avoid the temptation to consider the project completed when the dust has settled on the initial launch and instead plan for a process of “continuous improvement.” These “improvements” need not be dramatic or expensive, as sometimes small adjustments can make a big difference, like enabling a certain feature or tweaking the navigation to reduce a common task from five clicks to two, or loosening up a security restriction or approval workflow to eliminate a bottleneck in the process. A “feedback loop” in this context is simply a mechanism or policy that allows for people to identify issues and make suggestions for improving the SharePoint design and configuration. Some of this will happen naturally whether you plan for it or not, but allowing for and even encouraging feedback in an explicit way may reduce some people’s fear of speaking up and may also provide an effective channel for people’s frustrations, allowing them to be heard on a subject rather than simply grousing about it amongst coworkers. Note that there is a potentially powerful connection between this practice and practice #7, “Cultivate a power user in each group.” As noted in that section, these “power users” can be an effective point of communication. One idea would be to meet with these power users (or perhaps their department leaders) once per quarter to discuss adoption, practices, efficiency, and ideas for improving the collaboration tools in SharePoint for better results. Another idea would be to set up a specific discussion list in SharePoint for consideration of SharePoint issues, perhaps opening it up to only certain users such as team leaders, department heads, and/or power users. 10. Plan for Growth Another way of saying “plan for growth” would be to say “plan for success.” When your SharePoint adoption for team collaboration succeeds, growth will happen—and that’s a good thing! More projects will be added. More people will become more active users. More content will move from scattered file shares and C: drives into SharePoint. More issues and tasks will move from emails and spreadsheets into SharePoint Issue Tracking and Task lists. Other departments, divisions, and regions will want to replicate your success and set up a site collection of their own. Planning for this growth can be as simple as being mentally ready for it, but could extend into more physical concerns such as the sizing of a server, the allocation of disk storage on a SAN, or the design of the site collection boundaries in the first-stage SharePoint design. Success will usually breed more success, and the best part is that successful adoption of SharePoint for team collaboration was never the end itself, but rather a means to a larger end: more effective project execution, more efficient people and processes, more visibility and governance, less chaos, more order—more success! 
In Conclusion In this paper Northridge presented ten “best practices” for the successful adoption of SharePoint for team collaboration, communication, and project execution in your organization. While these capabilities are exactly what SharePoint was designed for, realization of the desired benefits in your organization will not be automatic. The good news, however, is that the steps required to achieve a high value outcome, many of which we have described here, are well established and highly achievable. Northridge stands ready to help. The ten best practices we introduced are:
  |
 |
TAG’s article library is optimized by Atlanta SEO company Vayu Media, provider of search engine optimization services to technology companies nationwide. Vayu Media develops internet marketing strategies that drive business growth through sales generation and brand awareness. |
