Five Years of SharePoint

Recently I accepted a new position as a Software Development Manager, not working with SharePoint; this is an exciting new challenge for me, as I’ve been fully immersed in the technology for some time now. I started working with SharePoint at IBM 5 years ago, and since then I’ve worked with various deployments pretty much coast-to-coast in Canada, from Vancouver to Ottawa to Halifax. I wanted to make a post reflecting on 5 years of working with Microsoft SharePoint, and discussing at a high level some of the observations I’ve made of the various SharePoint deployments I’ve worked on over the years in order to help others understand what makes SharePoint a success (or failure).


“Governance uses people, process, technology, and policies to define a service, resolve ambiguity, and mitigate conflict within an organization.”
― Joel Oleson, 10 Steps to SharePoint Success

Governance has always been a hot button topic in SharePoint, and will be for some time; in my opinion, lack of Governance is one of the primary sources of frustration and failure for every SharePoint deployment. This conflict is tragic, because at its heart Governance is the simple act of planning and setting expectations, something which everyone acknowledges must be done, but all too often do not actually do.

For many organizations, Governance is the opportunity to take a moment before implementation and actually think about:

  1. How do we intend to use SharePoint?
  2. What are the limitations of  our SharePoint deployment (technical, human resources, knowledge, or self-imposed)?
  3. Are there legal implications we must adhere to, and how do we do that in SharePoint?
  4. What specific challenges will be addressed by specific features of SharePoint?
  5. What are the expectations for the various stakeholders (Executive, IT, trainers, end users, etc)?

#5 is a big topic, because this is where a lot of conflict comes into the organization. At some point, someone will think it was someone else’s job to fix/ prevent something bad that happened, and if you don’t have some kind of written policy or process, you’re asking for a round of the Blame Game, and that’s just poison in any organization.

Setting Objectives

A common objective when deploying SharePoint is “increase collaboration and communication”, “provide document sharing”, “use SharePoint as a development platform”. I would argue that these aren’t objectives, they are aspirations, because they are exceedingly difficult to measure through hard data (user surveys are difficult to count), and they represent broad, amorphous goals. Sure, there may be 400,000 documents in SharePoint, but that’s a storage metric, not a collaboration metric that indicates how, when, and if people are actually using those documents and to what effect.  How can you measure if someone is communicating more effectively? Perhaps you could infer that by seeing that people are performing more work in shorter periods of time, but maybe that’s just the espresso machine you installed last month.

An objective is something that can be measured, well, objectively, and contains two critical ingredients:

  1. What you are trying to do
  2. What will tell you that you did it

Good examples of objectives are: “Use InfoPath, SharePoint, and SharePoint Workflows to reduce TPS-421A form processing time from 5 days to 3 days.”, or “Reduce meeting minute approval time from executives from 20 days to 10 days”.

Objectives can be on the micro-scale, but tie into the broader strategy of SharePoint as defined by your Governance. As objectives are met, those successes should be celebrated, and similarly if objectives are not met, those failures should be analyzed, lessons learned, and finally addressed; either way, there must always be new objectives developed and added to the list.

Simply put, if something cannot be measured, it cannot be managed. If a system – any system – SharePoint or otherwise – cannot be managed, then you have real and serious problem on your hands.

Make the Technology Work for People, Not the People Work for Technology

There’s a common saying among a lot of SharePoint admins I’ve worked with that people have to learn to do things “The SharePoint Way”. I spent much of the early part of working with SharePoint trying to get people to change how they work towards The SharePoint Way, with mixed success. Sometimes people have been doing a process for 5, 10, or even 15 years, and they’ve seen technologies like SharePoint come and go. You can’t expect to make people’s processes change overnight, particularly if they haven’t been sold on SharePoint. When I started to see real success, it was because I accepted that people have a process that can be fit into SharePoint, and that SharePoint can be adapted to fit people as well – in essence, finding a middle ground between people and technology.

When you start showing people that what they do can work in SharePoint, and often much more efficiently than without SharePoint, you not only make people more productive, you often find internal champions that are willing to promote and teach others when SharePoint administrators aren’t around.


It’s an exciting time for SharePoint and Microsoft. SharePoint, like so many other services and applications, is jumping headfirst into the cloud. Yammer stands to change SharePoint in a fundamental and overwhelmingly positive way. With Steve Balmer leaving the big chair, and other leadership changes at Microsoft, there are some great opportunities for positive change and development – particularly in the cloud and mobile arenas.

While I may not be working with SharePoint day to day as I have been for years, I look forward to seeing how the technology changes over time and continues to meet the challenges of the various organizations and businesses that deploy it.





Why IT Can’t Own SharePoint (And Why Business Users Can’t Either)

