In "Wise and Not-So-Wise Choices, Part 1" and "Wise and Not-So-Wise Choices, Part 2", I discussed some healthy perspectives on SharePoint that I've run into during discussions with clients over the last few weeks. Today, I'd like to wrap up my three-part look at the role of SharePoint in today's enterprises by turning to another set of experiences in which unfortunate and in the end costly decisions were made. I'll propose an approach that might help you avoid those costly choices. And I'd like to find out how you address issues of end user productivity, business culture, and politics when planning for SharePoint.
Costly Choice #1: Using MOSS When WSS Would Suffice
I've seen it over and over: Companies bite the bait that Microsoft throws out and commit to using Microsoft Office SharePoint Server (MOSS) too soon and too often. Many organizations are currently focusing their SharePoint implementations on the collaboration scenario to help information workers get their jobs done more effectively with streamlined file sharing, workflow automation, and Web 2.0 functionality. For many enterprises, the additional value that MOSS brings to this particular scenario is nowhere near the cost differential between Windows SharePoint Services (WSS)—which is free, so to speak—and MOSS. Even in large enterprises and geographically distributed environments, WSS can serve the collaboration needs of branch and remote offices, with MOSS providing search and other "meta" services (e.g., site directories) at headquarters. You're better off meeting as many business requirements as possible with WSS before committing to MOSS. Believe me, I'm not saying that MOSS doesn't have a role to play—it most certainly does—but its roles are more likely to be in search, portal, and other scenarios that complement collaboration.
Costly Choice #2: Underestimating (or Excluding) Costs of and ROI for End User Productivity
When end users can get their jobs done more efficiently, costs are reduced and revenues are often increased. That's why we (i.e., IT folks) have jobs in the first place—IT is a service that should ultimately provide an ROI at least as high as the company's own expected rate of return on any investment. SharePoint has the real possibility of increasing end user productivity in each of SharePoint's scenarios: collaboration, search, portal, business process automation, business intelligence (BI), and content management. Depending on your business, one or more of these scenarios might represent a major portion of your end users' daily work. For many organizations, collaboration and search fit that bill. So anything you can do to help them (e.g., reduce collaboration headaches, improve searches, automate processes) can make a difference in their daily work.
Unfortunately, most organizations don't take the time to accurately estimate the cost of employees' time. It's not terribly tough to do. Take the full "burden" of an employee (salary, benefits, training, taxes, cost of recruiting, etc.), which is usually more than double the employee's salary, and divide it by a reasonable number of work hours per year. (In the United States, 2,000 hours is often used.) At one client, we demonstrated that we were saving users 10 minutes per day with a specific project. That doesn't sound like much, does it? It's not. But it saved the organization millions of dollars when we calculated the impact for the several thousand users over which the savings would be realized. In fact, the ROI became so outrageously high that we had to hugely undersell the project just to make it believable.
In the past, it's been tough to position these "soft" savings against the "hard" costs of software licenses and implementation. However, I think organizations will finally start to look at both hard and soft costs as they try to figure out how to do more with less in this economy.
So, with this perspective on end user productivity, the cost of implementing a tool that users find cumbersome versus a tool that works almost effortlessly is significant. And SharePoint is, all in all, easy to use. I've been amazed at how quickly users figure it out, even without (gasp!) training. And the tight integration with Microsoft Office makes advanced use of SharePoint quite accessible, unlike every other one of SharePoint's competitors. It's a pretty safe bet that any newly hired information worker already knows how to use Microsoft Word, Excel, PowerPoint, and Outlook. If that's your "starting line" for increasing collaboration with SharePoint, any other tool that starts you further back becomes extremely expensive.
Costly Choice #3: Politics and Resistance to Change
SharePoint is a new kid on the block. Unfortunately, because SharePoint came along later, there are many people who have a lot invested, politically, in legacy tools. Their resistance to change can cost your organization huge amounts of money, particularly if you calculate total cost to include employee time and productivity. IBM Lotus Notes, EMC Documentum eRoom, Xerox DocuShar, and other legacy tools have their strengths, to be sure, but their primary strength was they did it first. But in most cases, they don't do it best any more. When you consider that SharePoint tries and succeeds in most cases to do it all, in one package, that's tightly integrated with the Office suite (which the vast majority of people already know how to use), using SharePoint is a no brainer in most (but not all) cases.
I have one client that's exploring the "Open Office is better because it's not Microsoft" avenue. The people in charge see only the hard savings in software cost. What they don't see is the outrageous cost of training and support. It's kind of sad to watch because I've seen it before and I know how it turns out, but companies usually have to learn on their own, just like kids. But if you can muster the political capital to help your organization avoid getting stuck in a mire of multiple, legacy tools, it will pay off.
Avoiding Costly Choices
How do you avoid these mistakes, particularly in a complex organization with lots of politics, cultural legacy, and under-informed constituents? It all boils down to investing some time in the requirements-gathering stage of a project. If you really understand your requirements, you can create metrics with which success can be measured. Those metrics will lead directly into the ROI discussion, calculation, and decision. Sounds simple, and it is simple from a process standpoint. It's not so simple when you have multiple people, perspectives, and political agendas taking part. So, if you're going to invest time in one place, invest it in defining the project and its requirements. If you can lay out the requirements and get your leadership to support you sticking to them, you should be able to get past barriers of politics, legacy, and ownership.
I'm curious to know how you approach issues such as requirements gathering, ROI calculation, and the politics surrounding a major service like SharePoint. When you have a moment to talk shop, shoot me your thoughts at [email protected].
Speaking of talking shop, there's still time to register for this week's free online event "SharePoint: From Chaos to Success". I'll be delivering a session on governance and another session on SharePoint security. My friend and SharePoint guru Michael Noel will be talking about best practices for building a SharePoint farm. Come for some in-depth, independent talk about SharePoint. After each session, we'll be answering participants' questions.
