Best and Worst Practices
A principle is the expression of perfection, and as imperfect beings like us cannot practice perfection, we devise every moment limits of its compromise in practice.
—Mohandas Gandhi
SharePoint has not yet reached its full potential. This is partly due to the time it takes to refine and perfect an application, but it is also due to the limitations and boundaries set for it by the technologies it is dependent on. SharePoint is bound by .NET, Windows, Active Directory, networks, latency, bandwidth, SQL Server, and the Internet. But the primary driver to realizing the potential of SharePoint is the decision makers who have responsibility for its planning, deployment, and maintenance. There are many perspectives you can take on why something is what it is. There are always many interrelated causes. While we cannot control the hardware, software, networking, and developmental limitations of the SharePoint platform, the actions of those who run it can make the greatest difference to its success or failure.
This chapter is an attempt to distil the best and worst practices I have seen during my years as an end-to-end implementer of SharePoint solutions. We all do some things well and others less well and can all get better. Most of what makes SharePoint successful comes down to the people involved and the decisions they make. I have fit these under the following four main headings:
- JFD: Stakeholders who want fast, cheap, short-term results at the expense of quality
- Quagmires: Migration, metadata, customization, workflow, and more
- Change Management: Not something tacked on after a farm is deployed
- Governance: Having the right people in the right roles who know the right things
There are many small best practices to do and bad ones to avoid. During the course of this chapter I will explain the ones that create the most difficulty in maintaining a SharePoint Farm.
Figure 11-1. Rushing to a result never works
JFD
JFD is an acronym for an informal management style I have encountered in a number of organizations. The letters stand for Just F***ing Do It. It is a philosophy based on the assumption that any attempt to do things in a methodical way is just wasting time and the best way is always the quickest short cut. There is a lot to be said for intuitive leaps, and they can be very successful because they avoid the groupthink that can dilute good clear ideas and reduce them to a mishmash of compromises. The best approach is probably a mixture of JFD and some careful consideration of the longer-term implications of this approach to make sure it will not lead to problems that could be circumvented now.
For example, you can set up SharePoint on the first pieces of hardware available on the network and give people access, and you can then hire some developers or a third-party external company to set up a boilerplate server farm, backup plan, governance plan, and branding. This can be done quickly albeit expensively. The flaw in this approach is that no detailed planning has been done to establish if and what SharePoint is indeed needed for because this is what shapes the actual solution. If this step is skipped, the result is a SharePoint platform doomed to fail. The reason organizations find themselves in this situation is not all because of the JFD approach, but the way SharePoint is marketed to make it look simple and easy to adopt. It is, but it can’t just be installed and left there. In many cases, SharePoint is chosen and installed without any planning or a formal Request For Proposal (RFP). Even if an RFP is done, it is based on the same superficial needs that are not enough to execute a proper SharePoint implementation.
A Typical SharePoint RFP
SharePoint is generally chosen after some basic online research. Then someone in the organization is told to create an RFP. RFPs are not a bad thing as a rule: they are the early stage in a procurement process. The first step is an invitation is presented for suppliers, often through a bidding process, to submit a proposal on a specific commodity or service, in this case for SharePoint. The RFP process brings structure to the procurement decision and is meant to allow the risks and benefits to be identified clearly up front. However, here the largest risk has been ignored: is SharePoint the right choice, and is the organization prepared for the amount of work it will take to transition to it? This risk can be mitigated by the organization first issuing an RFI (request for information). This presents the vendor with some technical problems; if it provides good solutions, they are then allowed to submit and RFP.
In our scenario, third-party companies are invited to submit proposals on how they would meet the organization’s needs, which are only generally described in the RFP because in most cases a detailed business analysis would not have been done internally by someone without in-depth SharePoint experience yet. Here is an example:
Company X has lots of data in many different systems and people in many places. We also have lots of different applications and these are expensive to support. We want SharePoint so we can have one application to do everything and store everything. In your response to this RFP, due in 2 weeks, tell us how you would use SharePoint to deliver the following:
- One place where people go to put everything
- Centralized Search so people have one way to find everything
- Web Content Management, but not to replace our Intranet, even though it is out of date and too slow to update
- Records Management, but we don’t know what records
- Document Management, but we don’t have any policies
- Facebook for the Enterprise, even though we don’t know what that entails
- To migrate all our content, and you have to do this without any disruption to users
- We want to migrate our business processes into Workflows too
- Also, send us a detailed design of the SharePoint farm architecture and how you would do backups.
In some instances, the result is a generic response from the third parties, because they can do no more than list the other companies they have set up SharePoint for and give a generic response to these criteria, adding the proviso that “further analysis will be required.” Although this is not always the case, when this is done well, it contains detail of what must be done to address these ambiguities and further refine the SOW.
The reality is that the analysis is the most important part of the process, and the client is rarely prepared for or informed of the amount of up-front commitment in terms of time and people this will require both from the client and the third-party consultancy to build a professional SharePoint implementation. The third-party consultancy rarely has good people at defining taxonomies and information architectures. They usually have lots of developers who they use to create custom code for the client, which creates the risk of locking the client into a solution that is harder to migrate to the next version of SharePoint. Not an ideal scenario. Although there are exceptions, when choosing a consulting firm, look for ones with strong business analysis skills.
An ounce of practice is worth more than tons of preaching.
—Mohandas Gandhi
Before embarking on a SharePoint project, every organization should make sure they have the budget and time to plan the project properly. For a large organization, it could require hundreds of workshops with every team to establish what their business processes are and how SharePoint could be used to do them better. The assumption is always that SharePoint is the answer and that it is now the task of the third-party company to frame the question exactly to fit that. Good consultancies guide the client through the process of setting up SharePoint in a small way initially, and then hand over ownership to them as soon as possible so they can learn about and own the platform themselves. A good consultancy supports their client in establishing internal processes for the assessment of user requirements and how these can be translated into out-of-the-box solutions with SharePoint, not ones that require custom code and as a result cannot be owned internally. Good consultancies will establish exactly what the business needs are for SharePoint before they build a scalable, secure, and available architecture for them. They will also take into account that different content with have different RTOs and RPOs and that these cannot be defined without a proper Business Impact Analysis. This is information I have covered in previous chapters and should be familiar to you now.
Putting the Cart Before the Horse
SharePoint is Microsoft’s fastest growing product in its history. This is partly because of the need for something that provides users with better and faster information sharing, but it is also because of Microsoft’s unique position in the majority of enterprises. This position creates a situation where SharePoint is installed using the JFD approach before anyone has assessed what it can and should be used for: there is no business case prepared. Here are the main reasons SharePoint can be leveraged into organizations by Microsoft in this way.
Figure 11-2. Slow and inefficient
Office in all its versions is the dominant productivity tool used by most people in business. How many of us could function without Word, Outlook, or Excel at work? The same is true of Windows; for most businesses it is the only type of PC OS available to users. SharePoint integrates better with Office and Windows than any third-party product. This is a compelling driver for organizations to reduce the risk of user nonadoption. It also helps Microsoft bundle SharePoint with Office and Windows, but they only do this indirectly via licensing bundles.
SharePoint Server and Client Access Licenses are frequently bundled in an Enterprise Agreement with Microsoft for Office and Windows. That means many companies have SharePoint licenses included at a low or minimal cost. A lack of proper analysis means that the true cost of setting up SharePoint, planning, is ignored. Even the cost of purchasing, installing, and managing the hardware for the multiple farms is not taken into account. A large enterprise could need 15 or more servers. Even with SharePoint Online, there is still likely to be the setup of sync with Active Directory that requires hardware too. The licenses may seem free, but a functioning SharePoint platform that meets your business needs is not. Volume licensing is a much neglected art and needs proper planning: see http://www.microsoft.com/licensing/about-licensing/briefs/SharepointServer2013.aspx.
With a beginning like this, there is a risk that things will simply get worse for the SharePoint platform. Seeing SharePoint only as an IT product, rather than a business process mapping tool, means it has not been perceived correctly from the start. With this misperception, the pressure is places on IT services to make SharePoint “work.” Their perception is either that it is only their role to support the infrastructure, or it is up to the business to decide what and how to use it for. Even if the organization does have a services arm that supports an internal consulting role, they are unlikely to have SharePoint experts in house. If they hire someone to support the business, this person is rarely given the authority to make changes to how the business operates so that it can get the best benefit from SharePoint, and so they become an expensive support person. SharePoint becomes a quagmire nobody wants to get stuck in.
Quagmires
Worst practices do not seem that way at first. They appear to be a structured, pragmatic approach to implementing SharePoint, but they are bad because they are based on a fundamental misunderstanding of the nature of SharePoint. In this section I will describe the worst of these practices and the alternative best practices. I’m describing the worst practices as quagmires because there are a number of characteristics of real quagmires that are the same as the metaphorical SharePoint quagmires I describe here.
- A quagmire looks like normal, flat, clear ground, perfectly safe to enter (Figure 11-3).
- It is usually alongside a hard, uneven path, but the quagmire looks like a great shortcut. You feel very clever for taking this seemingly better route.
- Initially as you enter it seems fine, a little soft under foot, but you still make progress as there are no obvious obstacles.
- As you move further in, the footing gets softer, and progress is slower, but you still move forward hoping it will get better.
- Further along, you are now in the middle of the quagmire, your feet are stuck, and you can’t go forward or back.
- You start sinking and look for help. Anyone coming to help you gets stuck, too.
- Eventually, once you’ve fully disappeared, the quagmire returns to looking flat and inviting for the next person to come along looking for a shortcut somewhere.
Figure 11-3. The shortest route is rarely best
The metaphorical quagmires you can get into when planning to implement SharePoint are the same:
- They appear to be quite easy and safe.
- There is another alternative but it is obviously harder and more uncertain.
- Initially, you make progress with this approach.
- You gradually notice it is taking more and more effort to make less and less progress.
- Eventually you have gone so far in this approach that it will be just as costly to go back as forward.
- All of your wasted efforts lead nowhere and you are forced to give up. The reason you gave up is not fully explained and so someone else eventually starts making the same mistake.
Let’s see how this pattern applies to the most common quagmires in SharePoint implementations, starting with migration, easily the biggest and most dangerous of them all.
History in its broadest aspect is a record of man’s migrations from one environment to another.
—Huntington Ellsworth
Implementing SharePoint should be seen as a migration of business tasks and processes, but it is very often mistakenly seen as a migration of content. This is due to a mistaken understanding of what SharePoint is. It is not a file storage system with drives and folders like Windows. This misunderstanding of the terrain of SharePoint is the first step into the migration quagmire. The mistaken perception is that migrating content to SharePoint is surely as simple as moving files and folders from one drive to the next. If you explain that SharePoint is in fact a collaboration tool and not simply a storage tool, this point is dismissed as it leads to a harder road: an analysis of all the tasks and processes in the business and how these can be mapped to functionality in SharePoint. This path means real commitment from the content owners and lots of work, because once the processes have been identified there needs to be a new taxonomy created in SharePoint, and then a slow, manual migration of content to the correct locations. The business would prefer not to go down this path, so they fixate on the idea that migrating to SharePoint is simply a copy and paste process.
There are simple ways to migrate content to SharePoint: users can drag in files and folders via the Windows Explorer view of Document Libraries and import Lists from Excel. An initial site structure can be created that reflects the organizational hierarchy and AD groups can be used to grant access to these. At this point, progress seems fast and the idea that SharePoint is easy to set up seems vindicated. But as more content is dumped into SharePoint, the progress becomes slower. Users complain that they don’t know when or how to use SharePoint and it appears to be just another location for files to be dropped and forgotten. The site hierarchy is not helpful as the sites quickly becomes “cobwebs” as no one updates them or uses them for any real business task except some meeting agendas or announcements. The question is asked as to the benefit of SharePoint to the business at all.
Now, however, there is lots of real business data in SharePoint, but SharePoint is not really doing anything for the business. The solution is seen as buying third-party content migration tools and employing external consultants to analyze why SharePoint is not being used. This approach may work, but is still no substitute for a serious plan that investigates what business processes SharePoint should be used for rather than seeing it simply as a more feature-rich content repository.
Now the stakeholders in the company are bewildered as to why the initial promise of SharePoint was not fulfilled, and they mothball the project. SharePoint stagnates until someone else in the organization decides to revitalize it. They either avoid this quagmire or step into it again. The best way to avoid the migration quagmire is to follow these steps. These are more complex than the easy approach, but they do work:
- Understand that SharePoint is a process and collaboration tool.
- Hold workshops with key teams within your organization who will act as early adopters of the technology.
- In advance of these workshops, give the teams a questionnaire that asks them about key sharing and collaboration processes that they want to improve.
- Map their requirements to out-of-the-box SharePoint functionality.
- Give the users a chance to pilot, understand, and take ownership of what you have set up for them.
- Hand over ownership of the SharePoint processes to the teams.
- If the users would benefit from some content being migrated into SharePoint, they can move it manually themselves. This is rarely the case.
It can be difficult to promote this approach as it requires users to be directly involved and take ownership. It is then necessary to show them the benefits to them of doing it this way. Focus on the fact this will make their lives easier, not harder. Also explain how content migration is not a way to implement SharePoint. This is not the easiest path, but it is the best. It is also the first quagmire most organizations step into. Unfortunately, there are other quagmires that have to be avoided, too, and the next is not based on the inherent problem of moving content into SharePoint, but on moving information about content.
Metadata
The metadata quagmire is based on the mistaken assumption that all properties and content types must be defined before the system can be used, and that strict, centrally managed metadata has to be applied to all content. While it is true that SharePoint can centrally manage metadata and keep properties and content types consistent across Site Collections and even farms via the Managed Metadata Service, it is not true that everything has to have detailed metadata and that this all has to be defined in advance. That is because some content does not need any metadata, and some only requires user-defined tags that do not have to be consistent with a central store of properties (although any properties can be promoted to that level).
The complexity of options at the beginning leads some at the planning stage to reduce everything to one hierarchical tree of metadata that all content will sit on. At first, this seems simpler than enabling all of the other metadata options. When SharePoint is initially installed, it is clear that there are many ways to provide users with the ability to tag content. SharePoint allows your users to create “folksonomies” of metadata with which to tag their content that are only useful to them and only consistent within one list or library. Libraries can be navigated just using metadata, and groups of content can be given the same metadata using document sets. Rather than understand this complexity, these SharePoint owners go for their one-tree approach.
This approach quickly starts to run into trouble when it turns out there are potentially hundreds of document types and that it will take a huge amount of time to identify every one. Then each of those document types will need multiple properties and each of those properties could have multiple predefined options in dropdowns or radio buttons.
Soon, they find themselves in the middle of the quagmire. They have hundreds or thousands of document types and properties and they realize no user want to have to choose which of these to use when they upload a document. The solution is seen as purchasing third-party tools and employing external contractors to write code that will apply all this complex metadata automatically.
This seems to work for a while until the metadata becomes out of date and the developers have to enter into a complex process to update the metadata. They now realize it is not possible to push changes out to existing documents. It turns out that they should have used the out-of-the-box SharePoint metadata functionality, which gives users more flexible ways to select and modify metadata. It also makes sense for metadata in different parts of SharePoint not to be consistent.
Following this “big tree” approach (Figure 11-4) to metadata gives users far too many potential content types and then properties and dropdowns to select from or fields to fill in before they can upload a document. It inevitably needs a custom solution that is very slow to change, and so the metadata gets out of sync with users needs. Entropy sets in and once again another SharePoint implementation sinks into the quagmire.
Figure 11-4. Metadata maps rapidly become complex
SharePoint is a web application, but there is an erroneous assumption that it is as simple to modify as a standard HTML website. Microsoft is guilty of fostering this misperception by marketing tools like SharePoint Designer as being easy to use by users with no prior training. As a result, they try and make changes themselves to the branding or even the standard SharePoint functionality. Their first efforts are successful: they change the site logo and theme, but when they attempt to do more, they quickly realize SharePoint is more complex than it first appeared, and it is taking more and more time to achieve what appear to be small changes, such as changing the appearance of the Search box. SharePoint is falling away and the company is building something much more complex to achieve the same purpose (Figure 11-5).
Figure 11-5. Custom does not always mean better
Now they have moved so far from the standard SharePoint UI, users demand more and insist SharePoint look and function exactly like they want it to, not as it was designed. As a result, the only way forward is to contract an external company to make the changes. They successfully make the changes, but now the system has become very complex and can only be updated by experienced developers from the third-party company. This sends the cost of ownership higher than its value to the business, and once again it stalls and is stuck until someone else in the business tries again to improve the UI.
Best Practice
The key point here is that SharePoint is a finished application and not as malleable as a web site. The more you bend it, the more likely it is to break. I would recommend as a rule of thumb that 80% of your SharePoint implementation be out of the box. Seventeen percent could be extensions that don’t require a feature or solution package. The final 3% can be custom code. This is just a general rule and not applicable in all cases. The reason for these proportions is the cost of managing customizations is high. If you don’t have the skills in house to do them and maintain them, I recommend you don’t do them. That may seem overly stringent, but as a principle it is a good one to follow and a good target to have even if you do not always meet it.
Workflows
Workflow is another deceptively simple quagmire to slip into. Initially, the prospect of using a technology like SharePoint to make a work process more efficient is attractive. SharePoint offers built-in workflow templates, there is also SharePoint Designer, Visual Studio, and tools like Nintex that make the creation of workflows seem deceptively simple. Creating a workflow is seen as a better alternative to the more difficult path of changing and improving inefficient and time-wasting business practices.
At first with customization the basic business processes are easily mapped to the approval workflow (for example) and the steps are defined. Then things become more complex. There is no official delegation policy if the approver is not available; in fact, there is no definitive list of approvers, and it seems anyone in the department could potentially approve something. Then it becomes clear that the organization has no idea what the business process actually is. The process has simply grown organically over time, and while it does not really work and constantly breaks down, the stakeholders persist with the idea that the problem is not with the business process but with the workflow technology. Once again, expensive alternatives are explored. A detailed bespoke workflow is built with Visual Studio that, it is believed, has the potential to capture every obscure eventuality even as the business comes up with new, contradictory rules for it to follow. As before, eventually the money and effort sink into the quagmire and the workflow development team gives up (Figure 11-6).
Figure 11-6. Illogical business practices make illogical workflows
Best Practice
The key point here is that no technology can fix a broken work process. If the business process is complex, inefficient, and ultimately doesn’t work, the workflow will simply reflect that and be complex, inefficient, and ultimately not work. Using SharePoint or a very good third-party workflow visualization and creation tool like the one from Nintex (Figure 11-7) should be seen as an opportunity to improve the business practice, to make it clear and efficient. Then the workflow will reflect that. The creation of a workflow is not a solution to a bad business process; trying to make it so will be a quagmire of wasted time and effort. Note also that the cost of Nintex is not insignificant.
Figure 11-7. Clear business processes make clear workflows
One definite quagmire to avoid in relation to SharePoint is not defining its purpose as opposed to the purpose of the existing Intranet. If you hear the question being asked in your organization, “Why do we need SharePoint; we already have an intranet?” and there is no clear answer, you know that you have a cart-before-the-horse situation and someone has decided to implement SharePoint without clearly knowing what it can be used for. At first, setting up SharePoint alongside the intranet seems deceptively simple; someone says that SharePoint is for “collaboration” while the intranet is for sharing news, templates, policies, and procedures with the company. After some time, when the two have existed alongside each other for a while, it becomes clear users are putting content on SharePoint in order to share it with the broader company community. This is because putting anything on the intranet takes weeks to submit, get approved, and have the pages formatted for the custom intranet application. It also takes weeks to change the navigation to add links to the new pages. As a result, the business is putting documents in SharePoint, them e-mailing around links to them. This creates a conflict with Corporate Relations or Marketing or whatever the department is that owns the intranet. They want to control the message. As a result they either insist that nothing be shared via SharePoint or that it only be linked to from their intranet. Progress grinds to a halt.
At this point third-party vendors or contractors are brought in to look at how the intranet can be migrated to SharePoint. Now the organization is in the migration quagmire. Now SharePoint and the intranet are out of favor and both fall into disuse.
Best Practice
Every intranet I have seen is out of date and trapped in a quagmire of its own. They are overly complex to update, users can’t change them without waiting vast periods of time, and as a result they are either out of date or have such a narrow use they barely have a reason to exist beyond being a glorified internal brochure for the organization. The basic one-to-many sharing paradigm of intranets itself is out of date, and users expect something more participatory like the Internet to which they can instantly contribute. Bringing in a new tool like SharePoint, which has a more two-way content sharing model, only shows the weakness of the intranet. At this point the decision has to be made to remove the intranet and replace it with SharePoint because that is what will inevitably happen regardless of what the organization wants. If that is not what they want, then SharePoint should be blocked before it enters the users’ hands and they see it as a way to circumvent the limitations of the intranet.
Records Management
SharePoint does indeed have records management functionality; as a result people try to use it to create records management operations. At first, things go well; the company looks at the record management functionality of SharePoint and it seems to be something the company can use. Then there is an immediate roadblock, because the company does not actually have an information management strategy or a records management policy (Figure 11-8). After all, SharePoint is just a tool. As with workflow, it is not a substitute for established business processes. It can’t in itself improve processes either. If you take on a third party, they may tell you the same thing, but the process of defining a strategy and a policy before you can even implement the policy is a long road and not one SharePoint can define for you.
Figure 11-8. SharePoint might be the How, but it can’t give you the Why or What
Best Practice
It may be that the desire to use SharePoint for records management underlines the fact that this is something the business needs and as with workflow, having SharePoint can be seen as an opportunity to define why records management is needed and what the policy should be. At that point SharePoint can be used to put the policy into operation. Once again, there are no shortcuts when it comes to records management. It represents a large upfront effort to put in place, but SharePoint can help bring the policy into practice.
Gage: Mr. Zuckerberg, do I have your full attention?
Mark Zuckerberg: [stares out the window] No.
Gage: Do you think I deserve it?
Mark Zuckerberg: [looks at Gage] What?
Gage: Do you think I deserve your full attention?
Mark Zuckerberg: I had to swear an oath before we began this deposition, and I don’t want to perjure myself, so I have a legal obligation to say no.
Gage: Okay—no. You don’t think I deserve your attention.
Mark Zuckerberg: I think if your clients want to sit on my shoulders and call themselves tall, they have the right to give it a try—but there’s no requirement that I enjoy sitting here listening to people lie. You have part of my attention—you have the minimum amount. The rest of my attention is back at the offices of Facebook, where my colleagues and I are doing things that no one in this room, including and especially your clients, are intellectually or creatively capable of doing.
[pauses]
Mark Zuckerberg: Did I adequately answer your condescending question?
—The Social Network (2010), Aaron Sorkin (screenplay), Ben Mezrich (book)
Many companies like the idea of seeing their staff as resources and believe that if they share information about themselves and their skills and knowledge, it will lead to better identification of resources and communication within the company. With Facebook, the site is provided for free to the users because the users are the product that is being sold to the advertisers. Everything people put in Facebook is valuable to the companies that use Facebook to target their products to the people they perceive as their customers. The rule is simple: if you are getting something for free, it is because someone else is paying and you are what they are paying for.
Translating that into a corporate setting is not so simple. There has to be an incentive for employees to share information about themselves. Since they are already paid to work there, it quickly becomes clear that building a sophisticated duplicate of Facebook in SharePoint is not enough. The organization quickly becomes disillusioned because the employees do not see any reason to use this corporate networking application. It does not help them do their job, or make their job easier. As a result it stalls and we are back in the mud.
Best Practices
The key to the success of applications like Facebook is they offer people status and exclusivity. Who you are friends with is just as important as how many you have. While work is not college, a large organization is like a college—there are reasons to network via a corporate version of Facebook because getting known by the people who have the power to promote you or offer you a raise is a powerful incentive to use it. Popularity is the driving force of Facebook, and in a corporate setting, presenting yourself well is also key to advancement within the organization and perhaps out of it. If the corporate Facebook is presented to people from this perspective of self-interest, then they may begin to invest the time and effort into it—because if they really use it, it becomes valuable to the organization. But to gain people’s attention, you have to appeal to their interests; you can’t sell them something they don’t want to buy just because you want them to buy it. Social collaboration, however, is how more and more people share information. Each new version of SharePoint improves how it is implemented, and even if it is not perfect now, it is worth investing in. Yammer integration also adds more interactivity.
Change Management
As I have presented thus far, the management of change is crucial to a stable SharePoint system. But the worst practices around change management occur because initially it seems you can simply make changes to SharePoint without needing a proper process. However, that is only because the majority of SharePoint’s functionality is supposed to be user-driven and can be changed through the web UI. There is also very little production data at first that users depend on to do their jobs. As SharePoint becomes more widely adopted and integrated into the businesses’ daily functioning, it becomes more essential to manage changes to it properly. More customizations likely have crept in, and these require careful testing before they can be made live. The more customizations there are, the greater the risk because they may begin to have an impact on each other.
The best practice with change management is to have a clear process in place from the beginning, even before it is really necessary. This gives you a chance to hone and perfect the process before any flaws have a significant impact on the business. This approach also gives the stakeholders and content owners time to learn and get used to the process. As an example, users are sometimes unaware that after an InfoPath form, approval workflow, and reporting dashboard go live, making a change to one will impact the others and that it may potentially destroy data. If there is no separate development and test/UAT environment, the changes have to be made in the live environment and the owners simply have to brace themselves for the support calls. This is not the way things should be done. Ensuring the process is being used from the very start will make it more effective when it is really needed.
Going Live
The biggest change to manage in SharePoint is the moment of going live. This is where users have full access to the system and can use it in earnest. This is frequently done too soon or not in a strategic way. The best practice I would recommend is a phased release. This gives you a chance to identify problems early but minimize the impact to a few users. Think of this as being like the beta phase of Gmail or Google+. The product was live, but users could only get access if they were invited. That way Google got feedback from real users, not just testers, before it was made available to everyone. Web applications can be released this way more easily because everything is on the server. It only has to be changed once for users to see the change, unlike when a CD had to be used to uninstall/install beta version of software. The crucial consideration here is that no changes can be made that will destroy content. Once a system is live, you are constrained by the fact that the user and their content are king.
Another error is not to have high availability, disaster recovery, and backup plans in place from the very beginning. Many organizations only add these later on, when the system has grown until it is at risk. Your HA and DR plans at the beginning will be simple, but they must be there, as a failure of the system early on can destroy user confidence that is almost impossible to get back.
Governance
A house divided against itself cannot stand.
—Abraham Lincoln
The worst practice in relation to governance is to see SharePoint as either purely owned by the business or purely owned by IT. In both cases, SharePoint is missing vital input into its governance. Unless there are regular meetings between the content and the infrastructure owners, SharePoint as a platform will suffer. Without either, SharePoint cannot grow and develop. The users provide the change and growth to the content and structure. IT provides the capacity and resources to support that change and growth. The two are interdependent. There must be clear owners of SharePoint and they must communicate.
Users Are King
Since SharePoint is a user-driven tool, another worst practice I have seen is to overcentralize it. This means site creation, granting access, and even adding content are controlled by a small team. This is counter to the way SharePoint is designed to work, and will eventually lead to frustration and user nonadoption. If your organization wanted a centralized content management tool and not a collaboration tool, then SharePoint was the wrong choice. Train users who want to own sites and manage them. Give them guidance and encouragement in running SharePoint properly, and you will have a healthier system in the long run. Here are some good principles to pass on to users.
Folders Are Bad
A small bad habit of users to discourage early on is the creation of nested folders within libraries. Try to show users that the main way to sort content is columns and views and the main navigation elements are sites and lists. List filters and metadata navigation also create dynamic ways to visualize content. Some would argue that only metadata matters as a structuring and organizing element in SharePoint, but sites and lists are still necessary for putting content into different containers that can have different audiences with different levels of access. No organization is completely flat and no SharePoint structure can be too, but folders are simply a throwback to file servers and are rarely necessary in SharePoint.
Have Skills in House
Give a man a fish; you have fed him for today. Teach a man to fish; and you can sell him fishing equipment.
—Author Unknown
It may seem obvious, but the golden rule of deciding if someone external should be asked to make a change to SharePoint is this: If no one internally understands how they did it, you need to recruit someone who does. This is true of branding as well as custom code. It is always cheaper in the long run to have skills in house than to develop a dependency on external providers. If you can’t afford to take on someone new, train an existing employee. If no one can take on the ownership of changes, you will be dependent on third parties for any new changes, and this is inefficient.
Permission Inheritance
I have also seen children successfully surmounting the effects of an evil inheritance. That is due to purity being an inherent attribute of the soul.
—Mohandas Gandhi
The worst practice I find among users is a lack of understanding of the concept of permission inheritance. This is the concept that the children of an object will gain the same permission settings as the parent. As a result, it is logical to group content that requires the same permissions; when you arrange it hierarchically, grant access at the highest level to avoid complex granular permission management that becomes impossible to track. Another permission management principle that is very important to convey to content owners is the idea in SharePoint (indeed in many systems) that you group rights into permission groups, that you associate these permission groups with SharePoint groups, and that you then add Active Directory user accounts and security groups to those SharePoint groups. This relationship structure is very important, and as the architect of the system you have a responsibility to ensure the importance of this is conveyed to the users.
Summary
Ultimately, when it comes to best and worst practices in SharePoint there is no such thing as perfection and no implementation is all bad. But it is possible to improve and to avoid obvious pitfalls. The quote at the beginning of this chapter points out that while principles are an expression of perfection, as imperfect beings we can never fully attain them. But they do give us something to strive for and a direction and motivation for our efforts.
Primarily you have to avoid the easy path of short-term results, the quagmires of weak assumptions, a reactionary approach to change, and an irresponsible approach to governance. Those four principles will get your SharePoint platform off to a good start and keep it on course to the end of its voyage.