The Value of SharePoint – Introduction
Guest Author: Shaun O’Callaghan
The value of SharePoint is often best broken down and contextualized by organization, division and department. For instance, the value to an organization may be broad and sweeping e.g. improve collaboration. Trying to sell that value to a small Sales division may be less tangible and even less so to a team where collaboration isn’t important at all. A failure to realize this increases the risks of project slippage and raised barriers to end user adoption.
An obvious but often forgotten point is that end users, just like executive sponsors and stakeholders also buy value and don’t care for the most part that it’s SharePoint. From an information architecture perspective we need to understand how the product touches the different parts of the organization and how the value changes (and inevitably becomes much more granular) as the organizational unit becomes smaller.
It is often easy to lose sight of how the value changes to an organization when we are working on large, global deployments. My thoughts are borne out of the fact I’ve sat in a room with global directors of multinational pharmaceutical companies and I’ve also pulled up a chair at the desk of a finance assistant in a small department and sold the value of SharePoint. Both of these are equally important and we fail to realize this at our peril. If our SharePoint deployments are to be truly successful, and deliver the value that we say they will during presales consulting activities, then we must understand that the value of SharePoint isn’t broad and sweeping but tiered. When engaging with end users at different levels within the organization we must be able to demonstrate that we understand what the value is specifically to that particular division or group. When we do this, we stand a much greater chance of delivering an implementation which gains traction quickly and is aligned to customer expectations and needs.
Guest Author: Shaun O’Callaghan
Shaun O’Callaghan is a Senior SharePoint Consultant who works for Calvis Ltd., a UK/US based specialist IT and management consultancy delivering solutions in the commercial real estate, private equity and legal sectors. He has been working with SharePoint for 5 years and has been technical lead on a number of projects for major international organizations. Shaun enjoys leading a mix of customer engagements which involve architecting new SharePoint deployments for customers as well as in-depth development engagements with heavy customization.
- The Value of SharePoint - Introduction
Extremely important point clearly identified and explained.
Couldn’t have said it better myself.
I found the article and the points made very well communicated, knowledgeable, and you successfully articulated the business and marketing requirements necessary from a development and sales perspective. The objective of presenting a clear and marketable SharePoint product is definitely based on the understanding of the organization / business, and the individual requirements of each entity and / or the various business related areas. You absolutely have to know what’s going on in all areas of the business when conceptualizing and visualizing the foundation for a successful architecture, and for that to happen all business parties need to participate in the strategic planning process.
Very nicely put indeed! Another aspect of the IA challenge is the balance between what the technology can do and what the customer want. In many cases the technology is decided ahead by the customer (often for all the wrong reasons) in these cases it is often hard for all parties to not let the technology dictate the requirements (the infamous Golden Hammer). On the other hand, when the customer has a clean slate in terms of choice of technology during the specification phase, when SharePoint finally is chosen the challenge then is to translate requirements as much as possible to OOB SharePoint functionality and only resort to custom code as a last resort. Often i see the usability experts focus entirely on what works best, and now what the product offer, this will eventually end up with highly customized solutions where the customer have paid alot of money for *changing* the way SharePoint works rather than *extending* the platform. In essense it is about working *with* the product rather than working against it.