Lessons Learned From Making SharePoint Recommendations

I was recently asked what lessons I've learned when recommending SharePoint for for meeting a business need. While books are written on this topic, I've distilled the list down to what I think are the core of the decision-making process.

Know what your stakeholders require in objective, actionable terms

This is known as extracting core business drivers. Note that I didn't say requirements. Requirements are what you hand to your developers - core business drivers are what you use to make your recommendation.

Right questions to ask at this time:
- How does process x drive revenue?
- How much productivity loss constitutes a bottleneck in x process?
- How much must efficiency increase for x process to meet your defined goals?

Wrong questions to ask at this time:
- What problems do you have with your current system?
- What do you want your new system to look like?
- How do you want the system to function?

Note that the difference between the right and wrong questions is objectivity vs. subjectivity. If you can't get a quantifyable answer, the question should never be asked. And in reality, you should be answering those wrong questions yourself once you have digested the business drivers.
Map the core business drivers up to things that SharePoint does well

Another way to say this is, “Don't try to make SharePoint do something it's not designed to do.” This concept is simple, but it's very hard to establish effectively because SharePoint does so many blasted different things.

It's at this point where you'd decide whether using WSS or a full-blown MOSS implementation will fit the bill.

Be careful not to get into technical debt when mapping things up. If you've never used Form Services before, you'd better be darn sure it's the right fit for the job.

Every SharePoint feature you decide to implement should correlate to a core business driver. If you stick to this principle, you will avoid a lot of tehnical debt.

Just because SharePoint can do something doesn’t mean that you have to use it. Not every solution has a problem, so don't expect to use the entire of the SharePoint canon of functionality.
Decide whether the benefits outweigh the costs

Even if all of your quantified core business drivers are covered by your recommendation, there are a lot of unquantifiable things that will crop up. I'm talking about things like the personalities/predispositions of the stakeholders toward SharePoint, to the adoption propensity of the user base.

Rules are FAR more important than tools. Be smart on where governance is required to keep your SharePoint instance humming (even more books have been written on this matter, so I’m not going to get into it now), and build it into your proposal.

Posted on Tuesday, April 21, 2009 10:24 PM SharePoint , Systems Architecture and Design | Back to top

Comments on this post: Lessons Learned From Making SharePoint Recommendations

# re: Lessons Learned From Making SharePoint Recommendations

I absolutely agree with your summary of your first principle, but I vehemently disagree with your list of forbidden questions. It's rare that a business owner will have been able to refine his drivers into a concrete form well enough to answer the first three questions when you first sit down with him.

More likely, he's going to have good answers to the first two "wrong" questions. Any project needs to begin by casting a vision - why are we here? what problem are we really trying to solve? The role of the consultant/PM/tech lead in these situations is to guide the customer through the process of turning a gut-feel that something is wrong (e.g., the darn thing is too hard to use), into quantifiable statements that justify fixing the problem (e.g., 15% of users can't complete process X without calling the helpdesk, which costs us umpteen dollars).

I do not ask the question "What do you want your new system to look like?", but I always ask one very much like it: "When this system is implemented, how do imagine things being different?"

Similarly, I wouldn't ask a business owner how they want a system to function at this point, but I would find out if there are any constraints, either real or political (e.g., "We can't use any 3rd party products from FooCorp, because another group in the company failed with them.")

The key thing to remember is that projects need to be justified in quantifiable terms, but the actual decision making process typically involves varying degrees of non-quantifiable emotional inputs. You kind of hit on that in point #3, but I think its a point that bears expansion.

Left by Rob Huffstedtler on Apr 22, 2009 12:50 PM