Don’t Blame SharePoint

By accident or by design, I’ve managed to steer clear of MS SharePoint (SP) centric Enterprise Content Management (ECM) deployments until a few weeks ago. However, even though I’ve only been on the periphery of SP, I’ve never been of the opinion that all the SP implementations that have gone wrong were really the fault of the platform.

As almost everyone knows, whether they want to acknowledge it or not, SharePoint is an indomitable presence that’s not going anywhere. I know that many of us ECM purists (a.k.a.: snobs) kinda laughed the first time we saw MS SharePoint included in analyst coverage that also included Alfresco, Documentum, Filenet, Hyland, Laserfiche, OpenText, Stellent, etc. We laughed and we also cringed a little bit in fear because we knew that at some point we were going to have to deal with it. Between Microsoft’s might, the ubiquity of MS Windows and MS Office, a partner/vendor/SI ecosystem in the tens of thousands, user comfort, and ease of use (a nebulous concept, to be sure) no wringing of hands, gnashing of teeth, or blood sacrifice was going to save us. So here I am, facing my first SP2010 content management problem project.

The backstory goes like this …

1. Some time ago my client (an energy transmission provider) decided that storing all of their business critical content on network shares was not a sustainable thing to be doing (good start).
2. They took the decision to implement SP2007 to manage the aforementioned content (reasonable decision considering their core business and ECM maturity level).
3. On a content type/owner basis they copied (not moved) some content from the network drives into SP2007 (making progress, except …).
4. They did not …
   • Take a content inventory.
   • Develop a taxonomy or metadata model.
   • Account for other stakeholders that may need access to the content.
   • Provide context / role specific views to the users.
   • Put any rules around site provisioning and what to do with them when no longer needed.
   • Do ANY of the things needing to be done prior to implementing an ECM solution and migrating content, regardless of what the platform is. In short, they moved whatever was in those network folders right into SP2007, effectively creating two messes instead of one.
5. So … SP2007 started to collapse under its own weight (because they missed the parts about capacity planning, scaling, and disposing of content).
6. They decided to migrate to SP2010 (Yay! We can take this opportunity to make sure things are done the right way).
7. Aaaaand they didn’t.

My client hired an SI firm to do the SP2007 to SP2010 migration. They effectively said, “We want a like-to-like migration from 07 to 2010.” The SI said “Okay” and did it. Now, I don’t know about you, but when I hear “like-for-like” I typically think that we’re not adding functionality, but we are fixing mistakes. I also tend to think that we’d be taking advantage of new out-of-the-box features, available to make all our lives easier. A fairly reasonable thought process, no?

The SI interpreted “like-for-like” literally, and fired the entire mess from SP2007 into SP2010, effectively creating a third repository of unmanaged stuff. Enter Chris the consultant (that’s me, in case you’ve lost track by now).

So I spend a few days talking with a bunch of stakeholders to figure out what’s needed and what went wrong with the first two attempts. I also spent some time getting into people’s heads about their thoughts, fears, and attitudes around how they viewed information management as an enabler for them to do their jobs. Here’s what I found …

Scope – The scope was limited to a specific group’s SP site. You don’t need to bother anyone else, they said. Not so fast. Though the content in the site was “owned” by a single business unit, the content applies to a business process that involves all non-administrative units in the organization. No one spoke to these other folks in the first two iterations. They also neglected to hold any discussions regarding what happens upstream and downstream in the process (a 7-stage process in which the affected department is the primary participant in stages 4 & 5).

Fundamentals – By fundamentals I am referring to items such as file plans, retention & disposition schedules, archiving strategies, metadata model, user profiles (personas), security, … pretty much everything I mentioned in the numbered list above.

Content Migration – Content migration is not just simply forklifting content from one repository to another. There has to be some serious thought put into it. Decisions about what content goes, where does it go, what gets archived, day forward or legacy, all have to be asked and answered. In addition, the target repository needs to be configured so that people can find what’s been put into it.

Search – You know you’re in trouble when the search screen tells you to go to the Windows Explorer view to find what you’re looking for. Suffice it to say that absent any metadata and taxonomy, search was a fantasy.

Miscellaneous – (‘Cause I want this to end soon.) No infrastructure planning or architecture, no capacity planning, no business continuity planning, no backup/restore planning, no storage management, no integration, no enterprise search, etc. There is a long list of things that should have been, but weren’t done.

Any one of the above could have caused the SP implementation (any implementation, really) to be a spectacular failure. Combine them and you’ll end up with … I don’t know what you’ll end up with but it’s really, really bad. So, what happened?

One small mistake doomed the whole thing. No, it had nothing to do with technology selection. The mistake was even more critical; they picked the wrong partner. It’s really that simple.

Anyone can do SharePoint; very few can do it really well in a mission critical scenario. With all that’s possible with SP, you need a partner that really knows their stuff. Had my client selected the right partner they wouldn’t be in the hole they’re in now.

Regardless of what solutions you’re deploying, selecting the right partner is critical. In the case of my client, they needed an SI that has a deep understanding of ECM and how to do it correctly using SharePoint as the technology. My client chose wrong and the SI, to be blunt, misrepresented themselves. Had the client done some additional due diligence, they would have discovered the skills and services gaps that the SI has. They also would have discovered that the SI does in fact have an ECM practice that could have been involved, albeit they are located in a different city.

So how do we rescue this thing? We go back to square one and do the right things in the right order. The client needs to acknowledge that what they’ve paid the SI is pretty much wasted. I and the group I am working with fess up about our shortcomings and help the client fill the gaps. We involve the right stakeholders in the discussions. We stop the client from making quick decisions and get them to make correct decisions.

The point of my little story is that you need to do your homework before you choose a partner no matter what you need them for. The wrong partner can kill a project; the right partner will help you succeed. My colleagues at Digital Clarity Group have done some tremendous work to help organizations select partners; you should check it out, especially some of the more recent posts by Cathy McKnight and Jill Finger Gibson (she may or may not be involved with Gibson guitars).

I spent this past weekend writing up a final report, to be delivered this week; there are going to be some mighty unhappy people. On the bright side, all is not lost and we can still make this a success. I’m going to roll the dice and see what happens; either the client understands what needs to be done and we move forward, or my contract comes to an ignominious end in a few days.

June 25th update – meeting with the client ended a little over an hour ago. Decision to proceed to the next phase.