Inside just about every organization that uses SharePoint, there’s a quietly seething war happening. No, it’s not between you and the person that keeps stealing your food from the fridge – but honestly, who does that?

It’s between the SharePoint IT crowd and the business end users.

Both sides think the other abuses SharePoint and makes it unusable, and both sides think that the other should just shove off and let the people who know what they’re doing handle the situation. This kind of conflict happens most often when strong governance isn’t in place before, during, and after SharePoint is deployed – since governance is almost always either totally undeveloped or underdeveloped, the battle between IT and users is a common one.

So What’s The Problem?

There are two fundamental approaches to SharePoint:

Scenario 1: SharePoint Owned by IT

IT is told to deploy SharePoint to allow people to collaborate, communicate, and various other ate’s. Usually this means a server admin installs SharePoint, gives the business user(s) limited access (usually Contribute), and considers the service request fulfilled. Business users are given the URL, told how to login and left to their own devices. IT favours this approach, as they tend to dislike relinquishing control of their infrastructure and resources to non-IT personnel. Business users tend to hate this approach, as they must now must submit tickets to IT for just about everything you can do in SharePoint: manage permissions, create lists and libraries, etc.

The conflict between IT and business here comes from business feeling like they’re constantly on a leash that IT holds. Business wants to do things right now and doesn’t have time to wait on IT to get what they need done, and they don’t want to be subjected to IT decisions such as server moves, downtimes, etc.

Scenario 2: SharePoint Owned by Business users

Usually this scenario happens when a business user catches wind of SharePoint at a conference, trade show, or meeting with a colleague, and and it’s love at first site (pun intended). Someone within business with some tech savvy and initiative fires up a server, installs SharePoint, and lets the business user community go at it. Business users really love this approach, as they now have a powerful technology stack under their complete control, which they can (in theory at least) make jump through the hoops they need jumping through. IT, on the other hand, is fuming mad, because they definitely do not like being kept in the dark when it comes to someone deploying servers in their environment, especially when something blows up a year later and are told that they have to fix it.

In this scenario, the friction comes from IT feeling left out of the decision making process and told they need to clean up when something business has chosen to do has blown up. Most often IT will propose bringing the server ‘into the fold’ to which business users will dismiss outright and fight tooth and nail to keep their toys in their backyard. IT becomes frustrated because they become a cleanup crew, but business enjoys it because they get all the benefit, and risk is absorbed by IT.

Power Up To 11

SharePoint doesn't do 10.
SharePoint doesn’t do 10.

At it’s core, this whole situation is a power struggle. In Scenario 1, IT feels empowered but business feels powerless. In scenario 2, it’s just the opposite. Neither approach truly works, because it creates a lopsided power dynamic that always leaves one side mad, frustrated, and wanting to hit the “ABORT” button on the whole thing.

The only solution is to establish a hybrid model – a power sharing approach that involves both groups to empower each other.

The Fix: IT Enables, Business Executes

Coffee Talk

The most first step is to have IT and business stakeholders sit at the same table, ideally as a part of a larger governance committee. The various stakeholders from both sides need to flesh out the divisions of responsibility and the expectations they have for each other.

In essence, both sides need to communicate with each other and on a regular and permanent basis. It doesn’t work to have one meeting before kickoff, and it doesn’t work to do it sporadically when people feel like it (and for God’s sake don’t do it on a Friday afternoon). Depending on your level of use of SharePoint, this could mean a bi-weekly or monthly meeting between IT and business to keep each other informed and head off issues and conflict before it even happens.

A great tool baked right into SharePoint to facilitate this kind of integration between IT and busines are Blogs. I’ve found creating a blog where technical and non-technical stakeholders can post updates, discuss issues and keep each other informed is invaluable.

Render Unto Caesar

Caesars camera by John Kratz, on Flickr
Seriously, don’t touch his camera, Caesar gets mad.
Photo: John Kratz on Flickr

After the initial discussions above, you should start to have a pretty clear understanding of where each of the responsibilities lay.

Let’s be honest here: business users do NOT want to have to deal with server health, backups, patches, combing through the ULS logs troubleshooting, etc. Nor should they! This is IT’s bread and butter. Business users should be focusing on business: how to improve, how to be more efficient, how to use the tools.

Similarly, IT should not have to be contacted every time permissions have to change or a list needs to be created – this is the day to day business side, and frankly IT has better things to do with their time. Therefore, business users must be trained and trusted to take on all of the day to day responsibilities. Training is critical for both sides, because the more training they each have, the more they can focus on getting work done and the less they have to ask the other side to solve their problems with SharePoint.

