ROI of SharePoint – An Example

In a recent post, I talked about ROI of SharePoint and how there are many hidden “soft costs” within business activities — which are probably not measured in most organizations today.    A good use case for measuring ROI of SharePoint is a set of business activities around managing IT contractors.

Many IT organizations both large and small utilize contractors and consultants. In many global enterprises, you might have several thousand contractors in and out of your organization over a calendar year. The process of hiring contractors and consultants is often times a painful one. It takes weeks if not months, lots of back and forth emails, paper forms and approvals, resumes, interviews, rate discussions, on-boarding, and more… Project timelines are impacted and the demand for IT project requests starts to backlog because it takes too long to get the right IT resource into your organization and onboard. In the absence of an expensive “vendor management” system, the end to end process can seem like a chaotic dance of emails, paper, and documents.

Just as there is a cost in hiring a full time employee, there’s a cost of on-boarding a contractor. Additionally, if you’re not tracking vendors, candidates, or rates, how do you know you know you’re getting the best candidate for the lowest rate? Do you know the average bill rate of your contractors or for a particular vendor? Are you measuring the cycle time for an IT manager to initiate a resource request through the on-boarding? Do you know the dollar impact resource delays have on project schedules and costs? Do you know what metrics you should be measuring at all? These types of questions beg for a solution built on SharePoint to help you manage the information and documentation, communicate status, and report on key performance indicators (KPIs) you indentify to be important to your organization.

Before you even begin to start building your solution on SharePoint, you’ll want to begin by mapping the end to end business activities, approvals, and flow of information and documents. The next step involves developing an “information architecture” with the appropriate content types and metadata you are looking to capture. Part of this exercise involves understanding what KPIs you are looking to measure as that will drive some of your taxonomy. Where possible, you also want to attempt to estimate time and dollar costs of the existing process so you can compare those estimates after you implement the solution built on SharePoint. There are obvious hard costs like the hourly rate of a resource. Soft costs might be the time required for approvals, time waiting for hiring decisions, or interview feedback. There are also less obvious soft costs such as cost of turnover, lost productivity, low morale, lost sales, or missed opportunities.

So let’s look at an example to see how much lost productivity we might find in this example of IT contracting staffing requests:

1. Let’s assume you receive about 2000 IT staffing requests a year.
2. The average processing time for fulfilling IT staffing requests is on average 6 weeks (or 240 working hours).
3. The lost calendar hours waiting for staffing requests to process would equate to 480,000 lost hours per year waiting (2000 requests * 240 hours waiting per request).
4. Those 480,000 total calendar hours divided by 24 = 16,667 days total waiting.
5. Multiply 16,667 days waiting times 8 hours in a day = 133,336 Lost Productive Work Hours Waiting for IT Staffing Requests in this example.
6. The average hourly rate of your employees (those submitting and fulfilling the requests) is estimated at about $55/hour.
7. $55 * 133,336 lost productive hours = $7,333,480 as the Total Cost of Loss in Productivity

Once you understand the end of end process and estimate the current loss in productivity involved in the current set of business activities, you can then begin to set a target such as reducing the request fulfillment time by 50%.  Then you can begin to leverage the capabilities of SharePoint.  The assumption is you probably already have it inside your organization and all you need is your own Site Collection.  The costs are minimal and you can now provide IT managers a place to request resources via a centralized SharePoint web form and self-track the progress of their requests and candidates throughout the interview process.   You can empower the individuals who work with outside staffing agencies to manage the candidates and resumes, present them in SharePoint to the hiring manager and include the in-flow of information and documents all within SharePoint lists and libraries with appropriate metadata.   Managers can enter feedback and executives can approve billing rates.  Lastly, you can begin to report to executives and measure cycle times, average billing rates, and more — all from the data and information captured in the solution built on SharePoint.

Just imagine this SharePoint solution allows you to reduce the time it takes to fulfill IT Staffing requests by 20% or 50%?   In our example, that’s a cost savings of millions that are measurable and easily communicated to executives and business leaders to justify the cost of SharePoint and showcase the value and ROI of the technology platform.

Why is measuring a hard ROI for SharePoint just so hard?

Traditionally when it comes to implementing technology, the financial bean counters and decision makers have looked for hard dollars for the ROI of a technology investment. However, when it comes to SharePoint, it seems we have thrown a hard ROI out the window. In a manufacturing or factory environment, it’s generally easy to measure hard dollar costs of raw materials or labor costs or costs per hour. Centuries of economic theory and practice led to the pioneering of the “scientific method” in the early part of the 20th century by Frederick Taylor and Henry Ford among others. Implement “robot X” into the assembly line and produce more widgets and save on labor costs. We have also had a few decades of TQM (total quality management) which has evolved into many buzzwords all seeking efficiencies in productivity of manufacturing and supply chains. In Business School, I remember learning all kinds of management theory on these subjects and “generally accepted accounting principles” to calculate hard dollar costs and manage budgets to actual as well as profitability of goods sold. So what happened to measuring ROI of SharePoint and why isn’t there enough written on it?

I have read tons of articles on web 2.0, collaboration, and SharePoint. They evangelize about grand topics like innovation and creating opportunities through communities and connecting people through social sites. Some talk about the vision of enterprise content management being realized at an enterprise level. And some articles even try to address ROI and talk about the “downstream effects” of capturing ideas and information in blogs or wikis. Then we hear from executives and decision makers that evangelizing the technology sounds great, but all the benefits are “soft” and too hard to measure. Okay, so why not measure “soft costs”?

