Organizations in the oil and gas industry are always looking for ways to reduce costs, improve decision-making, increase operational efficiency, and help ensure regulatory compliance. From the upstream perspective, consider the vast volumes of documentation generated in the typical exploration or production project. Or the supporting documentation behind your division orders and land records.  Downstream, there’s the complexity of the contracts that must be created, reviewed, and managed, plus technical publications, plus facilities and asset management – not to mention the information produced and used by functions like customer service and communications management.

Enterprise content management (ECM) technology provides a way of addressing all of these challenges by helping an organization manage its information and make it available to the users who need it, when they need it.

How are your competitors in the industry making use of ECM capabilities – in both upstream and downstream applications? Where are the ECM opportunities in your own organization?

Join Joe Shepley, PhD, Vice President and Energy Practice Leader at Doculabs, for a lively and educational webinar, “Enterprise Content Management for the Oil and Gas Industry,” on Tuesday, May 15, 2012, from 1:00 to 2:00 CDT. The webinar will address the following topics:

•             Why oil and gas organizations should care about ECM

•             The ECM problem for oil and gas organizations

•             The vision for ECM at oil and gas organizations

•             How oil and gas organizations benefit from ECM

Register now!

Learn how effective management of information can improve decision-making and information-sharing across your organization’s global operations – and what you should be doing to put these capabilities in place.

I’m at the end of a series on how to build and deploy successful Microsoft 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. the “if-you-build-it, they-will-come” approach.

Following are the steps of this process toward the deployment of successful SharePoint document management applications:

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 1 through 6 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 I’ve outlined so far, in my experience, training and communication are given short shrift (or omitted altogether) 95 percent of the time. And we all know 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, we say to ourselves; 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 is just the right amount of training and communication for your users. 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 require training and communication (see Step 3).
• You then take the capabilities that you mapped in Step 4. 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 on 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.

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 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.

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.

In this post, we’ll dive deeper into migration planning, one of the most challenging parts of the process.

To that end, in the first three 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. the “if-you-build-it, they-will-come” approach. Once again, the eight steps of the process are:

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 five in the first three posts, and that’s the place to start if you haven’t already done so. So on to Step 6.

#6. Migration Planning

If you’ve been reading the first few posts in this series and thinking to yourself, “Man, nobody does all that work when they deploy SharePoint,” you’d be right: Very few organizations do take the time to do SharePoint the right way. Heck, very few of them take the time to do big ECM the right way, and those are multi-million-dollar enterprise platforms that require system integrators to even get up and running…so SharePoint never stood a chance.

But compared to the efforts put into migration planning, the typical SharePoint development looks like an IEEE best practices case study. Only one of two things happen when organizations start up SharePoint: users bring nothing over, or users bring everything over.

Needless to say, both of these are terrible outcomes for your SharePoint program.

To avoid them, you need to put in the time and effort to understand your users’ content from a number of different perspectives in order to determine what, if any, needs to be migrated to SharePoint and how:

• End user: What content is of highest value to them – i.e. used frequently, supports their main processes or operations, etc.?
• Compliance: What content poses the highest compliance risk – i.e. is required under penalty of law to be maintained, is critical to supporting compliance operations, mitigates the risk of being found non-compliant, etc.?
• IT: What content is the most burdensome to support – i.e. the largest files, infrequently accessed, extremely aged, etc.?
• Records Management: What content is past its retention requirements?
• Legal: What content is part of active (or impending) legal holds?

Once you’ve gotten an assessment of the content from these angles, you can begin to formulate a migration plan, the foundation of which is a protocol statement that sets the ground rules of how decisions about moving content will be made. For example:

Content will be migrated if it is…

• Required to be retained for active (or impending) legal holds
• Required to be retained to comply with the records retention schedule
• Required for regulatory compliance
• Critical for business operations

You can also express the ground rules negatively – i.e. when content will not be migrated:

Content will be not migrated if it is NOT…

• Subject to active (or impending) legal holds
• Required to be retained to comply with the records retention schedule
• Required for regulatory compliance
• Critical for business operations/has not been accessed in the last X time period (1 year, 2 years, 10 years, etc.)

Once the ground rules are in place and all the relevant stakeholders have agreed to play by them, you can sketch out what migration will look like for each group of users you bring onto SharePoint, which will be some combination of tried-and-true migration techniques:

• Bring over Tier 1, mission-critical content, and delete it from the shared drive
• Leave Tier 2 in place, read-only, and track levels of access to promote some to Tier 1 (and then migrate), demote some to Tier 3, and leave some at Tier 2
• Move Tier 3 to cheaper (e.g. off line, lower availability, etc.) storage
• Purge Tier 4

 The Final Word