In my mind, the business owner of SharePoint should be able to perform all of the operations available to them up to the Site Collection Administrator level; everything from managing permissions to workflows and sandboxed solutions. IT, on the other hand, should have the knowledge and ability to proactively address issues before they become problems, and work with business to quickly address problems.

Magna Carta

What we’re talking about above, really, is governance. Stakeholders coming together to define and work together to determine the who, what, when, where and why of SharePoint as a tool. Write down the outcomes from these discussions. Share what you’ve written down with the group. This is how you can start to develop a framework for governance that can be built on over time. Governance doesn’t have to be a giant, monolithic project (but you do have to address it at some point), you can start small and iterate to a larger goal.

Wrap Up

SharePoint is a unique bird in that it will starve if one group keeps a strangle-hold, but it tends to thrive when multiple groups buy into the technology and work together to develop it into a success. IT and business aren’t mutually exclusive, they’re part of the same workplace ecosystem, and as such, what’s good for one side is good for the other. IT and business can work together, and indeed they must work together if SharePoint is to be a cause for celebration rather than a source of conflict.

Don’t Start With SharePoint

A question SharePoint administrators are often asked is: “Can we make a [time entry system/ inventory tracking/ other application] in SharePoint?”

The answer is usually: Yes. Absolutely. Maybe. Sorta. Hold on a second.

Why Are We Making This In SharePoint?

Usually the response to this is “We want to strategically leverage our existing investments in technology to maximize our ROI”, which is a fancy way of saying “We want to use SharePoint because we have it.” and absolutely that’s part of the answer. If you’ve invested the time and resources into deploying SharePoint, you should use it.

Most often, however, the real answer is “Because it’s easy to make stuff in SharePoint”, which is a dumb guy (that’s me!) way of saying “Deploying a solution in SharePoint would provide a value-added opportunity for minimal development investment”.

Users know that in 10 minutes, you can have a site up and running and be creating custom lists and workflows up the wazoo. No other platform affords that level of ease of use and development. It’s one of SharePoint’s greatest strengths, and also the reason why it so often gets abused (unless you have strong governance, in which case internet high five).

Requirements Schmequirements

Since SharePoint is both easy and available (hey, wait a second..) users will often forego the requirements gathering and project definition phase and jump straight into “I gotta box a’ Lego and I’m gonna build something!” phase. This is a huge problem, not only because it virtually guarantees scope creep and Rube Goldberg-ian solutions, but also because inevitably, you run into SharePoint’s famous out of the box limitations.

Cart before the horse SharePoint Development
Whoa there, Buttercup

Achtung, Baby

In SharePoint, the out of the box features usually get you 80-90% of the way to your goal. The other 10-20% forces you to make the tough decisions:

  1. Buy a third party solution (If it exists)
  2. Develop a custom solution (Open wallet wide. Wider.. wiiiiider, that’s it. This may sting a little.)
  3. Live without it (But I really, really wanted it, dad!)

If you don’t sit down and work out your Project Management 101 type stuff (background, objective, definition, requirements, budget, etc). You are going to run headfirst into that 80/20 wall at 100 km/h. After you’ve already invested dozens or hundreds of hours, spent much of your budget, and have a mostly-working solution, you may find that options 1-3 above leave a bitter taste in your mouth and cause you to utter the fated words..

“I Hate SharePoint.”

I hear you, and I’ll let you in on a trade secret: Just about every SharePoint Administrator I know hates SharePoint. But not really. SharePoint can be a tumultuous beast sometimes. You have to keep in mind that SharePoint is like a toolbox full of tools. It’s easy to pick up and start banging around making stuff, and that’s great. However if you need to dig the foundation for a house and all you’ve got is a hammer, you’re going to have a bad time, and maybe it’s time to look at buying a backhoe.

Use Your Thinking-Meat

(That means brains, for all you rocket surgeons our there)

I’ve never been a fan of falling into the trap of when you have a hammer everything looks like a nail. I don’t believe that SharePoint is all things to all men, because frankly nothing is – if anyone tries to tell you differently, don’t believe them. It’s more important to figure out the best execution for a solution to a problem than it is to try and shoehorn the solution into the problem and hope for the best.

So sit down and work out who you are and what you’re trying to do. Write it down. Leave SharePoint out of it. Be a technology agnostic and just figure out the what the best possible solution for your project is. Once you’ve done that, you can look at how far SharePoint’s out of the box features will take you, and what it will take to get you the rest of the way.

Maybe that means deploying your time entry system in SharePoint; or maybe that means calling up SAP, I don’t know. The best thing you can do is figure this out before you’ve gone so deep down the road you’re on you’re forced to make some potentially very hard decision.

So don’t start with SharePoint. Start at the start, with requirements, and when you reach the end, stop.