You think you use SharePoint but you really don't

Thousands of organizations have implemented SharePoint but fail to exploit the most obvious of SharePoint's many benefits. Here are some suggestions for a SharePoint roadmap that can succeed.

You see it all around you, good SharePoint gone bad. The number of SharePoint deployments in the world today has six digits in it, and four-fifths of them suck. That's a subjective observation, of course; many who deploy SharePoint (especially the license-free version) don't have very high ambitions. The irony is, they could aim much higher, and get a lot more out of their deployment without upgrading to the more expensive version.

Since "sucks" is a less-than-technical term, let's give it a focused definition: there are many organizations out there that have implemented SharePoint - with good intentions, surely - but have improved neither their processes nor their culture thereby. But the implementation that really sucks is the one that actually takes the big messes that existed in the legacy environment and simply recreates them in SharePoint.

The typical pattern is something like this: 1) the organization has the epiphany that file shares are out of control, and content management is sorely needed; 2) SharePoint is deployed throughout the organization; 3) files are moved out of file shares and into SharePoint; 4) they rapidly spiral out of control.

Adding insult to injury, the failure of SharePoint to solve the content management issue diverts the organization from exploiting SharePoint's other game-changing features. SharePoint persists - no one in their right mind would actually roll back those awful file shares - but nothing new gets done.

Let's start with the two biggest problems ... which are also the two that are easiest (and cheapest!) to fix.

Share and share alike

After years of consulting on content management issues, I'm prone to stating that most organizations birth file shares in places where John Conner would feel right at home - dystopian wastelands fraught with unforeseen peril and sudden eradication. Any organization that doesn't have at least one such file share lurking about ought to be immortalized on The History Channel.

What tends to happen is this: the file shares get chopped up at the subdirectory level (depending on who owns what, content-wise) and shoved into SharePoint by means of the Windows Explorer View interface (which is fake, but convincing), preserving the trickle-down hierarchical file structure of whatever chunk of the tree the content owner is moving. This doesn't simply transplant the data - it also transplants the problem.

What should you do, instead? Eliminate folders altogether. I know, it's like giving up reruns of Andy Griffith (or Cosby, or Friends, depending on how old you are), but file folder hierarchies are the single biggest cognitive shortcoming we possess, as a result of our years in IT. SharePoint exists, in part, to liberate us.

Move all that file-share content over into SharePoint libraries, yes - but make the libraries themselves the top-level folders. Once you parsed at that high level, don't parse the child folders as folders! Instead, drop everything into the appropriate SharePoint library, and then establish columns (metadata) that define the organizing sub-levels that the resulting files require, and create views for each library that display files according to those columns.

What is the end result? Each library you create is a superfolder of sorts, able to be all folders to all users, depending on their view. A single folder can represent dozens or even hundreds of subfolders - and instead of hosting content defines in single dimensions (a necessary restriction of the traditional folder hierarchy), you're now hosting all those files in as many dimensions as you need - and asking fewer mouse-clicks of your users to get to it, in the process.

Stamp out email abuse!

I've ranted about this before, and I surely will again: There are lots of us out there who should be jailed, or at least made to do community service, for our crimes against Outlook.

Crime #1: Long chains of email become de facto meetings. Those of us who use Facebook - almost everybody - are familiar with the occasional lengthy thread that results when somebody posts some really interesting or important status, and many additional posts are made to the original status, resulting in a substantial (and often controversial) thread. Now - tell me this doesn't happen in your workplace, in email. You may not be an instigator (God bless you if not!), but you've almost certainly been hostage to this scenario, probably more than a few times.

Crime #2 (even more despicable than Crime #1): These long email chains are actually saved as project documentation. And from a content standpoint, it's actually legitimate!

The solution to both of these problems?

  1. Set up a List in a SharePoint Team Site. Make all of your project participants Users of the team site. This List will contain all of the tasks (or action items, or objectives, whatever is appropriate) for a particulat project.
  2. Assign each Task/Action Item/Objective an "owner," from among the team site Users.
  3. Set up email alerts on this List, so that any participant is notified when one of the Tasks/Action Items/Objectives is modified (notified via Outlook - which limits email to its appropriate role in the process!). These alerts will contain links that will take the participant directly to the Task/Action Item/Objective, opening it for them in SharePoint.
  4. Have all of your participants pass along their input or contributions or reviews as comments in the List items. For all practical purposes, this input will be exactly the same as email - date/time-stamped, credited to the author, placed sequentially among all such entries - except that it will all exist in one place, a secure and properly administrated place (as opposed to email!).

