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.
To give an example, storing IT documents is a poor description of a business activity, whereas running IT projects, operating IT assets and managing IT administrative functions are much better examples of the specificity you need to get to if you’re going to successfully enable them in SharePoint.
You’ve Got to Know How You’re Going to Do It
Now that you’ve gotten more specific about the business activities that you need to support in SharePoint, you can hone in on the SharePoint capabilities needed to support those activities. And whether you do this on the back of a napkin or with a fully developed capabilities matrix, you’ll be able to get to a much more detailed, nuanced picture of what your target SharePoint environment needs to look like to meet the needs of your end users than you could ever get to using the if we build it, they will come approach.
After all, SharePoint is less an application than a platform on which you must build applications, so deploying it “out of the box” or “vanilla” tends to deliver little value. Where SharePoint (and any other Enterprise CMS) begins to really shine is in the application of its functionality to clusters of capabilities that enable specific business activities.
The Final Word
So much for the overview of how to think about a successful SharePoint implementation. In the next post (or two, or three), I want to lay out a specific set of steps that allow an organization to detail and articulate the key business activities in scope for their SharePoint project as well as how it can connect the dots between these key business activities and the capabilities and underlying functionality that will enable the activities. The ultimate goal of all this being the delivery of business applications built on SharePoint that meet user needs and enjoy broad adoption, allowing you to retire older, less fit for purpose document management systems.
But in the meantime, SharePoint is a hot topic here at CMSWire, so I’d love to hear what you all think out there about the approach I’ve sketched here -- jump in and let’s get the conversation started!
Editor's Note: You may also be interested in reading: