SAVE THE DATE! KMWORLD 2019 in Washington DC NOVEMBER 5 - 7, 2019

 

SharePoint The Reality Series
Laying the foundation for your next SharePoint deployment

This article appears in the issue April 2010 [Volume 19, Issue 4]
Page 1 of 2 next >>


   Bookmark and Share

In our first in a series of SharePoint reality checks, we focus on the growing usage pains of a global SharePoint implementation. Those lessons apply to enterprise content management (ECM) systems as internal publishing platforms and as nest beds for collaboration through social networks, business process improvements and the repurposing of past success to optimize future efforts.

What happens when you take a packaged application that answers to most document-based processes in your enterprise ... only most of those tasks are still managed on e-mail and file drives? That long overdue and difficult conversation is made timely and necessary in the deployment of Microsoft SharePoint.

SharePoint is a game-changer for enterprise content management. According to IDC, SharePoint is the primary work environment for 22 percent of all knowledge workers. Also true—many of us knowledge managers are alternately excited and anxious about our next ECM deployments—most of them centered squarely on that platform.

SharePoint forces difficult conversations—ones delayed for years by consolidations, cost cutting and a single-minded focus on business performance. Each adopter gets out-of-the-box ECM and two bonus features that fall outside the functional sets of any software package:

  • a blank slate—For the first time ever, the ECM roadmap is dotted with a common set of pathways and building blocks.
  • a Rorschach test—The reach of SharePoint exposes every loose wire and unexplored corner of your information infrastructure.

Getting religion

Chris Rivinus, director of knowledge systems for Parsons Brinckerhoff, recalls, “When we started [we thought] this is just another software package. How great is this? We have a need for a global intranet, how cool—off the shelf. We’re going to make our lives easier.”

Others have a personal conversion somewhere offsite or at a conference. They return to headquarters ready to change. SharePoint’s what they’re going to use. That’s it. But if it were as simple as flipping a switch, everyone in the organization would forsake e-mail and go live on SharePoint.

There are just as many stumbling blocks as there are building blocks. “There is no halfway,” says Rivinus. “If you want a small percentage of what it offers, you still need many conversations.”

To Marc Anderson of Sympraxis Consulting, the first misstep is refusing to walk the walk. “The guy who gets religion needs to start practicing it,” he says. Deploying SharePoint successfully means rolling out metrics and measuring your people against them, so that every arrow and line points from pre- to post-implementation. “I’m behaving differently because I see the benefit,” Anderson says.

Here are some deployment principles and indicators for how your effort is faring.

GovernanceAccording to Bill English, president of Mindsharp, it’s not the promise but the premise of SharePoint that trips many implementers up at the start: Why are you putting it in? What are you using it for? What are the core roles and responsibilities? Those weighty questions soon clash with the perennial showstoppers that KMWorld readers know by heart: Who can see what? What goes where?

As straightforward as those questions are, the answers in your governance plan can vary as widely as the capabilities offered. That’s why it’s essential to reach outside the project team. The most unwavering sponsorship won’t buy as much credibility as engaging time and interest in the groups that gain the most from an enterprise platform. The wider the enlistment the team makes, the more persuasive the business requirements are for implementing SharePoint. In terms of internal marketing, one genuine endorsement is worth a thousand e-mail blasts.

MisconfigurationOne of the most common conclusions reached among deployment experts is the distinction that SharePoint is a product to be architected—not a series of Web pages to be a programming environment. “The first step is configuration—not development,” says Dave Sterling, CEO of Sterling International Consulting Group. It’s not custom programming but the information architecture that needs to happen upfront.

Sterling likens SharePoint to the interconnectedness of an enterprise resource planning (ERP) system where what happens in one corner impacts the whole neighborhood. That means approaching it like a platform, not a prototype that can be tested and rewritten: “Once it’s deployed, everything’s live,” he says.

Architects by nature have to see the bigger picture. The problem with putting IT administrators in charge is that they miss the real workflow between organizations. They look at SharePoint and see a top-down hierarchy. “If your project manager is more concerned about full disks than empty sites, you’ve got the wrong guy in charge,” Anderson maintains.

Taking the inventory

According to Rivinus, SharePoint is not only an easy way to generate and store content, but also “a fantastic therapeutic service for your company.” It forces adopters to take stock of what’s been done or, more precisely, what was started but didn’t have the backing to catch on.

According to Rivinus, SharePoint compels companies to have a conversation about the processes, content ownership and division responsibilities required to move forward with the product. SharePoint reflects where the organization wants to go and what’s holding it back. It’s not only a software application, but also the gap analysis between what the technology can do and where the organization has been.

Page 1 of 2 next >>

Search KMWorld

Connect