As you might suspect, the reality will get much messier than my description of the process, and at times you will feel like one of the personal organizers on Hoarders, standing in a sea of junk, holding up a 10-year-old cocktail napkin, asking timidly if we can throw it out, and having the hoarder refuse to get rid of it, begin to have a panic attack, and ask you to leave.

But you have no other option — so stick with it. If you can get all the relevant stakeholders involved and facilitate properly, you’ll get past the initial roadblocks and arrive at a migration plan that, while not 100 percent for any one group, will be the best fit for the organization as a whole.

Next post we’ll wrap up with everybody’s favorite redheaded stepchildren: training and communication (along with some discussion of go live, thrown in for good measure).

In the meantime, as always, I’d love to hear your thoughts on the process I’ve sketched out so far, your experiences with SharePoint development, or your own thoughts on  how to get SharePoint right — jump in, and let’s get the conversation started.

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.

In this post, we’ll dive deeper into system design and testing, one of the most exciting parts of the process.

In the last two posts, I’ve been walking through a step-by-step 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. the “if-you-build-it, they-will-come” approach. The steps are as follows:

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 1 through 4 in the previous two posts, and that’s the place to start if you haven’t already done so.  Onward, then, this time to Step 5.

#5. System Design and Testing

The most important thing to take away about system design and testing for a shared drive migration to SharePoint is that the typical waterfall SDLC approach is less than optimal. A better approach, and one that I’ve used very successfully, is the rapid application development (RAD) approach. Here’s how it works.

Rather than serially executing the steps in the software development lifecycle, i.e. requirements-gathering, system design, system development, testing, and go live, you run requirements-gathering, system design and development, and testing concurrently in order to speed up the development cycle and reduce overhead (documentation, handoffs, project management).

There’s lots of great stuff out there about RAD (or RAD-like methods) for software development, so I won’t try to replicate that here. But I can give a quick overview of what the kind of RAD sessions I’m thinking of look like for SharePoint.

Basically, you’ll have SharePoint technical resources, end users, infrastructure stakeholders, business analysts (BAs), and quality/testing resources in the room. You’ll begin by articulating the business requirements for the solution – i.e. letting the end users talk about what business activities shared drives, email, and hard drives are currently supporting for them.

You want to make sure you don’t jump right into solutioning; getting too technical too soon can squelch the discussion of user needs/requirements. But at a certain point, you want the BAs, quality folks, and technical resources to start contributing ideas about how SharePoint can address the areas the end users have identified as important.

Once it becomes clear that you’ve gotten the lion’s share of the requirements and the discussion has shifted to system design, you’ll want to have the SharePoint technical folks plug a laptop into the projector and begin mocking up functionality directly in SharePoint, so that everyone can see the solution as it emerges.

Of course, you won’t be able to do all the system design in this forum. But consider this a prototyping exercise, using SharePoint itself rather than a whiteboard or wireframes. The goal is to get a rough mock-up of a SharePoint site that is moving in the right direction to meet your users’ needs. The goal is not to get a fully functioning SharePoint application up and running; that’s going to happen between sessions, as the technical folks go back to the lab and, using what they’ve learned in the session(s), build out a true SharePoint site.

Over the course of a number of sessions, here’s what the progression typically looks like:

• Session 1: Develop first pass at user requirements; begin sketching first prototype
• Session 2: Finalize user requirements; complete first prototype
• Session 3: Complete second prototype; finalize test plan
• Session 4, Session 5, etc.: Continue revving and refining prototypes

It’s important to note that you won’t always need this many sessions. I’ve facilitated RAD sessions where, by the end of the second session, we got to a good enough prototype that we were able to finalize and go live with only asynchronous collaboration on the emerging SharePoint application. I’ve also facilitated RAD efforts that required many, many sessions to reach that point.

How things shake out in any given case is going to depend on the complexity of the user requirements, your skill as facilitator, the personalities of the participants, the culture of the organization and dumb luck. Bottom line: be ready for anything and stay flexible.

The Final Word

Honestly, most SharePoint efforts move right from this step to go live; who needs migration planning, training, and communication? Copy everything over to SharePoint, or move nothing, or let users decide, and send them links to online training and call it a day, right?

Wrong. The road to SharePoint success is littered with failed efforts that went south in large part because folks didn’t pay enough attention to these two steps…so we won’t make that mistake here!