The reality is that all businesses have soft costs such as turnover, lost productivity, low morale, lost sales and missed opportunities. And any combination of those might drive soft cost dollars in your organization which can have big impact on your bottom line — sometimes just as much as the hard costs and other times even more. Many organizations simply don’t measure these types of costs because they don’t understand it or simply don’t have the capability to measure them. Or perhaps people are just focused on meeting deadlines without questioning the value or impact to the customer. Meanwhile, project management within many organizations seems like chaos, deadlines get missed, decisions are delayed, tiger teams get formed, and the insanity of our day to day work life continues. Projects that should take only a few weeks or a few months, takes 12 or 18 months to complete and quality suffers as does employee morale. You continue to wonder why things in your organization aren’t as easy as what we see on Google or Facebook. Then we recharge on the weekend, read the Dilbert cartoon in the Sunday paper, laugh and think of our own work environments, and do it all over again next week. All the while we continue to email each other on our smart phones and at best upload documents to a site on SharePoint. And if you’re paying attention, there are no doubt hidden costs in many of the things just mentioned.

In today’s economic climate, it’s time we take a hard look at dollars and sense and focus on driving analytics from a collaboration & information management platform like SharePoint. In my next series of blog entries, I’m going to focus on making measuring a hard ROI less hard and relate it specifically to real solutions implemented on SharePoint.

How to Staff Your SharePoint Project

Something that has been truly bothering me lately is recruiters or project managers or executives not knowing how to staff SharePoint Deployment projects or staff their Operations teams that support SharePoint.   Too often I receive calls from recruiters looking for SharePoint “Technical Resources”.  Rarely are they looking for people who know how to analyze business processes or manage enterprise information management platforms like SharePoint.    It seems recruiters want hands-on resources who write code and do everything else including administration and configuration.   Unfortunately looking for a jack of all technical trades is just not the best way to minimize risk when it comes to your enterprise application deployment.  I’ve seen too many implementations that have gone wrong or ended up simply re-creating the information mess that already existed in the organization.

So let me outline the resources required for ensuring success of your SharePoint implementation.   It is important to note that these resources do not simply go away once you have completed phase I of your global deployment.   Each one will be required for ongoing governance of operations and continued solutions development and support of business needs:

Program/Project Manager – an individual who not only knows how to manage IT projects, but also understand ECM, information architecture, software and solutions development, IT infrastructure, etc…   They don’t have to know how to write code or know SharePoint administration hands on.  They do need to have some “technical acumen” but they also need to evangelize the solutions to both end users and senior executives.  They need to know how manage and govern an application like SharePoint and have discussions about backups,restores, failover, disaster recovery, taxonomies, etc.  They also need to understand communications, collaboration, knowledge management, business process improvements, ECM, web 2.0 — all the capabilities that an organization might leverage with SharePoint.

Systems Analyst – Having the word “SharePoint” on this resource’s resume is just not required.  There are sooooo many GREAT system analyst resources that I have met who seem be stuck in their current role between IT and the Business.   Perhaps they’re in a Big 4 Consulting firm doing QA work on some legacy or ERP application or custom web development for some large Fortune 500 client, drafting business requirements documents, or working late nights with offshore development teams.  All of these individuals I’ve talked to seem disenchanted with their current role, see little career growth, are tired of their current technology focus, and are looking for the chance to work with an application that the sex-appeal of SharePoint.   It really doesn’t matter if these individuals know SharePoint or have seen it.   Let me repeat that: It really doesn’t matter if these individuals know SharePoint or have seen it. If they are experienced with any enterprise application, the skills are all transferable.   This role is so critical in SharePoint’s success because someone needs to work with the end users and business to understand their needs, map out the requirements and workflows, wireframe site designs, get hands with SharePoint Designer and do light customization and design of sites, and provide QA.  However, there is no reason why this resource needs to know how to write code.   They just need to interact with the business and developers ensure what is delivered to users has some level of quality and actually matches the requirements identified upfront in the project.   Lastly, a systems analyst is not someone who simply leaves once the initial deployment is completed.   This person will be needed for ongoing requests by the business to develop solutions on top of SharePoint.  So many companies have way too many internal processes that are paper based, inefficient, or handled over email….that a systems analyst resource will be busy for at least the next decade.

Solutions Architect and Jr Developers – Okay, so here are the resource who knows how to write code… .Net, visual studio, etc.   Maybe you offshore development and if you do, that’s fine.   However, you better have really really good system analysts and project managers to manage that development and provide the interface and QA to the business — especially if there are language barriers to manage.   Don’t expect these resources to know how to configure SharePoint, install it, or do any administration whatsoever.   However, it definitely helps if they do and can guide your organization in their deeper taxonomy planning, security, and high-level solution design.  Do expect they know the SharePoint object model, know how the performance impacts of developing point solutions on top of an enterprise infrastructure.

Information Architect – Expert in ECM and information architecture.  You’ll pay a premium for this resource, but it’s worth it.   Most deployments overlook the need for this person.  Maybe they have worked with other ECM applications like Filenet or Documentum.   Knowing SharePoint is useful, but not necessarily a must have.  If they have 10+ years experience with ECM applications, they can learn SharePoint’s model very quickly.   In fact, most Documentum or Filenet or Lotus consultants I know who have 15+ years experience all say the same thing — they’re doing exactly what they did 10-15 years ago — just at an enterprise scale and with SharePoint.