... and you have all of the benefits of those email threads, with none of the shortcomings.

With just these two steps, an out-of-the-box SharePoint deployment can go from a turkey to a tiger. But even this is just the surface of what out-of-the-box SharePoint can do. Another step or two down the trail is process automation, collaborative power you've never harnessed before, salvation for project managers and a potential application hosting platform that can consolidate your security and administration efforts into a single global model. And each of these we will visit soon.


Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...


Every project I have worked on had a Sharepoint set up. At the start, everyone tries to upload their files and send each other links. After a week, people remember why they stopped using Sharepoint in the last project - its clunky, slow, unreliable, intranet only access - totally useless when you are all working on a customer site.They all revert to emailing documents to one another, and their laptops hard drives & MS Exchange become the project repositories. Given the choice between paying lots of money for a basic file share / Dropbox and email, or getting Sharepoint for free, I would pay the money and take the file share. Maybe this is not the best way of working, but people will always gravitate to the most convenient way of working, and Sharepoint will never be it. Until there is a secure, user-friendly Dropbox-like solution for content sharing, people will continue to email files to each other.


Microsoft does it again - somehow they killed 1-2-3 with an inferior Excel and once more, when Exchange is horrible and SP sucks -- it's time to get corporate IT to dust off Lotus Notes.


I think the main reason projects are not successful is because SharePoint paradigm is really out of touch. It's much easier to implement things like wikis using different tools. We have a few applications and they don't work that great, there are issues with the workflow where some of the documents just fall through the cracks. IE is required, I have tried to use other browsers and they just don't work. It's rather complicated to create filters. The search is marginal at best ... This is unfortunate as a collaboration tool is really needed in our environment but management is not willing to spend money upgrading to the latest version.


"The number of SharePoint deployments in the world today has six digits in it, and four-fifths of them suck." As one of the suckees, I got a lot out of this article. Indeed, I have a meeting in ten minutes to discuss another potential SharePoint use here. The problem I have is that I don't know when it is appropriate to use SharePoint vs. our existing traditional shared network folders. There's also the issue of user training. They already know how to use network folders, and I haven't found a reason to force them to do otherwise. I've never seen a 'working' collaboration configuration, so I don't know exactly what we're trying to accomplish. Even within the IT department, we don't eat our own dog food. We're in the middle of an Active Directory migration. Most of the collaboration takes place in meetings; most updates are via e-mail. We have a few procedural documents in SP, but those are usually also e-mailed (as attachments, not as links to the SP site).


Excellent article, Scott! Though I would go a little further and make it one library appropriately parsed by views or permissions depending on security requirements. I'm sure I'm preaching to the choir here, but SharePoint is vastly underutilized in almost every company. Another of my gripes is that too many developers fall back on their strong knowledge of C#/VB code to create a solution instead of researching SharePoint (SP) to find a more OOB solution. I suspect at least 2/3 of coded SP solutions could have been done without the code. Of course, then it becomes a matter of how much time is the developer willing to invest (and the client to pay for) to find the SP solution? What to do? LEARN MORE SharePoint! If anything, SP constantly teaches me humility, but I still keep coming back to it (kind of a love/hate thing). Keep the great articles coming, Scott!


We have been using discussion boards in an effort to attack item #2. Users who care about certain discussion boards can attach the board to their outlook file and monitor from there (the place that they seem to live the west). Not to say that a bunch of crap doesn't leak into the conversation trail, but at least it gets captured outside the email folders of the team. I like your implementation as well. Care to comment on the advantages/disadvantages of your implementation versus discussion boards?


more on sharepoint like this please. the thing i find most difficult being a one-man IT shop is never seeing anybody else's implementation and get inspiring ideas where i can. I liked your previous sharepoint article too but it seemed to end when it just started getting good.

Editor's Picks