I’m at the end 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.

To that end, in the first four posts I’ve been 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’ve covered steps one through six so far, and that’s the place to start if you haven’t already done so. In this post, we’ll wrap up by diving deeper into communication and planning and go live, which is where the rubber hits the road.

#7. Communication and training

Although I’ve seen organizations drop the ball and cut corners on every step in the process so far, in my experience, training and communication are given short shrift (or omitted all together) 95% of the time. And this isn’t purely a SharePoint thing, on most application development or software deployments, training and communication are the first to go when schedules or budgets (or both) get tight. Users will figure it out, just put up some links to free online training or Power Points and they’ll be up and running just fine.

As anyone who’s been through this kind of training and communication can tell you, it never works. But, you might be thinking, what’s the alternative? We don’t have unlimited time and resources, and we certainly aren’t going to short change some of the earlier steps to make sure we have training and communication in place -- so what are our options?

First, you need to get really tactical about training and communication: quick and dirty, with the idea that you will do as little as possible to still achieve a good result after go live.

Second, you need to leverage the work you did in earlier phases to determine, Goldilocks fashion, what just the right amount of training and communication is. Here’s how:

  • You begin from the business processes you determined you’ll be rolling out and assume that these are the only ones that absolutely, positively need to be trained and communicated with.
  • You then take the capabilities that you mapped in step four -- these are the SharePoint areas that you train and communicate about, no more, no less.
  • You then take the migration plan and make sure that end users understand what this will mean for them, what’s expected of them, etc.

Quick and dirty for sure, but it gets at the main training and communication needs: the processes that users will be expected to use SharePoint for, the SharePoint capabilities they’ll need to be familiar with to support these processes, and the key change management relating to migration they’ll need to participate in.

What you absolutely do not want to do, even if they gave you the time, money, and support to do so, is to create some kind of grand, general SharePoint training that attempts to teach users everything they could ever want to know about SharePoint, or that is so generic that they can’t easily connect the dots between what they’re learning about and what they need to do day 1.

#8. Go Live

Which brings us to go live: what could be more important? After all, this is where the magic happens and all your hard work in the previous phases comes to fruition. But it’s also where all your previous efforts lay the groundwork for (hopefully) a smooth transition to production.

Learning Opportunities

So in the end, other than the typical SDLC go live activities, there shouldn’t be anything you have to do over and above that for your SharePoint deployment, particularly if you already have a stable SharePoint environment and you’re simply adding applications on top of it.

The Final Word

Well there you have it: a detailed look into a process for building SharePoint applications that I’ve seen be very successful in the real world. Despite the detail we’ve gone into, there will of course be lots of specifics that you’ll need to determine on the ground, but hopefully if you’ve stuck with me over the last few months, you’ll have a solid blueprint that will help get you where you need to go with SharePoint.

Not sure what’s next for me post-wise, but in the meantime, jump in and let me know what you thought of the series, share your own real world experiences, or just plain old heckle -- let’s get the conversation started.

Title image courtesy of SVLuma (Shutterstock).

Editor's Note: Additional articles on SharePoint strategies include: