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?
- 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.
- Assign each Task/Action Item/Objective an "owner," from among the team site Users.
- 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.
- 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 and social informatics, primarily in the health care and HR industries.