Blogger: Craig Roth
OK, in a previous posting I listed several points of countervailing wisdom for SharePoint. I just listed the teasers, and now is when you get to judge whether I'm really insane for saying things like "Trying to squeeze the most from your SharePoint investment is probably not good for the company" and "Driving adoption" is a band aid for poor demand management".
I posted the more full descriptions at the KnowledgeForward blog. Here they are:
Trying to squeeze the most from your SharePoint investment is probably not good for the company
What could possibly be wrong about trying to get the most return from your investment in SharePoint? What matters is the ROI of the company, not the ROI of a product. Just because SharePoint can do something doesn’t mean it’s the best tool the organization has to accomplish that task. As a parallel, the ROI on my $40 cordless screwdriver would increase if I used it for drilling all the drywall holes for my basement remodeling since it’s squeezing more benefit for the same investment. But that’s still silly if I have a corded electric drill nearby that’s much more efficient. When organizations get too excited about SharePoint, they risk cannibalizing value from other systems to the detriment of the overall collaboration portfolio.
Value is different than ROI
Conventional wisdom has convinced many SharePoint implementers that no metric can prove its worth better than the return on investment (ROI). After all, it’s actual dollars made compared to dollars spent – how much more real can it get? However, ITIL’s approach reframes the value equation quite elegantly by avoiding common SharePoint ROI problems (like the difficulty of proving the numbers and the distortion that perception introduces). What ITIL reveals is that SharePoint service providers need to focus on the portfolio’s combination of utility (what it provides) and warranty (that it is available to provide it) to ensure that value is achieved.
Management is different than governance
Governance is very important. I’ve dedicated significant portion of the last 6 years instructing everyone from Microsoft to government institutions to large corporations on how to apply governance to SharePoint. But management represents a separate pillar that is just as important. Executed properly, governance will provide the organizational and procedural structure that management requires to succeed. While practitioners conventionally blend management guidance into governance docs and use the terms interchangeably, there is a clear line separating them and two distinct efforts are required.
Offering SharePoint as a business service is fundamentally different than offering it as a set of technological capabilities
SharePoint demos like an app and it is tempting to treat it like an app, but more organizations are finding it’s really infrastructure. Steve Ballmer at the SharePoint conference finally used the “P” word: platform. So SharePoint is collaboration and content infrastructure. But users use applications. A service delivery methodology bridges that gap by packaging technical services into business services.
Users of SharePoint shouldn’t know what SharePoint is
Why does a business user need to know what SharePoint is? Conventional wisdom pushes the importance of “lunch and learns”, training plans, and rollouts. These are all fine as long as they are not for SharePoint. Proper service delivery will yield business services carefully crafted for particular uses. Those services are what the users need to understand. If an end user is asked if their company uses SharePoint in my ideal service delivery organization, they would answer “I don’t know. Never heard of it. But we do have a great Lab Research Tracking tool …” (where the tracking tool is a customized SharePoint list and template). Even though end users should be able to help themselves with SharePoint, that can mean end users initiate their own instance of the Lab Research Tracking workspace, not that they create it from scratch. And the service delivery methodology can stretch to include local service delivery points so that business services can be provided without having to contact IT or wait in their queue.
“Driving adoption” is a band aid for poor demand management
Conventional wisdom touts the importance of driving adoption before, during, and after rollout of SharePoint. “If you don’t drive adoption, you’ll fail to achieve the full potential of SharePoint”. Nonsense. A study of ITIL’s demand management process forced me to rethink this wisdom and realize that it is all backwards. If you took the time upfront to understand what the business needs and deliver it, you wouldn’t have to convince, cajole, or lure them to use your system. And the education required would be less as well since it would be targeted to business services rather than general purpose usage. End user self help can work once you attract users with specific business templates, after which adoption comes naturally rather than require “driving”.
Internally, SharePoint always has competition; users always have a choice
ITIL demand management recommends evaluating competition as a best practice. While it is written to apply to other external service providers, reframing it as internal competition yields important insight. E-mail will remain a substitute good for much of what SharePoint does. Competing – but disconnected – SharePoint installations can occur. And SaaS options abound.
The process of applying a service methodology has value for the organization beyond just the end result
Conventional project plans have governance and management as “something that needs to be done”, when actually they are “something that needs to be learned”. The process of implementing ITIL has many side benefits including better communication with the business, higher value, and knowledge that can help with other domains.