When discussing SharePoint with new clients I often hear things like “our staff doesn’t like SharePoint” or “our SharePoint site is out of control” or something similar. I spend a lot of time explaining how RePoint can fix that and what our process is. But, I am often confused how companies get into this spot in the first place. They feel that SharePoint is a bad product. But, in reality, it is their implementation of SharePoint. I never hear a company saying Java or .Net is bad because the Website built on those technologies isn’t working.

At RePoint, we think of SharePoint as a platform, not a product. When you think of it like that, it’s easier to understand why the implementation is the issue rather than the platform. The problem with SharePoint is that it’s easy to do some things, it’s easy to grow really fast and it’s hard to find advanced functionalities. So, people grow it. Consultants come in without much experience and grow it too fast. Companies think they can learn it internally and grow it too fast. We see it all the time.

So, what are some of the common mistakes we see happening?

  1. Too quick to Code – we’ve written blog posts on this before – To Code or Not To Code – the ultimate SharePoint Question. Why do SharePoint consultants do this? Most SharePoint people are Net developers. SharePoint is built on .Net. It’s real easy to fall back on our expertise as developers. But, we often don’t understand the long-term ramifications in terms of maintenance and scalability. Coding should be a last resort when implementing requirements in SharePoint.
  2. Information Architecture – “the structural design of a shared information environment; the art and science of organizing and labeling websites, intranets, online communities and software to support usability and findability” (-wikepedia). This is VERY important for SharePoint. We have a term in the SharePoint community – SharePoint sprawl. This is when people create sub-sites, within sub-sites, within sub-sites. Information is so deep in the site, nobody can find it. Why does this happen? Many reasons:
    1. People are given too high of rights without proper training
    2. Not enough planning was done of how deep site should go or how navigation should be structured
    3. Plans are put in place – but nobody enforces them

    Another important thing to understand about Information Architecture is that it is not just planning your navigation out correctly and where sub-sites should go. You have to think about content also. Should you use managed meta-data? Should you pre-build Content Types as meta-data templates? Should you pre-build Document Library templates that already set the Content Type? Should you pre-build Site Templates that already set the Content Type? This stuff can be done out-of-the-box SharePoint. But, you have to put a lot of thought to what you want to capture throughout your organization. If done right, you can increase how Search works, implement Records Management capabilities, make roll-ups and dashboards easier, and do so much more.

  3. Navigation that only supports the organizational structure – we always think that everyone in a company knows the organizational structure. We always think because we work in an office the documents should go there. For some organizations this is true. For some, it isn’t. I just had a client recently put HR under a division that intuitively didn’t look like the parent of HR. I told them that nobody will be able to find HR documents. They pushed back that this is their organization structure. I spend a lot of time convincing clients that a website (particular an Intranet) does not have to follow your organization structure. It has to make things easy to find.
  4. Governance – “In its most abstract sense, governance is a theoretical concept referring to the actions and processes by which stable practices and organizations arise and persist” (-wikipedia). “The best laid plans of mice and men often go awry” (Robert Burns). Governance is understanding who does what, what is allowed and how it is done once you are in production. You can plan all you want. We often get contracts to install and setup SharePoint for companies. But, they have no budget plan for after go live. Then, all the great planning we do is overdone once users get their hands on the system. It is very important to create rules and put processes/tools in place to enforce those rules. How do you ensure old documents are removed from the system? How do you ensure sub-sites that are no longer in use get deleted? How do you ensure admins have trained appropriately and know your rules? There are many questions involved in Governance. Remember – SharePoint makes certain things easy. Sometimes you don’t want those things to happen. You have to put controls in place to prevent this. These controls can be technically based. But, sometimes they are report/auditing based. In fact, I suggest third-party tools which help with this. There are many on the market. I personally like ShareGate for the price to functionality return on investment. But, there are other great ones too. Also, beware of too much Governance. You don’t want so many rules that your users can’t do anything or have to ask for permissions to do common things. There is a fine balance.
  5. On-Going Training – Training is always included whenever we get a SharePoint install and/or setup project. However, Training in SharePoint is not step-by-step. If I build a custom application for someone, I can train them exactly what buttons to click to do what they need to do. It’s very easy. However, in SharePoint, I have to train them on how to use the platform for future implementations. So, we try to train at a high level. So, what happens:
    1. We train before go live. Users don’t use the system right away. They forget the training.
    2. Some types of people are not good in one-time training classes. They need hands on.
    3. Future systems are built on SharePoint. Some users have issues correlating general concepts (like the Ribbon and Save) to systems that look a little different.

    I have never seen this approach work. Is it good to do training when you go-live? Absolutely. Will that work for the long term? No Way. You need on-going training. Hire a trainer. Make an Analyst do training as part of their job. Make it easy for you end users to sign-up for training sessions (at RePoint we have a pre-built training portal we implement for many clients on SharePoint). Point is – SharePoint is always evolving. Your implementation is always evolving. Keep your users trained to gain adoption of your systems.

  6. Install – aren’t using Office 365 yet, why not? Don’t say security too quickly. Lots of great, secure ways to do it. But, let’s say you have a good reason to do on-premise. Is your install done correctly? Unfortunately, the answer is usually no and you don’t even know it. Almost every organization we’ve done maintenance checks for has some sort of issue in their environment. Service accounts not set up correctly (i.e.: security issue), space problems, sync issues, etc… You name it, we’ve seen it. Most don’t even know. But, their customers/users know. They just know problems exist and IT isn’t getting them fixed. 9/10 times when we ask users, they just think it’s SharePoint. They don’t even realize they are working on a sub-par install.
  7. Communication Planning – Do you tell people when your farm will be down? Are you proactive when you plan maintenance? Do you let your users know when new features are available? Do you effectively communicate training? If you aren’t doing these things – why not? Communication is the backbone of a successful SharePoint engagement. This should be part of someone’s job.
  8. Only planning for launch – this is a prevailing theme throughout most of the other points. But, it is still important enough to call out on its own. You need to plan (and budget) past launch. Training should be continual. Improvements should be continual. New functionality/systems built on the platform should be continual. It’s rare we ever go to an organization and they have a roadmap for their future SharePoint environment. But, it should be common place to know what you are doing next year, in 2 years and even in 5 years.
  9. Big bang roll-outs – some organizations just “turn SharePoint on”. Everyone gets everything all at once. We are working at an organization right now that wants every department site and sub-site created before launch. This particular organization came from a previous version of SharePoint where only half the organization actually used it. Isn’t it a better idea to launch the new version of SharePoint and roll-out department by department? Learn the needs of each department. Learn the security of each department. Train them individually. Then combine what you learned with your Governance and Information Architecture to make a site they will actually use. I never recommend creating sites unless you know they will be used. That is what happens during big bang roll-outs and should be avoided at all costs.
  10. Level of SharePoint Expertise – lastly, and most importantly, make sure you have the right level of expertise helping you out. I see “SharePoint Admin” all the time with very little expertise in all parts of SharePoint. However, they are the only support at an organization. If you are going to support your SharePoint install with one person, you better have a rock start (and they are few and far between). Otherwise, you better find people that are good at certain things and staff a well-diverse mix of SharePoint talent to support your site. Get that back-end admin. Get a person great at out-of-the-box components to support your end users. Doing a lot of customization – get that developer that knows JavaScript and SharePoint really well (yes, I said JavaScript, that’s what SharePoint developing is mostly now a day). Point is – this is not the place to skimp. One person can rarely do the entire job unless they are really senior (and you are going to pay for that).

SharePoint is a great product. But, with “great power comes great responsibility.” (Spiderman). The flexibility of the platform allows for many things. But, it also allows for many mistakes. Plan ahead, organize, take it slow and you can take advantage of the tool and make your end users happy.