Systems Engineer / SharePoint Administrator – a Windows certified resource preferably.  Someone who knows how to install, configure, secure, troubleshoot IIS, OS, hardware, Virtual images, and network issues and in a global WAN or extended extranet environments.   When users can’t access SharePoint, you will not only need a really competent resource here — but you will be buying them drinks often!

Storage Engineer – your SAN or NAS experts who understand performance and storage considerations mostly around SQL databases unless you opt to store files outside of SQL.

DBA – SQL Server experts who should learn how SharePoint stores data and files, how to care and feed for it, limitations, and even options for storing files outside the database, etc…

So don’t understaff your SharePoint project.   The ROI is real and you’re making a mistake if you think you can offshore everything or pay a junior resource $40 or $50/hour onshore.    While some of these roles might be filled by a single person, you will likely pay more for someone who can wear many hats — and you should pay more for 1 person who addresses multiple needs (that normally would be addressed by multiple resources).   In this world, you get what you pay for….so don’t risk an information mess in your SharePoint deployment.   Get the right resource with the right skills for the right job….and yes, I’m available if you need help!  🙂

 

How to Determine the True Cost of Microsoft SharePoint

From CIO Magazine….  great article.     Please follow me on Twitter…

SharePoint has unquestionably garnered a lot of attention from business users and IT. Toby Bell, Gartner Inc.’s research vice president, calls SharePoint 2007 “nothing short of a phenomenon.” He says the growing number of searches for SharePoint on Gartner.com indicates high interest in the product and some confusion about its value.

“For Microsoft and its partner ecosystem, it’s easy to see SharePoint becoming the billion dollar baby in ECM [enterprise content management],” says Bell via e-mail. “[However,] estimating the potential ROI of SharePoint and related products for enterprise buyers is harder.”

Indeed, the true costs of deploying and supporting SharePoint are not well understood. Fundamental misconceptions about SharePoint prevent organizations from deploying it effectively and realizing its value. Many IT executives view SharePoint as a shrink-wrapped product that can be installed and configured in hours or days. In fact, it cannot. SharePoint is truly an enterprise information platform and must be treated as such. That means SharePoint configuration work needs to be well-planned and designed—not conducted in an ad-hoc fashion.

What’s more, because SharePoint has been popular among users, SharePoint sites have popped up all over enterprises, resulting in what is known as “SharePoint sprawl.” The ability for users to easily create and manage a SharePoint site is one of the product’s benefits, but the subsequent sprawl takes up lots of storage space, increases costs and makes it harder for users to find documents due to inconsistent metadata and tagging.

This article explores the true costs of SharePoint—both expected and unexpected. By gaining a firm handle on these costs, IT leaders will be able to identify whether the product is right for their organizations and will be better prepared to take advantage of SharePoints many benefits.

Expected Costs

When determining the true cost of deploying SharePoint, CIOs need to consider the expenses typically associated with rolling out any new software product, such as the cost of licenses, server software, virus protection, hardware and infrastructure, and IT staff. Here’s a breakdown of the costs IT leaders can expect to incur when deploying SharePoint.

1. SharePoint Product Licenses: Microsoft offers different licensing options for SharePoint. Pricing for each of these options can vary considerably based on an organization’s licensing agreement with Microsoft. In this regard, it is important for IT leaders to determine if they are going to be employing the free version of SharePoint, known as WSS (Windows SharePoint Services), or if they’ll use MOSS (Microsoft Office SharePoint Server) Standard, Enterprise or SharePoint for Internet Sites.

WSS is the base level of SharePoint that is freely available with Windows Server 2003 and above. No client license is needed for it. MOSS Standard offers additional functionality including records management capabilities and enhanced searching. MOSS Enterprise offers even more: Web-based electronic forms (InfoPath on the Web), the business data catalog (BDC) for connectivity to databases, and Excel services for rendering Excel spreadsheets via the Web in SharePoint. Both versions of MOSS require the purchase of a client access license.

The version of SharePoint a CIO selects will depend upon the functionality his or her organization needs, and the cost of those licenses will in turn depend on the number of instances of server software that is running at any given time and the number of users.

2. Microsoft SQL Server Licenses: The purchase of SharePoint doesnt include the cost of Microsoft SQL Server, which is used to store the actual SharePoint content and corresponding metadata. In most cases, companies pursuing SharePoint are already running a SQL Server. If so, the SQL Server database servers could be used, or an additional SQL database may need to be installed and configured as part of the SharePoint server farm. The optimal database configuration will be predicated upon requirements for scale, redundancy and performance. Pricing will vary significantly depending on the configuration and the type of software license agreement a company has with Microsoft.

3. Windows Server Software: All SharePoint Servers will be required to run on Windows Server 2003 or Windows Server 2008 regardless of whether they’re physical machines or virtual machines. The SharePoint farm can be fully contained, run on one Windows Server, or the farm can be distributed across multiple Windows servers depending on requirements for scale, redundancy and performance. Pricing will vary for Windows server depending on the configuration and type of license agreement.

4. Virus Protection and Backup: SharePoint platforms need to be secure. To that end, Microsoft offers a number of virus protection and back-up products specifically geared toward SharePoint. Additionally, a number of third-party suppliers provide virus protection and backup products for SharePoint. The prices for these products vary. They can be user- or server-based or both.

5. Hardware and Infrastructure: The hardware required to run a SharePoint environment includes the actual computers functioning as servers (for MS SQL database, SharePoint Web front-end servers, SharePoint application servers), the disk storage (local or a storage area network), and the necessary networking hardware and workstations. Most companies already have the networking and workstations in place to support SharePoint; what they need are additional server-based components. If SharePoint is being employed over a WAN, for instance, CIOs may want to explore infrastructure optimization appliances, which can be deployed as software running on industry-standard servers or as pre-packaged hardware solutions. Software-based appliances start at $5,000 and hardware-based appliances start at $18,000.

