Do you hate Sharepoint? Part 2 of 4

If the answer is yes, could your hatred be caused by your local implementation? In this second part of our blog series we continue to explore four common problems with SharePoint implementations and how you can address them.

Once again, a huge thank you to Neil McIsaac, SharePoint MCT, for putting this together. Happy reading! If you missed Part 1 – Information Management, you can read it here

SharePoint is an interesting platform and as it grows as a product and with its already incredible adoption, it is an important cornerstone for many organizations. But ask the people that work with it, and you will find a divided love it or hate it passion for the product.

Why hate it?

It’s my experience (which dates back to the site server/dashboard days), that many customers have difficulty handling the product and I mean this a number of ways. Here’s the issue:

SharePoint will amplify your problems.

So why do we hate it? I would hate anything that made my problems larger. But did SharePoint create the problem? That would be like blaming the carpenters hammer for building a crooked house. The problems are our own doing in the majority of cases. In my experience, the most common problem SharePoint seems to amplify are the following;

1. Information Management
2. Project Management
3. Information Security
4. Business Intelligence

Last week we looked at Information Management, this week let’s look at Project Management.

2. Project Management

There are some interesting numbers on the frequency in which SharePoint projects fail. I won't bore you with numbers mainly because individually they succumb to a lot of subjectivity, but ask anyone that's been around the block a few times and they will tell you that the majority of SharePoint projects fail. Why? Blaming SharePoint for a bad project is kind of like blaming a poor house design on the hammer in the carpenter's hand. SharePoint is a tool, albeit a very complex one, but the result is always the result of its usage and rarely the tool itself. SharePoint has its quirks, the vast majority of products do, and part of a proper SharePoint implementation is to address those quirks as best we can. But that's not where projects tend to fail. The common culprits are the following;

Scope management

This is a really tough one to control in a SharePoint project. When the decision has been made to use SharePoint and people soon realize that it has the potential to solve the majority of your organizations problems, many organizations attempt to solve everything at once or completely the opposite, choose to only solve a single problem with SharePoint.

SharePoint projects are commonly either scoped too large, or too small. Too large a scope, and you are overwhelmed trying to coordinate a very complex solution. You get bogged down with the intricate under wirings of your organization to the point that your project will be stuck in the requirement gathering stages for years. I've seen it. I've seen organizations that have planned for a year and not really yielded any results. On the other hand, organizations that start too small usually create an inadequate solution for growth. So where is the happy medium?

To properly manage scope within a SharePoint project you need to understand a bit of the big picture of your environment and then focus on one problem at a time. The best place I have found to start is by establishing proper Use Cases for your organization, and not just the ones you think should go into SharePoint. Properly created Use Cases are one of the most powerful architecture tools that we have in IT and is something that every IT department should have on hand already. They truly help focus our solutions to be task oriented and not data oriented. By understanding what our people do or need to be able to do, we can create a better solution for them. After collecting Use Cases, we need to establish an overall vision for the SharePoint solution. This can be a little bit daunting to staff that are new to SharePoint structures. If we look to our Use Cases, we can group the cases that are shared by common roles with the idea being that those roles should be able to complete those tasks as easily as possible. By grouping them, we can establish areas in SharePoint where an employee in that role can go to and complete those tasks. We now have an idea as to the scope of our project - make an area in SharePoint do cases x, y and z. Many areas can be identified with their Use Cases bound to them, and realistic timelines could be better established for each area.

Requirements Gathering

Most organizations feel they are pretty good at requirements gathering because they've been doing it for so long. In my experience, they've just established that they don't understand process improvement. It is the question "How can we do this better?" where we establish our daily pursuit of perfection and question our assumed excellence. There is a lot of information elsewhere on different approaches, so I will cut this down as simply as I can. If you are not using an iterative process in your IT projects, you are doing it wrong, plain and simple.

Have an Architect

I should expand on this a bit. You should have a qualified SharePoint architect or architecture committee. "We don't have one, so where can we find one?" Good luck. There are a lot of lousy consultants out there for various reasons, but you really need to have a good architect in an IT project who understands the impact of various choices they make. When it comes to SharePoint, I offer this advice. Give your solution architect a business problem you wish them to solve in SharePoint, and ask for 3 different solutions and the pros and cons of each. If they can't do it, RUN! They are obviously under-qualified to be supporting you. A really good architect should be able to rough out more than 3 different solutions.

Testing

Wow. This is one of my absolute worst pet peeves of the IT industry. If the only testing you are doing is User Acceptance Testing (UAT), and maybe some regression testing, you have really missed the boat. I have a whole spiel on this topic which I will save for another blog someday. When it comes to SharePoint, test your solutions including your code and go beyond the question of "Does it work", and ask "Does it work well?"

Use SharePoint to run SharePoint

This is one of my favourites mainly because it is one of the most overlooked. I often ask my clients how someone in their organization would go about creating a new site, say, to manage a project. The answer is typically that the person making the request would send an email to their manager, where it would eventually be forwarded to IT after a couple of emails going back and forth for approvals and information gathering, an IT staff member would then go and manually create a site for the requestor. My reply usually goes something along the lines of "So, you gather some required information, invoke a workflow with steps for approvals and further data collection, and create a site based on the data. Why isn't that automated in SharePoint?" By using SharePoint to manage SharePoint, you can establish a more consistent structure and daily routine. In the above example, the data can be collected via a list. Workflows can be initiated for the approvals and further data collection and in the end a site could be created automatically as the final successful step in the workflow process. The result would allow IT staff to be involved less, the results more consistent since we reduce the amount of manual steps, and the process to flow much faster. Managing IT requests are also business procedures so don't ignore them when developing your Use Cases for SharePoint.

Next week part 3 Information Security…