In my last post, I sketched out at a high level what I see working at organizations trying to move off of older repositories onto SharePoint. 

What I want to do in the next few posts is walk through a process that, while by no means a silver bullet, gives you a better chance of success than the typical approach.

You can read my previous post to get more details, but the gist of it was, if you’re going to build a successful SharePoint application, you need to know what your users are going to do with it and what capabilities they require to do so.

Seems like common sense. But I can count on one hand the number of organizations that I’ve seen actually follow this advice. More often than not, folks roll out a vanilla, one-size-fits all SharePoint environment and hope that if they build it, they will come. The result is either that they don’t come, and SharePoint is a dud at the organization, or that they do come in droves…and use SharePoint in the same ways they used their old repositories.

In either case, what you haven’t done is leverage SharePoint to its fullest or provide your end users an improvement over what they now have.

With that in mind, I developed the following steps to increase the likelihood of a successful SharePoint implementation:

  1. Process mapping
  2. Process triage
  3. Process redesign
  4. Capabilities mapping
  5. System design and testing
  6. Migration planning
  7. Communication and training
  8. Go live

And while this may seem like software design and development 101, frankly, that’s what most organizations need based on what I see passing for SharePoint deployments out there.

To keep this post grounded in details, let’s use the most prevalent legacy document management system out there: that unholy trinity of shared drives, hard drives and email.

Your Users Already Have a Document Management System

The biggest mistake you can make in trying to move users off shared drives, hard drives and email is to think that they currently have no document management system and that these three repositories are simply buckets into which users dump their documents.

The truth is that as much as we enterprise content management practitioners like to lament the use of shared drives, hard drives and email, the majority of document management going on at organizations uses them. And make no mistake about it, these three systems are more than simply buckets: they are supporting business-critical document-centric processes. So if you hope to replace them and actually deliver improved capabilities to your users, you better understand what business processes shared drives, hard drives and email are supporting.

Step #1: Process Mapping

The first thing you need to do is to determine what document-centric business activities folks are currently using shared drives, hard drives and email to support, because these are the processes SharePoint will have to support in the future state. If you don’t, you’re headed for a vanilla implementation of SharePoint, one that will become little more than shared drives on steroids.

To do this, you need to work your way across the organization, department by department, work group by work group, to find out from the users themselves what core, business-critical activities they currently use shared drives, hard drives and email for. And you’ll need to have not only good representation from end users, but from your SharePoint team as well, because this needs to be a collaborative process to work, more like a series of joint application development (JAD) sessions than requirements gathering interviews.

And in the spirit of a JAD, don’t turn it into a down-in-the-weeds, six sigma exercise: capturing the high-level steps in each process will do.

For example, if you’re working with the sales organization, you might come up with a list of document-centric activities similar to the following:

  • Contracting
  • RFP response process
  • Forecasting

With that done, you would step through each process at a high level. For example, under contracting:

  • Populate contract template with deal specifics
  • Route to sales team for approval
  • Send approved version to legal for review
  • Finalize contract draft
  • Send to client for review
  • Revision cycles with client, sales and legal
  • Deliver final version to client to sign
  • Route to sales for signature
  • File hard copy in file room, keep scanned copy on department drive

Along the way, you also want to find out the basics about any other systems used during the process, which documents are electronic and which paper, and any relevant upstream and downstream participants.

Once you have this done for all the business activities for the group, you can move on to the next step: process triage.

Step #2: Process Triage

Despite the fact that your goal is to move folks off of shared drives, hard drives and email onto SharePoint, you want to avoid turning everything into a nail simply because you happen to have a hammer. SharePoint has some sweet spots, and the goal is to find those processes that fit that sweet spot and get them into SharePoint as effectively as possible.

But not all of the document-centric business activities you uncover will fit SharePoint’s sweet spot. Some may be better suited to your enterprise content management platform, to existing line of business systems, or to best of breed niche solutions -- or remaining right where they are.

So once you have a good feel for what a group’s document-centric activities look like, you need to perform some triage to determine which processes would be in scope for a move to SharePoint and which would be out of scope.

You do this through discussion and a healthy debate among the participants, discussing what currently works and what doesn’t, what SharePoint is good at and what it struggles with, and what other technology options might be available.

For example, to continue the contracting example above, the sales team might share their difficulties with keeping versions straight, tracking down reviewers, and having lots of clauses and sections in the contracts that seem unnecessary. Your SharePoint resources might discuss some of the ways that SharePoint could alleviate the challenges the sales team faces and everyone might weigh in on the pros and cons of using a built for purpose contract management system.

Based on these discussions, the team decides what to do for each process: move to SharePoint, move to some other system, keep it where it is. The output of this triage activity provides the input for the next step: process redesign.

The Final Word

We’ll continue walking through the process in the next post, but in the meantime, I’d love to hear from you all out there: have you tried something like this at your organization? How did it go? Any key lessons learned? Or if not, maybe you have thoughts about my approach based on your personal experience designing and building systems -- keep me honest and let us all know what you think. Whatever the case, I’d love for you to jump in and get the conversation started!

Editor's Note: You may also be interested in reading: