Where do you begin with SharePoint?
Whether you’ve just unwrapped the Christmas packaging off your shiny new SharePoint 2010 deployment, you’ve downloaded a trial version, or maybe SharePoint has been in place for a couple years but not really utilized and you’re trying to build a business case for a much broader deployment. Where to begin? I’ll tell you one place not to begin – Human Resources. 
I’m not trying to beat up on HR, but it seems that every organization, when deploying SharePoint for the first time and thinking about building a business case, seems to focus in on some of the most common HR activities, such as automating expense reports, or maybe vacation requests. My money says that this is exactly where most of you started. And that’s fine when you’re learning the platform, doing a proof of concept, or experimenting with workflows. But don’t go that route and expect to wow anyone.
You might get some attention, get SharePoint approved. Inevitably, the vanilla version of SharePoint (the out of the box experience) is deployed, initial focus is spent on building your HR solutions, and life gets underway. Jump forward 3 months, and people have associated SharePoint with your non-business critical HR solutions. They lose interest. People will look at SharePoint as a bloated, wasted effort that automates HR stuff. And then management turns back to look at you, at the lost time, at the lost productivity.
HR is not the point here. My point is a focus on solutions that don’t mean much to the overall business….at least right now, in the early stages. Your strategy should be to focus on those areas that will drive value to the business first. Quickly routing expense reports, while wonderful to your accounting team, is not adding tremendous value to your business. Email will work fine for a few more weeks while you focus elsewhere. SharePoint deployments should (like everything else) follow the 80/20 rule: focus your efforts and deliver functionality to the 20% of your organization who will be doing 80% of the workload in SharePoint. Find those teams that **need** productivity solutions, and build to their requirements first.
A funny thing happens when you deliver to the needs of the smaller group of end users, that 20% of users who actually need SharePoint – they’ll become the platform’s strongest advocates, and do more for end user adoption for the other 80% than anything in your bag of tricks. But your management will need to see the numbers. Track the KPIs around their performance increases, measure it, report on it, and demonstrate ROI back to your executive team. From there, with that success in hand, you can think about building out broader solutions that will improve life for the other 80%. Like a vacation request form. Or an automated birthday reminder.
Ooh, I can feel the productivity bubbling up now….
Mike, I completely agree with your point. I was attempting to make a point by focusing on one aspect of a generic deployment, but you’re right — resources and receptiveness are huge factors of moving forward with any plan. But I think that also kind of goes to my larger point about having a plan, and building with purpose rather than going live with “vanilla SharePoint”. As i mentioned in a tweet discussion today, it’s the difference between “deploying SharePoint” and “solving a business problem with SharePoint.” There’s a difference.
There’s nothing wrong with having the scope of ‘get SharePoint up and running’ because it has inherent value, even without specific business solutions in mind in the near-term. You know it will add value, and some organizations just need to get up and running so that they can figure out what to do next. In my experience, however, the more successful deployments are those who go into it with a plan to solve specific business issues. And if they’ve done their planning correctly, they’ve taken into consideration the resource and cultural (receptiveness) issues.
Jim, rarely is SharePoint measured on par with many other enterprise systems — but it should be. Analytics are the key to understanding the value being achieved, and helping inform teams of where the next investments should be made.
Christian, I totally appreciate the “high value/high leverage” play and you know how I feel about measurement, but I think there are other factors that are overlooked or at least undersold in this analysis.
Availability of resources and receptiveness of users are critical success factors as well, and they are frequently inversely proportional to the degree of business-criticality of the solution. If we intend to deploy SharePoint to solve critical business problems in measurable ways, I think we need to add this dimension to our decision-making criteria. You could argue that it’s already baked into ROI, but I rarely see it explicitly mentioned/discussed in a planning process or risk analysis.
Frequently, when we do, what appears to be the the second- or third most urgently needed solution (e.g., HR self-service forms library) becomes a much more viable “win” because of a lack of ability of business stakeholders on the higher-leverage (automation of a new project initation process, for example, when utilization is 90% and everyone’s maxed out doing their “day job”).
I like your premise a lot, just wanted to add that oft-overlooked dimension…
“Track the KPIs around their performance increases, measure it, report on it, and demonstrate ROI back to your executive team.”
Such an important bit that I bet is overlooked whenever SP is dropped in to a company.
It’s there to improve productivity and/or solve a business problem. You need to do it does that. And that’s how you do it 🙂