The SharePoint Project

This week I attended the Australian SharePoint Conference at the Hilton Hotel in Sydney. I've decided this is the last year I will be an attendee. Next year, I plan on presenting.

I am currently managing my fourth "SharePoint project". This is somewhat of a misleading proposition. As a former application developer and business analyst, I have always tried to deliver based on business objectives. As a Project Manager, I need to understand why there is a "SharePoint Project."

What is a "SharePoint Project?" SharePoint is a platform. Thankfully, this is the main message out of the conference to those just beginning to dabble in the technology.  One session estimated, by a show of hands, that 40% of the room was on 2007, 40% on 2010 and the rest were "thinking about" going to SharePoint. This message is for that last 20%.

By the time I'm hired as the Project Manager, the platform has already been "installed." Infrastructure guys (and I love you) have found SharePoint on the Windows server and "turned it on". Now to tell someone how to use it!

Voila! The SharePoint project is born. Some sites get created; the webmaster thinks it would make a great intranet; the document/records lady notices you can tag stuff with metadata. The CIO throws a barely six-figure sum at the budget and asks the Infrastructure guys to do this in their spare time.

No wonder so many people hate SharePoint. It's treated like Infrastructure.

Paul Culmsee, in his Day2 keynote speech, noted that things like installing servers are simple. You plug it in and it works. It's basically the same every time. Sure you have to hook up dummaflobbers and whatsits, but servers are interchangeable for many purposes. And infrastructure guys are great at knowing all this.

Things like Exchange/ Outlook are little more complicated. You configure it based on requirements that are predictable. People want to get mail and send mail. The requirement and business objective is that the thing works. I don't have to ask anyone what "success" looks like.

SharePoint implementation, however, is complex or sometimes chaotic. The requirements are many. The Webmaster wants a good content management system; the Enterprise Architect wants good information architecture; the Records Manager needs a single source of truth. SharePoint has suddenly become the solution to everyone's problem.

But that's just it. It's a solution. You need a problem to solve. SharePoint can be configured and adapted to do just about anything, but you just don't know what that anything is yet. 

Mark Miller, the editor of EndUserSharePoint.com, is right in saying that business objectives should drive the use of the platform. If you're not careful, you could end up blow-drying your pizza, or microwaving your dog.

The platform needs to have a strategy, a reason to exist.  From the strategy, projects branded with the business purpose in mind can be launched. Each project - document management, intranet, business process workflow - should have its own business objectives and a determination made as to whether SharePoint is the right platform. 

Next year at the conference, I'd like to see less geeks and more business folks. Vendors should be inviting their contacts along to see how SharePoint can provide the platform for the solution.  I'd like to see Governance replaced by Strategy; Workflow Management replaced by Business Process Implementation; Site Branding replaced by Project Branding. Let's start using the term "SharePoint" in context as the middle-bit between Windows and the applications that run on it.

End Users can then be taught the Business Solution. And no one, other than the Infrastructure guys, should ever care that it's called SharePoint.

What would you like to learn about from a SharePoint conference?