If the situation listed below sounds familiar or this image looks something like your current SharePoint implementation please read on:
- IT installs SharePoint
- IT plays around with SharePoint and decides it truly is sweet and starts telling people about it. IT really though, knows nothing about the implications of what they are doing.
- A few users start using it and things tick along “nicely” for a while.
- They start talking about it to others and it becomes like that Susan Boyle video on YouTube.
- Then….an executive sees it and decides that this is the answer to all our prayers your world is now significantly different.
- Once someone realizes that things are well and truly screwed up a hasty meeting is called to talk about governance.
- The question now is….what are we going to do about it??
Don’t despair. It can be fixed and yes it’ll be a lot more time consuming and expensive than had you done it right in the first place – but come on. Where is the fun in that?
The first step to doing it is getting agreement that it actually needs to be done in the first place. After a prolonged period of staring into the cold dead eyes of people that could not be less interested the following questions may arise:
- Who cares if IT backs up 200 gigs of data they don’t need?
- Doesn’t it work fine now?
- How much is this going to cost and how long is it going to take?
- Why did you let it get this screwed up in the first place?
These are all semi-legitimate questions but there are some much more important questions to focus on:
- What is the business risk of not having any idea who is responsible for the content on half these sites?
- With more than 400 SharePoint security groups how can we realistically know who has access to what? What is the potential risk?
- What kind of information is currently being stored on our portal? Do we know?
- How much time is spent on an ongoing basis on calls to the Help Desk to answer questions related to this debacle?
- Is it a value-add to the organization to have 5 sites focused on the same basic operational requirements with redundant data, different users, different owners?
So we all agree that the current situation is not sustainable and we decide that we ARE going to slay this beast once and for all. So let’s get started! … …. That sound you hear is in fact the sound of crickets.
The first thing you need to do is understand what you currently have to work with. This means an understanding the hierarchy of every single site collection on your portal. I personally like the visual approach. There are tools out there that can help but I’m a fan of Visio for this for a few reasons. The first is that going through it manually is helpful to me to understand and remember some of the thinking that took place for why things are currently structured as they are. The second is that the physical and mental anguish that is caused by doing it is an excellent incentive for being more proactive from now on. It’s also an excellent opportunity to weed out the sites and content that are obviously obsolete
The next step is to figure out who actually owns the sites/content. There are tools available to do this but I always find it advantageous to use these types of opportunities to build and strengthen relationships.
Then comes security. This is just not fun at all. You need to truly understand what SharePoint, AD or whatever groups are being used throughout the portal, who is in them, what they have access to. You also need to understand which ones are not being used. A strategy around security will come later.
What do we do?
So now that you know what you’ve got what does it mean? It actually means pretty much nothing unless you can put things into a relevant context – like the operational structure of your business. So for example, part of your business might be an initiative to focus on global business process standards. You currently have sites for these types of activities under finance, purchasing, IT etc. & across site collections. This might be fine but it might make no sense in your organization. Business processes might be related to financial reporting or how we build a new building. Is there an executive responsible for the overall standards initiative? Is there a common language related to these standards? Is the content public? These are the types of questions that need to be answered before you can really move forward.
This kind of conversation should take place on a regular basis, preferably people with some actual skin in the game. Business needs and priorities change all the time and your SharePoint implementation must evolve in tandem – not 4 years afterward – or never.
Do 1 first
Remember that a SharePoint implementation is a journey. But you don’t, and in fact can’t, tackle this all at once. So focus on an area that is strategically important to your organization and do it right. Use those lessons on the others going forward.
Contact the executive/manager responsible for the initiative and explain to them the current state of affairs and the business reasons for undertaking this project. Before he or she gets the chance to tell you that this is the stupidest idea they have ever had the misfortune of hearing, you need to be able to cough up real data to explain the current state of affairs. Such as:
- You currently have 6 separate groups of people focused on standards. They are using SharePoint and have no idea what the other is doing.
- There is 50 megabytes of standards data that has been uploaded and it’s extremely difficult to find if you don’t know where to look.
- 4 of the sites have different versions of the same documents on them
- If someone moves departments you are going to have 500 documents to change the permissions on individually. Then explain just how fun and what a value-added activity that is.
It’s important to be able to sell the value of moving forward as well. Search is always a good one. Telling someone that you can work with them to understand their initiative and one of the outcomes is that everyone that wants to find the information they need will be able to do it the first time, every time (a little hyperbole never hurts).
Understand What You’ve Got
Once there is agreement on prioritization of focus you need to gather the stakeholders in the room and truly understand what you are dealing with. What are people trying to accomplish, what are they supposed to be trying to accomplish, and what are they actually accomplishing? This is requirements analysis 101 with the caveat that people are going to have some an emotional stake in what they have done. The last thing they want to hear is some dude tell them that what they have been working on basically sucks.
This involves an assessment of the sites, structure and content as it currently exists. It also involves understanding the business processes that are driving the need for the sites(s). If your company is anything like the ones I have worked for no such documentation will exist. It’s important as well not to lose focus on the task at hand when you are having these conversations. If you get into wonderfully deep philosophical discussions about how great things could be and all the things that are possible you will resemble Yoda by the time this project completes.
You also need to understand the content, what purpose it serves, how much there is, where is located and why. I won’t delve too deeply in the ideas of taxonomy and information architecture here as there is tons of material on the web that can provide guidance. Suffice it to say you want to get your new local heroes to think about and understand the language of their business so you can teach SharePoint what it is.
What is the security situation like? How is content secured? Is it at the site level, list level or the document level? Are groups managed in SharePoint, Active Directory, Outlook or somewhere else?
Rolling Up Our Sleeves
Well, there is no time to start like the present. I fully realize this is a drastic oversimplification but my intention is too simple to provide a broad framework for how you might go about a task like this.
Look for more in an upcoming post…