This post begins the first of a six part series that provides important considerations for embarking on your SharePoint implementation. I’m not claiming there are ONLY 6 considerations, or that these are definitively the 6 most important, but I am claiming they’re important enough to be pretty darn close to the top.
Consideration 1: What are your success criteria?
I’ve been involved in quite a few long running SharePoint implementations, some from the ground up, some in rescue stage, some in ongoing maintenance state. It never ceases to amaze me when I start a SharePoint implementation and ask: “Why are you implementing SharePoint?” and get some variation of the following:
- Blank stares
- My competitor is using SharePoint
- I read a lot about it and thought we could use it
- I’m not sure
- Or my favorite: “So we can collaborate better.”
The above (especially 2- 4)are great justifications for a pilot implementation or a skunk works implementation but by the time the organization is committed to a serious investment in SharePoint, you must know your success criteria or you will stumble on success only by accident, and then only rarely.
Let me dive into my favorite point – “So we can collaborate better” – to comment a bit more on success criteria. What’s wrong with that criteria, you might ask? SharePoint is built for collaboration, or so I’ve read, and people at my company complain about collaboration. Correct on the first point, and probably correct on the second point since I’ve yet to meet a company that didn’t want to collaborate better. But what does it mean: collaborate better? How will you know when you have achieved it? This is the tough question that, when answered, will provide you with the true success criteria.
This brings me to a key point. Success criteria must not only be clearly defined, they must be measurable. “Collaborate better” is not measurable –it’s subjective and anyone can interpret the end state to either meet or refute the success criteria. As much as is reasonably possible, success criteria should be clearly measurable. Having shared an example of bad success criteria, here are some examples of better ones:
- All client documents will be accessible through search in 5 seconds or less, starting from the intranet home page.
- Each of our 10 business units will have a department home page which shows their top 5 key performance indicators, each to be updated with current date no less frequently than every day.
- Customers will have access to the full set of their documents in their customer portal.
It is not hard to determine if we were successful in our implementation with criteria like that.
Why don’t more organizations define these? Because it is hard. It is easy for each person to read “Collaborate better” and imagine their own desired end state. Thus, tough questions don’t have to be asked up front and consensus does not have to be achieved. But as you get granular with your success criteria, this is no longer possible. Success criteria then, are important not just because they allow you to easily guide the project to successful implementation, but also because they drive consensus on what you are trying to achieve right from the very beginning of the project.