In the meantime, I’d love to hear your thoughts on the process I’ve sketched out so far, your experiences with SharePoint development, or your own thoughts on how to get SharePoint right. So jump in, and let’s get the conversation started.

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. the if-you-build-it, they-will-come approach. This process has eight steps:

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 in the previous post, 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 involves the following activities:

• 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, you’ve got in the room with you 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 fewer 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:

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. If so, 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!

What I want to do in the next few posts is walk through a process for rolling out SharePoint applications 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 in order 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 approach. More often than not, folks roll out a vanilla, one-size-fits all SharePoint environment and hope that if they build it, their users 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 they wind up using SharePoint in the same, less-than-optimal ways they used their old repositories.

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

With this 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. 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.

FYI, 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 available to them 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 makes use of 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 process mapping, 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 are currently using 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 if it’s to work, this process needs to be collaborative – 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 then step through each process at a high level. For example, under “Contracting,” you might document the following steps:

1. Populate contract template with deal specifics
2. Route to Sales team for approval
3. Send approved version to Legal for review
4. Finalize contract draft
5. Send to client for review
6. Revision cycles with client, Sales, and Legal
7. Deliver final version to client to sign
8. Route to Sales for signature
9. 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 are paper, and any relevant upstream and downstream participants in the process.

Once you have done this 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, and 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 within your own organization that fit those sweet spots, and then 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 — and some may even be better suited to 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 tell you about its difficulties keeping document 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 lessons learned you’d care to share? Or, if not, maybe you have thoughts about the approach outlined here, based on your own experiences designing and building systems. Keep me honest, and let us all know what you think. Whatever the case, I’d love it if you’d jump in and get the conversation started.

If your firm is undertaking an initiative to address alerts and notifications, we recommend that you organize and manage such an initiative with a program framework. Here’s what such a framework of common components and capabilities for alerts and notifications should look like.

The Framework for Alerts and Notifications

The alerts and notifications framework has eight elements: Event Management, Profiles and Preferences, Rules Management, Process and Policy Management, Delivery Management, Message/Template Management, Archive, and Compliance Administration. In more detail, it looks like this:

1. Event Management: System- or human-initiated activities that generate the need for an alert or notification.  In terms of technology, event management means services that capture events which generate or drive the need or production of an alert or notification. Key components include the Integration Layer, Service Bus, Delivery Confirmation, and Administration and Reporting.
2. Profiles and Preferences: Systems, databases, and processes used to capture and maintain demographic and preference information. Key components include Identity Management, Preference Configuration, Rules Administration, and Reporting.
3. Rules Management: Business and technical rules that operate on the messages, triggers, delivery mechanisms, and profile/preference data. Key components include Staging, Integrated Communications Director, Inbound/Outbound Controls, and Lifecycle Administration.
4. Process and Policy Management: Information and privacy protection policies and how they are to be used and implemented. Key components include Review and Approve Workflow, Policy Versioning and Archive, User/Roles Configuration, and Process Monitoring and Reporting.
5. Delivery Management: Physical resources and technology used to distribute Alerts and Notifications across the relevant channels. Key components include Channel Support, Inbound and Outbound Services, Delivery Confirmation, and Security and Encryption. 
6. Message and Template Management: Portfolio of templates, content, and standards and style guides for creating alerts and notifications. Key components address Classification and Version Management, Authoring and Design, Output Generation, and Archiving. 
7. Archive: Repository of record for templates, resources, alerts and notifications, and other relevant content. Key components include Ingestion, Retrieval and Viewing, Disposition, and Compliance Reporting.
8. Compliance Administration: Programmatic elements ensuring that Alerts and Notifications are compliant with relevant regulations. The elements for Compliance Administration address governance, policies, and technology. With respect to technology, the pre- and post-production services to ensure compliance in every aspect relevant to alerts and notifications include Data Aggregation, Analytics, Audit, Reporting, and Dashboarding.

Where Should You Start with Alerts and Notifications?

In our experience, it’s best to narrow your attention to focus your resources on just a few opportunities first. These opportunities should be simpler, less risky, and provide good bang-for-the-buck. Look for messages with the following characteristics:

• Message type: System-generated messages are easier to address than human-generated correspondence.
• Trigger events: Servicing events are easier to address than marketing initiatives.
• Recipients: Focus first on existing customers (e.g. policyholders and claimants in insurance; advisors, agents) rather than prospects.
• Channels: Focus on email and text messaging before trying to tackle chat, RSS, mobile, and other social media tools.

