Authorr: Ruven Gotz

SharePoint projects for large organizations can be a real political minefield. There are many competing interests, many competing projects and a lot of complex stuff going on that you just have no idea about.

When you come into an environment like that, as just one consultant or part of a small team, it can be really risky to stick your neck out to do the right thing. I am going to tell you about a project that I once worked on where things worked out well. I won’t guarantee that it will always go your way, and I guess I could have had my ideas shot down (or worse), but I feel good about my choice to speak up.

A Large Conglomerate – let’s call it ALC – wanted to migrate from its old, out of date portal to a brand new SharePoint portal. The migration had to be completed on a very aggressive schedule because the old portal had to be phased out by a certain date for a whole bunch of reasons. When I joined, many months had already been spent identifying content owners and inventorying the documents on the old portal. A new site had been designed including IA, wireframes, mock-ups, prototypes and the migration/implementation train was speeding down the tracks to a go-live in four and a half months. The go-live day was scheduled for the same day that the old portal was to be shut down.

Here’s a wrinkle: ALC had decided to use SharePoint as the front-end to the portal, but all documents would be stored and managed in a dedicated Enterprise Content Management (ECM) system from another vendor. ALC had purchased the ECM / SharePoint connector, but it would not be implemented in-time for the go-live date. The migration plan talked about migrating all documents from the old portal to the ECM and linking to them from SharePoint. What it didn’t address was all the content that existed on web pages within the old portal such as all the context for the documents. The plan called for, but did not leave enough time for, the design of a new taxonomy to assist with findability on the new portal and the new portal didn’t account for a collection of non-standard sites that had been created by many teams (some internal, some hosted externally).

Like I said, the train was going down the track, and the brakes weren’t working. The operative phrase was “it won’t be ideal on day one, but we’ll fix it up later”. Within the first couple of days after I joined, I started to get the big picture of what was going on and I had a very bad feeling. The consultant (from a “big-five” firm) who was leading the project was working very effectively and forcefully to deliver an on-time/on-budget solution within the constraints that he had to deal with. This was a highly visible project with a multi-million dollar budget and it looked to me like it was going to crash and burn. I had a couple of options: Put my head down and produce my deliverables, or look for a way to save this thing.

I used my Issue Mapping skills (see Paul Culmsee’s blog for details on this) to produce a map of options along with the arguments in favour or against each of the alternatives. I then converted those arguments into a slide presentation complete with semi-amusing images, like this one to represent the likely adoption failure that would result from the current approach. I presented my deck to the business owner who was then able to tell the story to the steering committee and project sponsor. The net result was that we were allowed to scale back to a manageable set of deliverables for the go-live date. We had greatly extended the deadline for decommissioning the old portal so that we would have time to work with the various content owners to design a functional and usable portal for them. We didn’t just move all their documents into a new place with the same old unworkable organization, but took a phased approach that allowed time and resources for the proper design, implementation and migration to the new portal.

Of course, this new solution had its costs as well: We did not meet the initial goals and timelines for the project. This had a political cost for the sponsors. We also required the old portal to continue operation for many months beyond the initial phase-out date. This had a licensing impact and caused problems for other, related projects. Finally, by extending the timeline, the implementation costs were higher but not greatly, as we were able to create a much more efficient team and project plan. These are all factors which had to be carefully weighed. Ultimately, the risk of the portal project failing outweighed the other factors.

So, do I recommend that you “blow-up” a major project (starting less than a week after you join)? Not always and maybe not even most times. I was taking a major risk, calling foul on a project plan created by one of the biggest consulting firms in the world and that was heading for a finish line that had been very firmly set. But, if the project is going to be a train-wreck and you can offer alternatives that will avert disaster, and (very important!) you can capture and organize the issues, create a well articulated  message and present it well, then: Yes You Can – do the right thing for your client.

Authorr: Ruven Gotz

Ruven Gotz is a senior SharePoint consultant at Ideaca in Toronto. Working as a Business Analyst and Information Architect, Ruven applies his eclectic education and varied experience in Psychology, Computer Science, Economics and Training to get to the heart of complex problems. Ruven is a great communicator who is able to discuss and explain technology concepts in language that is appropriate and relevant to his audience, whether they are from I.T. or business. Ruven’s blog is at http://spinsiders.com/ruveng and you can follow him at http://twitter.com/ruveng.