6. IT Staff: The IT staff needed to support a SharePoint implementation will depend on a number of variables. For example, if users are building their own sites and content with basic SharePoint features, the IT support costs will be lower.

However, if an IT department is using SharePoint as a development platform for business applications, costs will increase because developers and quality assurance testers will be needed. Business analysts, project managers, IT configuration staff and IT help desk staff may also be needed. The amount of time these staff members devote to implementing and supporting SharePoint depends on the pace at which SharePoint is being deployed and on how much advanced configuration and development work is needed.

7. Third-Party Products: Like all software, SharePoint is not perfect in that it does not solve every problem perfectly. Tom Rizzo, Microsofts senior director for SharePoint, says that the product was designed to provide a rich set of functionality, and where gaps exist, third-party vendors have introduced specific products to fill such voids. Examples of third-party products include tools for image capture, metadata replication and workflow supplements. SharePoint, more so than any other enterprise content management (ECM) platform, has set the stage for a global market of third-party products. The cost of these third-party products varies.

8. Configuration Management: SharePoint 2007’s phenomenal growth has occurred despite the fact that it doesnt have overly mature capabilities for configuration, replication, and the promotion of changes to code. As a result, additional time should be allocated toward configuration management. The cost of configuration management will be predicated upon an organization’s process for promoting code from one environment to another. For example, for an organization with finely tuned and documented processes, it may take a week or more to prepare this type of configuration management effort for SharePoint.

9. Consulting costs: IT organizations may need to hire consultants to help configure SharePoint’s many administrative options and to help integrate third-party products with it.

10. Quality Assurance: QA testing should extend beyond out-of-the-box functionality to include testing of custom development, the integration of third-party products, and any formal configuration exercises. As a general rule, CIOs should allocate five to 10 percent of their overall SharePoint project effort to quality assurance.

Unexpected Costs

It’s the unexpected costs—the costs that IT leaders don’t think to include into their business cases for SharePoint—that eat into their ROI. To get the biggest bang for your SharePoint buck, factor these expenses into your SharePoint strategy.

1. Governance: SharePoints greatest advantage—its simplicity and ease of use—is often its biggest curse. Because it’s so easy to use, adoption is high. The drawback of high user adoption is that the product is used inconsistently. As a result, design and governance standards need to be created.

Time and effort needs to be put toward developing and maintaining a SharePoint governance plan that outlines the type of content that should be loaded into the system, records policies, standard processes and metadata constructs, and guidelines for approaching and supporting SharePoint projects. IT leaders don’t need to design an entire governance strategy up front. Instead, they should do some initial planning and let their governance standards evolve to reflect changing user patterns.

2. Change Management: After deploying SharePoint, users will need to change their approaches to creating and managing information. Given people’s reluctance to change, a proactive change management program is recommended. This may be as simple as a formal communication from the executive sponsor stating the importance of SharePoint. It could also be an internal newsletter, e-mail campaign to promote the proper use of SharePoint, and “lunch and learn” demonstrations to give people a sense as to how SharePoint can make their lives easier. The costs of the change management effort will vary depending upon its intensity.

3. SharePoint Application Training: Even if your users are familiar with SharePoint, using it to solve a specific business problem (such as automating a contract management or accounts payable process) typically requires some training. Training can be performed by your staff or outside consultants. Since SharePoint’s user interface is intuitive, the training effort for end-users is usually measured in hours rather than days or weeks while SharePoint administrators may need a few days of training.

5. SharePoint Community Participation: The SharePoint community is unlike any other ECM community. It is collegial, always on and continually expanding. On SharePoint Saturdays, for example, SharePoint experts volunteer their time to speak at Microsoft offices. There is no charge to attend one of these presentations, at which hundreds of people gather (a testament to the growing role of the SharePoint community.) SharePoint Saturdays are a great source of information, but should you elect to attend these events or the many SharePoint conferences taking place around the world, factor travel expenses into your SharePoint cost equation.

6. SharePoint Code Management: When development takes place in SharePoint, it should be managed in a controlled and traceable manner. To that end, CIOs should invest in code management and plug-ins for Visual Studio or other integrated development environments that allow for the creation and management of SharePoint source code. The costs for such tools can range in the hundreds of dollars to thousands of dollars.

SharePoint: Worth the Costs?

After digesting all of this information, you may wonder if SharePoint is worth all of the expense.

The fact is, managing enterprise information and processes is not a trivial exercise. More than 80 percent of enterprise information is stored as unstructured content. SharePoint gives structure to that content and makes it easy for users to find and access.

If CIOs treat SharePoint as off-the-shelf software, the costs will indeed be onerous. However, if CIOs treat it as an enterprise information platform and content management system, SharePoint will yield tremendous value—and potentially at a fraction of the cost of comparable ECM solutions.

Follow me on Twitter…

Sharepoint and Enterprise 2.0: The good, the bad, and the ugly

Sharepoint and Enterprise 2.0: The good, the bad, and the ugly | Enterprise Web 2.0 | ZDNet.com

Depending on which numbers you look at these days, about a third of all companies right now are using Enterprise 2.0-style tools to enable collaboration and management of their knowledge. This is in stark contrast to just three years ago when the only tools most workers could count on for communicating with others and sharing knowledge was e-mail, the phone, and if they were lucky, an instant messaging or content management application.

It increasingly appears there is no such thing as Enterprise 2.0-in-a-boxToday’s worker landscape is a surprisingly different place with the rising use of Web 2.0 applications such as blogs and wikis and other applications. Use of public social networks like LinkedIn and Facebook are practically commonplace these days, even if not quite ubiquitous (a good percentage of companies still block access to these in fact).

And the Enterprise 2.0 landscape continues to change: The increasingly popular Twitter service has become almost trendy to use in some business circles, though it currently predominates in PR and marketing for the moment. This has given rise to a new generation of enterprise-class social messaging applications such as Yammer and Signals are used behind the firewall these days, though these are not reaching even double-digit percentages of adoption yet. Mobile devices especially have become rich multi-channel collaboration consoles for communicating in just about any way you prefer including voice, e-mail, SMS, chat, Web, social messaging, and pretty much anything else for which you can find an installable application. There seem to be countless choices when it comes to communication and collaborating in today’s workplace.

But when it comes to Enterprise 2.0 in particular — and you can read my most detailed explanation of exactly what the concepts of Enterprise 2.0 are here — the software solution that most organizations seem to reach for today in an almost knee-jerk reaction is Microsoft Sharepoint. In fact, last summer Forrester predicted that Sharepoint would “steamroll” the Enterprise 2.0 market despite “taking heat from some observers about SharePoint’s wiki, blog and social networking functionality.“

These concerns about SharePoint’s ability to be an effective Enterprise 2.0 platform is one I hear echoed a lot with practitioners I talk to. In spite of this, I correspondingly hear that SharePoint is in fact what most organizations are planning on using when it comes to 2.0-style collaboration and knowledge management. Why the apparent disconnect between the perceived suitability (which we’ll dissect in a moment) and actual use? Part of it is SharePoint’s stunning penetration in the software business. The recent adoption statistics for SharePoint should be sobering for anyone planning to provide competing tools:

• 55% of organizations have implemented or are considering implementing SharePoint (Global Intranet Trends 2009 report – 227 participant organizations)
• 46% of those companies using social media on the intranet are using
  SharePoint(Intranet 2.0 Global Survey – 430+ participant organizations)
• Only 47% of organizations have a defined governance model (Intranet 2.0 Global Survey)
• 70% use at the department level; only 38% use it at the enterprise level (AIIM)

In other words, SharePoint is already in most organizations today: Leading Enterprise Web 2.0 firm Jive Software’s CEO Dave Hirsch has gone on record in the past saying that “around 80 percent of our customers have SharePoint”. In the most recent authoritative number I could find, an estimated 85 million end-user licenses of SharePoint were in customers’ hands over a year ago and that number is likely a good bit higher today. This paints a fairly clear picture of a workflow and document management market leader that is highly entrenched, already paid for in many cases, and most likely to make the top of the short list of any Enterprise 2.0 initiative.

Microsoft SharePoint — often referred to these days as MOSS, for Microsoft Office SharePoint Server — is certainly one of the most respected and widely used platforms of its kind. It has a truly extensive set of capabilities which Microsoft typically categorizes into five major groups: Portal, search, content management, workflow, and business intelligence. Like most popular CMS and community platforms these days, SharePoint also has open architecture that ensures that almost anything that is perceived as missing can be supplemented by acquiring one of the many 3rd party addons or by custom development of what is needed. However, all products, especially very complex ones, have their own strengths and weaknesses and this is where the good and not-so-good begin to become an issue.

When Harvard’s Andrew McAfee first identified what was seemingly unique about Enterprise 2.0 compared to traditional collaboration and knowledge management tools he coined a mnemonic known as SLATES. This mnemonic forms a checklist of properties that seemed integral to successful Enterprise 2.0 implementations (based on successful early case studies). I originally covered the properties of SLATES back in 2006 when Enterprise 2.0 first arrived on the scene when I said it had the potential to “free your intranet” and it remains an excellent description of the key elements for successful social software. This was back in the time when I could ask technical audiences as collaborative conferences if they had access to blogs and wikis at work and virtually no one would raise their hand. Now they all do.

Specifically, for this discussion it’s blogs and wikis that remain the focus of Enterprise 2.0, despite there being more advanced types of applications that also qualify. Mostly this is because they are by far the most popular social tools in the enterprise, though social networking is also becoming increasingly important. It’s from this perspective that we’ll look at how SharePoint measures up to the ideal and practice of Enterprise 2.0, which can drive a variety of benefits such as higher worker productivity, improved knowledge retention, cross-functional innovation, and even as a corporate catalyst. That is, if the software you are using actually enables such scenarios in a widespread manner.

I should also be clear that SharePoint can be used to do a lot more than what we usually ascribe to Enterprise 2.0, the latter for which the elevator pitch is freeform, emergent, social collaboration and less the physical document share methodologies (such sharing Word, Excel, PDF, etc. files) it was originally designed for.

For the purposes of the discussion below, I’ll examine where SharePoint is suitable for this particular (though very significant) use case. And if you’re wondering how significant this topic this is, the Enterprise 2.0 story is primarily aimed at knowledge workers engaged in complex, collaborative projects which have had few effective software tools until recently, in other words strategic business activities. Industries like finance, government, civil engineering, transportation, and many others are trend to be top heavy with this kind of worker and are likely the last major bastions of productivity gains in modern economies, if the right solutions can be brought to bear. In other words, Enterprise 2.0 can help some of our most important and most valuable workers do better work while providing more value to the organization as a whole.

As a result of all this, and due the fact that the single most frequently asked question I get about Enterprise 2.0 is if SharePoint is a suitable platform for it (short answer: it definitely depends), I’ve spent the last few weeks taking a hard look at SharePoint the product itself, talked extensively with SharePoint and Enterprise 2.0 practitioners both, and created the resulting analysis. I’m hoping it helps you make useful decisions in your Enterprise 2.0 projects and initiatives.

The issues and challenges of using SharePoint for Enterprise 2.0

1. SharePoint is not a Web 2.0 native. This can be a compliment or an indictment depending on who you talk to. However, it’s very difficult these days to deny that innovation in social and collaborative systems is almost exclusively coming from the consumer Web. The Web has been far and away the most successful in creating powerful network effects and as the source of the world’s largest and most vibrant social systems. SharePoint was designed before we had learned many of the modern social computing lessons and though has powerful capabilities, the platform overall is excessively complex and has relatively weak support for the most common Enterprise 2.0 application types, particularly blogs and wikis, but also social networking features. SharePoint, at least out of the box, fails the SLATES test. It’s particularly weak around critical capabilities such as encouraging emergence, being freeform enough, and support tagging well (the latter which has proven to be surprisingly important for certain outcomes). For example, one of the more common offerings I saw at CeBIT in Hannover earlier this month was companies selling you the add-ons needed to shore up SharePoint’s collaboration features to have parity with newer, more modern tools. To be fair, the SharePoint community has also been proactive on this topic, and the relatively new SharePoint Community Kit goes a good bit of the way towards resolving many of these issues. A quick tour of its features also highlights just how much is missing from today’s standard SharePoint configuration.
2. The technology landscape of the enterprise environment fits SharePoint well; the business requirements to a lesser extent. While Web 2.0 tools are often unique viral and tend to have much better than average ease-of-use due to the competitive nature of the public network, they don’t transition well automatically into the Enterprise environment where multi-level security, governance, and policy controls are virtually mandatory and which few of the open source (or even commercial) Enterprise 2.0 tools from consumer world support adequately. SharePoint is strong many of these points with excellent Active Directory integration and better support for enterprise technologies. Sharepoint also integrates well with file servers, documents of many types, and traditional corporate databases, though this also reflects an older version of the technology landscape. While today’s enterprise does often not look very much like the Web, at this stage in the game, that’s not necessarily a good thing. Governance and policy capabilities in SharePoint are acceptable, but not best of breed and SharePoint has credible unified search capabilities (which is the “S” in SLATES) and works especially well if SharePoint is the only document management, portal, and knowledge management infrastructure in the organization.
3. The wilds of the open network can be a challenge for Sharepoint. Practitioners I spoke with consistently reported that SharePoint works best with homogeneous environments and not nearly as well when the environment isn’t controlled, especially on the browser-side (see this chart for details) and on mobile devices. This makes opening up SharePoint environments to work with partners, customers, and even the general public, one of the more requested Enterprise 2.0 scenarios in my experience, to be more difficult than with other platforms which were designed to function in highly diverse environments.
4. Self-service capabilities are lacking or not emphasized. One of the important aspects of Enterprise 2.0 is its freeformedness which helps lead to emergent structure and processes. In other words, a blog or wiki can be used for just about any activity by virtue of the ability of the users to aggregate thousands of tiny decisions that affect behavior and content around the work contained within the tools. Traditional enterprise systems, including SharePoint, tend to be more rigid in their ability to be shaped by users and too often force users into pre-determined uses rather than letting the users shape the use of the tools to best fit the work. Many large SharePoint installations consist of hundreds or even thousands of smaller sites, each of which must be made consistent in terms of layout and navigation if centralized administration and governance is to be effective. David Hobbs recently pointed out how rare this is but the 2.0 world has discovered that the more this is handed over to users, the better this works and critically, the better it scales up. The lesson: The more cookie-cutter SharePoint installations are, the easier they are to manage but the more they unnaturally constrain their use and prevent desirable outcomes. Users should be able to create sites within SharePoint, customize them over time to meet the local requirements, and let them evolve and improve through shared contributions. It is, however, by no means impossible to enable this kind of self-service with SharePoint but it does not encourage it nor is it a core design principle for the product.
5. Cost and complexity. One of the consistent messages I heard when speaking to SharePoint practitioners is the product’s complexity and high cost. The diagram at the beginning of this post begins to give a sense of the extent and the depth to the features of the MOSS platform. Invariably, this means highly trained implementors, administrators, and technical support staff are required to deploy and run it, which all add to the total cost of ownership. And SharePoint’s inherent sophistication can also mean slow adoption and low engagement by users. In fact, this is a central lesson in Web 2.0 design, that complexity is the enemy of ease-of-use and adoption; most 2.0 products are almost brutally simple in their user experience. SharePoint is also priced as an enterprise product and can be very expensive (at least compared to most Enterprise 2.0 products) for a large installation. However, many licenses are bundled with corporate purchases and as a result many organizations already have client licenses they are underutilizing.

I should be clear that I am not overtly negative on using SharePoint for Enterprise 2.0 and certainly there are those that are doing it. However, emphasizing the tool first, no matter how ready-at-hand, to create an enterprise-class information management solution is rarely the proper way to go — other than for solely financially expedient reasons — and rarely is that the only criteria. It also increasingly appears there is no such thing as Enterprise 2.0-in-a-box and that organizations need to find tools that best fit their culture and needs to get the best results.