In my last post, “Sharepoint at the Crossroads,” I outlined the decision point that the SharePoint user community faces right now. After the post, I caught some flak 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) a mess as they had before, 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. Having said that, with this post I want to provide a bird’s eye view of how you can use SharePoint successfully to move off your current ailing repository of choice and provide improved document management capabilities to your organization. Next post, we’ll drop down into the weeds a bit and look in some detail at how you go about implementing the best practices I introduce here.

Restaurant Odds

Depending on what source you rely on, something like 60 percent 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-typically-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 actually 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 annual growth rates of 50 percent and sometimes even higher), so doing nothing is no longer an option for most organizations – or, at any rate, it won’t be for much longer.
• Second, the move to SharePoint (or to 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 – the ones 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 times out of ten, 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 then 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, to put it 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 are currently being supported by “as-is” technology like shared drives, hard drives and email.

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 content management system) 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 among Doculabs’ consulting clients, 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!

A version of this post originally appeared in Insurance & Technology’s Virtual Roundtable: How to Improve the Customer Experience With Customized Document Creation and Delivery.

Technology, social media, and the ever-increasing power of the 18-to-34-year-old demographic have changed the way insurance companies must think about delivering an exceptional customer experience. A 2010 study found 33 percent of insurance buyers were willing to buy and manage insurance online – but among 18-to-34-year-olds, it was 43 percent.

Many insurance companies, having invested in the core CRM and BPM technologies, are now positioned to integrate with advances in customer communications management (CCM) or document composition tools. Expect the technologies and tools for delivering the experience to continue to undergo rapid changes. CCM tools will continue to evolve into full-scale multi-channel communication platforms – essential to delivering consistency in service and experience regardless of channel. Still, technology is the enabler, not the focus.

A key trend is the cloud. CCM vendors now provide services as SAAS offerings, which reduces upfront investment in the technologies and time to market. But it’s the integration with customer data and process automation that, when combined, drives delivery of a consistent, easy, and enjoyable experience throughout the insurance acquisition and servicing lifecycle.

A top-down vision is extremely valuable in galvanizing the cross-functional team required to develop a multi-faceted approach. This means aligning Marketing, Product Development, Customer Service, Claims, and Legal and Compliance to help shape the program.

Finally, multi-channel delivery also requires some heavy lifting upfront: redesigning communications and optimizing the underlying templates to align with branding, experience, and multi-channel delivery. We all know you can’t have dessert until you eat your peas – and you can’t truly leverage the technology unless you first clean up the mess.

In the meantime, Legal and Compliance are wary of deleting materials for fear of spoliation (i.e. wrongful deletion of materials).

But additional storage is inexpensive, which makes it easy for corporations to just invest in more storage and defer addressing the problem. Still, as this over-retention continues, and the volumes of electronic content creep into the terabytes, many organizations are starting to have concerns over the unintended dissemination of Personal Identifiable Information (PII).

There’s no silver bullet or single solution for addressing the terabytes of incoming and historical information. It requires a divide-and-conquer approach. But capture is definitely part of the solution – particularly when it’s deployed in combination with auto-classification technology.

Auto-classification is the automatic sorting of documents into appropriate categories. It might also include creating new categories and extracting or creating metadata (indexes).

There are different usage scenarios for auto-classification, and they are very different (just like full-text OCR on journal articles for research purposes is very different than OCR on forms for an insurance claim.) Our focus here is on classification for ILM and RM.

What auto-classification does is to get documents into a managed system, automatically classifying them according to what kind what kind of record they are. It directly addresses the problem cited above: the problem of how to determine which content to keep and which to purge, when (to date) you’ve been keeping all of your electronic content. Effective classification of content helps an organization make precisely these determinations.

But manual classification is unrealistic for real humans: It’s far too slow, and far too costly. As the volumes of electronic content continue to proliferate, particularly in large organizations with global operations with really high volumes of stored electronic content, what seems to work best is a mix of automatic and manual classification.

But when should you use auto-classification? Look first at applications where:

• The process and documents are already under the control of an ECM (or other) system
• There are a limited, well-defined number of document types
• There are big differences between types and small differences between the documents within each type (e.g. invoices versus contracts, because invoices and contracts look very different, but all invoices and all contracts look similar – to smart recognition engines, that is)
• The documents are of high quality (they don’t look like they’ve been dragged through a barnyard)

Capture is the technology for digitizing many of the documents your organization uses in its business processes, allowing you to get them into an electronic repository. But as more and more organizations become concerned over what might be retained in those repositories burgeoning with terabytes of documents, many of them long past their retention date, auto-classification begins to look like an attractive add-on – an easy way to determine which of those aging document images can be defensibly disposed of.