As a SharePoint evangelist, working with users to identify their requirements can sometimes feel like an uphill struggle. We have all heard of the wishful thinkers, the my app does this so SharePoint had better too, the lets tweak this bit by bolting on that from ‘XYZ Consultants Are Us Inc’, and the list goes on.

Having the gusto of tool additions, feature modifications, branding, and customization requirements thrust onto the evangelist can be overwhelming and without project management aiming for utter chaos; additionally, the need to please everyone in an organization of inter connecting teams can also be daunting.

Consider this statement I heard just the other day: “My company vision is to ensure that every department in my company meets their goals with SharePoint”.

That’s just like saying “I have an apple and now I want you to magically present it to you as an orange”.

The problem is, we all suspect, is that the statement is far too nebulous, and frankly, is a vision that needs a strategy; a timeline; governance. Work to get even close to that vision needs to be project managed, worked through and fully understood.

A research carried out last year showed that over 70% of company SharePoint installs for small organizations overspent their budget, simply because they concentrated too soon on trying to get all their requirements into the product – in fact, in the main the implementation plan appears to be ‘install sharepoint in a vacumn syndrome and then pay a developer to change it before they use it’. Concentrated on trying to fit SharePoint into their custom requirements instead of to see how their current processes maps into the default product. And of those a significant number stem from not using qualified SharePoint people to explain the features of SharePoint to the client. Most of the complaints I get are from clients whose user requirements was defined by a SharePoint developer whose key area of expertise is writing code, who is definitely not an analyst to identify what out-of-the-box features map to the user requirements, even from a basic perspective.

“Slow down, you’re moving too fast”…

Another basic stumbling block is that the client will state something like this: “We are a fast moving company and we do not have time to carry out any analysis. We want to modify SharePoint to fit this product right now”. Hence, the issue is that the lowly evangelist in those cases will fail to articulate the features available in the actual product that could meet the client needs. The client in this case appears to be happily oblivious to what SharePoint can do, and I wouldn’t expect the client to know the features. However, it is crucial that the lowly evangelist states clearly that those are properly recorded. Time must be taken to ensure detailed investigations are undertaken – as a matrix of user requirements can be listed. At least then the out-of-the-box features can be realised.

Out-Of-The-Box really means that the client requirements map directly onto features provided from a default provision of SharePoint. Out-Of-The-Box means governance defines the relevancy of features SharePoint has supporting the vision they have for their departmental productivity. That’s no fancy bells, no wonderful gizmos, no ‘wow look at the fancy bits’. Raw SharePoint meeting Raw user requirements. Functionality is the key. Once those are bedded in, the client understanding the benefits and limitations of the out-of-the-box, THEN the real work of identifying what needs to be done to meet and address issues. And of course, these issues would be mapped directly to a company road-map strategy that encompasses not just SharePoint, but interconnecting technologies. Governance is key since this is where global versus local user requirements surface. This is where governance can agree what should and should not be made available. This is vitally important since a user requirement can have an impact outside of SharePoint.

Take this scenario:

“Our department needs to be able to multi-download documents to a folder of our from SharePoint, and to multi-email documents to other parties”. Sounds like a wow factor coming on? Think again. What about the disk capacity locally to meet that requirement. What about bandwidth? What about email attachments now being wizzed around with even more gusto than before? Isn’t that not a great thing to do? What about the impact on our email infrastructure? What about security concerns when downloading loads of documents? You and I could easily think of more.

So how do we ensure SharePoint Out-Of-The-Box gets entrenched in an organization. There’s quite a bit that can be done:

• Demonstrate core collaborative features of SharePoint centering on user productivity.
• Let users loose on sandboxed versions of SharePoint – switch all the features on.
• Prepare to demo, showcase, and describe the more complex areas of SharePoint e.g. Workflows, Records Management, PerformancePoint and business intelligence
• Don’t get hooked on the social computing side, keep things simple by explaining raw concepts of sharing information (especially for new users to web bourne working).
• Get some governance in place to start looking at the differing features and understand what best fits the organization.

Whilst writing this article I’ve had so many calls from other SharePoint workers who have stories to tell concerning their attempts to elicit user requirements and their struggles in matching those to out-of-the-box features. Am going to gather these and post them up so that we can better understand and engage with clients to ensure that out-of-the-box SharePoint is given credence and priority where due.