In general, I’m also finding that IT departments, which are usually rather comfortable running a great deal of network infrastructure with Microsoft tools and platforms tend to favor SharePoint while business users tend to like it less and prefer newer more modern tools. This combined with either already active SharePoint installations or unused licenses means that SharePoint is usually a heavy favorite on the IT side, regardless of whether it will be able to provide the desired Enterprise 2.0 outcomes to the business. And we shouldn’t forget that SharePoint isn’t standing still as a product either and Microsoft is certainly working on newer versions that will address some of the issues covered here.

These state of affairs, particularly prevalent in medium to large organizations, is increasingly a significant topic of debate as Enterprise 2.0 adoption has achieved a mainstream tipping point within many organizations this year. I’ve perceived lately that more and more businesses are facing this topic with today’s uncertain economic times as the backdrop, making the financial component of the decision much stronger than it would be otherwise. Buyer beware, however, since these choices will set the stage for how effective your workers will be in the coming years. Years that will likely see many organizations needing to marshaling the very best capabilities of their workers to successfully transform to new market conditions and thrive.

Determining the ROI of Enterprise 2.0

http://blogs.zdnet.com/Hinchcliffe/?p=334

Determining the ROI of Enterprise 2.0 | Enterprise Web 2.0 | ZDNet.com

Despite recent statistics showing that Enterprise 2.0 tools have spread to about a third of businesses globally, there remain ongoing questions being asked in the enterprise software community about the real returns that they provide to businesses that deploy them.Many IT solutions create value only after traveling through an indirect chain of cause and effect. Certainly blogs, wikis, and social networks are popular on public networks, but does that translate to meaningful bottom line value to organizations? In other words, is Enterprise 2.0 truly strategic in the unique way that information technology can so often be?

This is a key question since actual penetration of these tools is almost certainly lower than the one third figure I mention above. Most organizations today, even the ones where the applications are available to employees currently, are not yet exhorting workers to adopt these tools en masse despite a suite of compelling arguments and a growing set of case studies. Even impressive citations such as the recent TransUnion Enterprise 2.0 case study that claims an eye-opening 50x return on investment (using the most basic ROI formula for calculating returns) are not yet initiating widespread inquiry.

Instead, while we’re seeing widespread interest and acceptance of Enterprise 2.0 in the workplace, there is still mostly a wait-and-see attitude amongst IT managers and business leaders at the moment. The reasons for this seem to fall into three general categories:

One is an broad wariness of a new horizontal information technology approach that purports to solve so many problems and will overlap extensively with existing solutions from e-mail and instant messaging to content/document management and knowledge management systems, to name just a few. Other related concerns are feelings that workers already have a lot of software to use today, that the tools already exist in the organization (see my Enterprise 2.0 and SharePoint discussion a few weeks ago), or that the available tools aren’t fully enterprise-ready yet.

A second set of issues is related to corporate culture and its fundamentally hierarchical nature, which seems anathema to the flattened, highly social nature of Web 2.0 in the enterprise. At this point, it’s becoming increasingly clear that in some tightly controlled, top-down organizations, culture is indeed an impediment to the use of emergent, social computing. Fortunately, there is now enough evidence visible in current case studies that many industries can indeed benefit from Enterprise 2.0.

The last issue is one that has bedeviled software and its strategic application to business since the very beginning, namely the accurate predicting of the return on investment of an IT solution. Andrew McAfee, who originally coined Enterprise 2.0, summarized the challenges succinctly a while back in The Case Against the Business Case. The central problem? Assets that are intangible, such as knowledge, social capital, and situated technology — which Enterprise 2.0 is primarily focused on — rarely have direct impact to financial outcomes such as revenues and profits. Its their downstream effects that generate the most value to the business.

There have been a number of good discussions on this topic lately including a detailed exploration of the issue by Hutch Carpenter, where he concludes that “software ROI is only as predictable as the activity for which it is used” and Martin Koser’s discussion on the challenges of coming up with the concepts and measures for “collaborative performance”. Susan Scrupski has also been exploring the ROI of Enterprise 2.0 and in her call for case studies recently highlighted that while we have a good number of them, there is still not enough ROI coverage in a wide set of industries.

However, a key aspect of the ROI issue is that the strategic capabilities represented by Enterprise 2.0 are primarily emergent in nature, instead of carefully aimed at and unleashed at specific problems. Classical technology investments such as assembly lines and industrial automation could be quantified because their most significant effect was direct and measurable. Many IT solutions (think e-mail or service-oriented architecture) are general purpose and tend to be indirect and create value only after traveling through an indirect chain of cause and effect to enable a positive business outcome. The problem with this is that it’s very hard to either measure or predict accurately, especially since IT solutions tend to have longer chains of cause and effect than other technologies. While this often builds up accumulated value by its ability to cascade across a business, it’s very unsatisfying from the traditional perspective of investment in X by spending Y to achieve a predicted return Z.

The net result of this lack of clarity is a hold up on the explicit use of Enterprise 2.0 for strategic benefit by businesses, even as the tools are proliferating, often virally, in many organizations. For now, the tools are often used in a localized or ad hoc fashion, or at very least, without a concerted business-wide effort to systematically capture the perceived business value. This question is important since an accumulating body of knowledge is pointing to potentially dramatic business returns with Enterprise 2.0. If these continue to be borne out, it will affect the competitive and financial positions of the companies that are proactive and therefore their long-term marketplace success. As I outlined recently in my Economics 2.0 session at Web 2.0 Expo last week, Enterprise 2.0 and other new modes of business seem to herald new, much more efficient — and just as significantly, fundamentally different — ways of running our businesses.

What will change the current status quo? A preponderance of case studies in the affirmative? Sustained, first-hand experience of the early benefits convincing senior management? Lack of reports of negative outcomes like data theft and excessive socializing? Yes, it will be all of these, but like the well-known examples of successful emergent systems such as termite colonies, bird flocks, animal herds, business organizations, and now online communities, there are real limits on the ability to direct emergent systems towards focused outcomes. In the end, all one can actually do predictably is enable the possibilities and not prevent them.

Innovation often comes from where you least expect it and harnessing collective intelligence, the core principle of Web 2.0 as well as Enterprise 2.0, is the very art of eliciting value from emergent systems such as the Web and our intranets. That this value is forming the bulk of the networked economy (open source software, social networks, social media sharing, etc.) is one of the signature lessons of the era of open business models and 2.0.

Update: Based on some feedback to this post over the last day, I would like to make it clear that there is little doubt that Enterprise 2.0 delivers ROI today, at least on the collaborative side (the jury still seems to be out on the social networking side). Recently, researchers have even been able to put a real numerical value on social connections. My point is just that it’s difficult to determine where the returns (often the most important ones) will appear when the tools have so many downstream effects. That’s not to say either that Enterprise 2.0 ecosystems can’t be directed to some degree to achieve business objectives. In fact, I believe the the next generation of workers will be experts at achieving their goals by eliciting and then harvesting the knowledge and capabilities they need over the network.

The TCO and ROI of SharePoint

When choosing a team space collaboration technology solution, one should consider both the total cost of ownership (TCO) and the expected return on investment (ROI).   The diagram below shows that a measurable ROI will increase the more structured the context.   In other words, the more structured the context, the easier the ability to measure something which in turn can lead to productivity gains and a higher return on investment. 

 

 

Products like MS SharePoint or Lotus Quickr provide a cost effective solution for basic ad-hoc file sharing and project collaboration.  However, additional licensing, applications, and/or custom development may be required the more structured the context thus increasing the TCO and ongoing maintenance of these applications.   Furthermore, ROI may be difficult to calculate as hard numbers are not always easily identified.  The calculation of ROI might need to be focused to a particular business unit use case(s), business process, and might also consider the following:

• Adoption of Tools: Ensuring users adopt and properly leverage the technology.
• Perceived Benefits: Ensure the link between technology and (perceived) business value is clear.
• Timeframe: Establish a timeframe within a realized return on investment could be achieved.
• Metrics: Attempt to establish both hard and soft metrics in an attempt to measure ROI.

Some economics to consider

eRoom’s days are numbered.  I remain a fan but I’m realistic.  Why?  Simple economics.   Sharepoint Services is free — and customers are looking to reduce costs today wherever possible.  And switching off of eRoom will save money in the short run.   The return on investment to hire some consultant or 2 to migrate off of eRoom will be recouped in a year as companies save the maintenance/support they used to pay EMC.  

Now MOSS will cost them down the road and it’s unsure if these eRoom customers actually consider the total cost of ownership and how Sharepoint might affect that over time.   The reality is that Sharepoint is untested in a large deployment — and no one really knows what type of mess it might create down the road.  You just might be migrating one mess of eroom, documentum, notes, fileshares to an even bigger consolidated mess in sharepoint —  that is if its deployment and growth are not managed properly.  

And keep in mind that it’s not easy to do migrate off a platform like eRoom…as eRoom in most organizations as mission critical an application as email.   The switching costs are high.  Even a small installation with 1 eRoom server and a few hundred rooms and a few hundred gb of data is not a trivial migration.   Imagine 7 servers or 20 servers and terabytes of data.   Sure you can write some code that dumps data out of eRoom and puts it into Sharepoint.   However, the project planning and change management planning that needs to go into this does takes many months if not longer and is a significant investment.   I think the point here is simple economics. 

I think EMC shouldn’t forget why thousands of customers use eRoom today and grew eRoom so quickly in their organization….it’s called user adoption as eRoom was easier to setup,  easy to install, easy to use (compared to the alternatives) — which made it a very economical application with a solid ROI.   And customers paid for that convenience (with licensing costs).  However, today customers no longer have to pay for the same convenience as Microsoft gives WSS away and offers a comparative collaboration and content management alternative.   And you’ve got other web 2.0 competitors jumping on the bandwagon making it a more competitive landscape now.  So you have to look at simple economics if you want to compete.  

Anyway, one word of caution for anyone thinking of migrating to Sharepoint….eRoom and Documentum have been battle tested for many years — and Sharepoint has not been tested.   And as someone who has spent years traveling the globe making this technology work over the last decade, troubleshooted headache after headache after headache — it is NOT easy to scale and manage any collaboration & content management application.   Sure, sharepoint has tight integration with office and WSS is free and there are some very positive feature of the application as a whole.   HOWEVER…I leave you with this final thought….

Collaboration & content management technology has become and will continue to become mission criticial for managing projects and streamlining and running your business processes.   Economics is really important to consider….   But so is reliability and scalability.   Think about it – can you live without email today?   Yes and no…but if email is down, it’s a headache for a CIO to hear the user complaints.   So if I’m a CIO — do you want to trust your mission critical business processes to something that has not been tested and proven????    If it goes down….if it doesn’t quite work right….or doesn’t scale right…. do you want to trust your business on it?    So seriously think about that as you think about saving costs in the short run.   Take baby steps if you are going to migrate…. think about context, make sure you are close your users, and get the right advice.  Be skeptical of the cool demos, song and dance, and marketing before you make an investment in this type of technology – no matter what platform you choose.