For those of you keeping score at home, I’m in the middle of a series on how to build and deploy successful SharePoint document management applications, with the goal of migrating end-users off of the most prevalent legacy document management system out there: that unholy trinity of shared drives, hard drives and email.

Last post, I began walking through a process that, while by no means a silver bullet, in my experience will give you a better chance of success than the typical approaches, e.g. if you build it, they will come.

  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

We covered the first two steps there, and that’s the place to start if you haven’t already done so. In this post, we’ll dive deeper into the next two: process redesign and capabilities mapping.

Step #3: Process Redesign

After completing the first two steps, you wind up with a list of ranked document-centric processes for the business unit you’re working with. For example, if you’re working with the sales organization, you might have landed on the following list of processes:

  • Contracting
  • RFP response process
  • Forecasting

You would have also stepped through each of these processes at a high level to better understand them and the documents involved. For example, the contracting process:

  • 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

What you turn to do now is build the target future state, the to-be process that you’ll enable in SharePoint. This will be an iterative process, one that begins with the team talking through both the problems of the current state as well as what’s possible and desirable in the future state.

Remember, in the room you’ve got all the relevant business, compliance and IT stakeholders, so those of you used to more waterfall approaches to system development will have to adjust to the blending of business requirements gathering, system requirements gathering and solution design that characterizes these JAD-type working sessions.

The basic idea is to collectively sketch out how the current process could be modified to improve it (take less time, require less people, have higher quality, have lower risk, etc), with particular attention to how SharePoint can support those improvements.

Unlike some of the other steps, there’s no real trick or repeatable formula for process redesign. It requires judgment and cooperation, and the results in large part are dependent on the specific context of each case.

That having been said, here’s what our hypothetical contracting process might look like after a redesign effort:
Shepley - SharePoint Implementation - Back to Basics for Success (Part 2) - FIGURES.jpg

As you can see, SharePoint can only optimize so much here: steps relating to internal document management get a real boost from workflow, versioning and link sharing; external document management remains largely the same, mostly because exposing SharePoint externally goes beyond the bounds of the typical shared drive replacement project at most organizations.

Step #4: Capabilities Mapping

Once you’ve completed your process redesign for all the in-scope processes, you need to map the capabilities required for SharePoint to enable the to-be processes.

Depending on your organization and its culture, this can run the gamut from a highly formal, detailed requirements generation to a rough and ready laundry list of what SharePoint needs to do to enable the future state.

In my experience, more formal approaches tend to be overkill: you’re better off getting a general idea of the SharePoint capability areas you’ll require and leave it at that. You’ll get a chance to delve into the nitty-gritty details in the next step, so for now, just focus on getting a good idea of what you’ll be asking SharePoint to do at a high level and leave it at that.

You may be wondering what the purpose of this step is, since you’re going to be getting into the weeds in the next step. If you were only doing one process for one department, there would be no need for this step. But you’re likely going to be doing multiple processes across multiple departments. Having an overview of what SharePoint’s being asked to do across all in-scope processes and departments helps prepare your IT folks for what they need to deliver, and support and provides them the inputs they need to make decisions about SharePoint resource needs.

The Final Word

We’ll continue walking through the process with steps #5 and #6 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: