In my last post, I outlined the decision point that the SharePoint user community faces right now. I caught some flak after the post that I want to address here head-on: some folks pointed out that whatever SharePoint can or can’t do in theory, in practice SharePoint implementations frequently fail to provide improved document management…and organizations find themselves with as big (or bigger) of a mess as they had with shared drives, Lotus Notes or whatever else was in place before SharePoint came along.
Now, I see SharePoint in action, day in and day out among my clients, so I think I have a good perspective on this issue, both in terms of how to fail at SharePoint as well as how to succeed. That having been said, with this post I want to provide a bird’s eye view of how you can use SharePoint successfully to move off of your current ailing repository of choice and provide improved document management capabilities to your organization. Next post, we’ll drop down a bit into the weeds and look in some detail about how you go about implementing the best practices I introduce here.
Depending on what source you rely on, something like 60% of restaurants close their first year — not very good odds. But given my experience with SharePoint in my work as a consultant, those are better odds than you have of successfully deploying SharePoint. So if you’re in charge of SharePoint at your organization, you might want to think about a career change.
And given the amount of SharePoint bashing you see on the Internet and the sheer number of failed client installs you hear about, this shouldn’t come as too much of a surprise to anyone. But to my mind, this lamentable situation isn’t a SharePoint problem, it’s a how-organizations-build-deploy-and-support-technology problem.
To make my point, just leave SharePoint out of it for a minute: how many of you work for organizations that consistently deliver IT solutions on time and on budget (and that tend to meet the needs of the end-users they were designed for)? If I could see you all out there, I imagine there wouldn’t be too many hands up in the air right now.
Let’s face it, IT delivery isn’t done well at most organizations, so to expect IT to do SharePoint any better than it does other technologies and platforms is a bit unrealistic.
Time for a Change
So, you may be asking yourself, if the odds are stacked against succeeding with SharePoint, both because SharePoint tends to underperform and because IT departments generally have such a hard time delivering tangible value, why move to SharePoint at all?
Two reasons: first, the electronically stored information (ESI) in corporate repositories is growing at an alarming rate (in my travels, I routinely see growth rates of 50% and sometimes even higher), so doing nothing is no longer an option for most organizations (or at any rate won’t be for much longer); second, the move to SharePoint (or any new document management system) holds out the hope that we can get it right this time…if we just stop cutting corners and engaging in the worst practices we’re all aware of (but for some reason find ourselves unable to avoid time and time again).
If You Build It, They Will Not Come
The most important fact to wrap your head around is the fact that deploying a generic, one size fits all SharePoint environment will, four times out of ten, fail to gain the kind of adoption needed to make a difference in your organization’s document management landscape; another four out of ten times, adoption will take off like a rocket, with SharePoint expanding exponentially and growing like a weed at the organization with no planning or governance in place; two out of ten times, the "if you build it" approach more or less works, resulting in good adoption and a fairly governed SharePoint environment.
Not the kind of odds I want to bank my career on, so let’s explore some ways to improve those odds by approaching a SharePoint implementation with some more rigor and structure.
What I want to do in the rest of this post is to introduce two key concepts that will help you structure your document management initiative (using SharePoint as an example) to better ensure success: process analysis and capabilities mapping. Neither of these is rocket science or brain surgery by any means — they’re both pretty much business analysis 101. But eating right and exercising are equally basic concepts, and look at how few of us practice them.
You’ve Got to Know What You’re Doing
No one uses SharePoint for the heck of it; people use it to accomplish business objectives, i.e., SharePoint (and any technology, really) is a means to an end, not an end in itself.
So, the first step is to figure out what your users will be using SharePoint for. Or, asked another way, what are they using their current document management system/repository for? By the way, “storing documents” is not a good answer to this question — you need to go deeper to reach the specific business activities that as-is technology like shared drives, hard drives and email support.