The Case for a Business Case when Rolling Out SharePoint 2010

Before Migrating to SharePoint 2010 or Implementing SharePoint for the first time – do a business case!

The facts are stark: Almost 70% of enterprises are using SharePoint (Source) however the results of a survey conducted by the Association for Information and Image Management (AIIM) indicate that less than 50 percent of SharePoint implementations were subject to a formal business case, and only half of those that did required a financial justification. (Source)

Even if you’re sure you want to implement SharePoint for the first time or migrate to SharePoint 2010, it’s a good idea to do a business case. Why? Not just because it’s good form.  Unfortunately, organizations that skip this step risk taking steps in the wrong direction instead of rectifying identified problems with elegant solutions.

First, let’s take a look at what a business case is:

  • A document or statement that captures the reasoning for initiating a project
  • An acknowledgement of resources needed to complete the project and an understanding of the net value to the organization of doing the project
  • An accounting of quantifiable and unquantifiable benefits of doing the project
  • An outline of the known risks of doing the project
  • A look at the alternatives to the planned implementation, including doing nothing

SharePoint 2010 is a great product, with many new features including seamless integration with Office, major improvements to Search, and great collaboration features.  So, why is it a good idea to do a business case even when you’re already clear that you want to migrate to SharePoint 2010 or implement SharePoint for the first time?

The act of creating the business case begins to make the successes and impacts of the project a reality. In the case of SharePoint 2010, one of the first important tasks is to really articulate what SharePoint will be FOR YOU and your organization.  SharePoint is multifaceted.  The more focused an organization can be on what it needs out of SharePoint, the more likely its implementation will be successful.

Writing a business case means thinking about the questions of why are we doing this? What are the costs, timescale, benefits, and risks?  Having thought through these questions and their answers, even best guesses at ROI and benefits, and presenting them in a well formed document provides you with something to share and enables you to involve other people. Such a document is a good means of getting buy-in and socializing the changes you want to see, as early in the planning stages. Even when change will bring a positive outcome, it’s never easy to get everyone on the same page for a smooth transition.  SharePoint can never be rolled out by one individual – as a system it will need at least cooperation from just about everyone in an organization, and starting with a clear understanding of why the change is happening and what the benefits are provides a solid foundation for success.

Even in organizations planning a migration to SharePoint 2010, there are multiple ways and reasons to migrate. The costs can be considerable, just like the benefits.  Consider this statement from Rob Helm, an analyst from Directions on Microsoft:  “SharePoint 2010 will challenge even companies already using SharePoint… Even for existing users, there are differences. The way supporting services are managed is different. Administrators and architects will need a lot of ramp-up time to understand the new product version. In some areas, it’s an even bigger jump than we saw moving from SharePoint 2003 to SharePoint 2007.”  (Source)

“Technology provides no benefits of its own; it is the application of technology to business opportunities that produces ROI.”  —Robert McDowell, In Search of Business Value   (Source)

Getting specific on the tensions solved by migrating to or implementing SharePoint 2010 not only allows your organization to do the right thing for its growth, but also to have the means to look back and assess success.

If, like many organizations do, you plan on hiring a vendor to do the implementation or migration, you will want this information prepared to communicate your needs to the vendor.  You’ll be better able to evaluate the vendor’s proposals and solutions if you’ve thought your needs and concerns through. Edgewater does many SharePoint implementation and migration projects and no two are ever the same.  It’s important that you use SharePoint to build solutions to the problems specific to your business. Don’t just skim the surface and fit your needs to a list of features that you know of or that already exist. This will lead to poor adoption and waste of your resources. The better you understand your actual needs, the better your solution can be.

Another important facet of the business case for SharePoint is that it encourages you to focus on ROI – it’s important for companies to really understand the long term costs of a SharePoint implementation.  When implemented correctly, SharePoint 2010 can save your business considerable costs and streamline your processes.

In addition, training is critical to making any conversion a success.  Sitting down to write or review a business case can be the first step in really thinking through what it means to make a successful change, how best to do it, and what it means in terms of specific costs and specific benefits to the organization.

So a good business case:

  • Backs up a decision to transition to SharePoint 2010
  • Forecasts expected ROI and other intangible benefits
  • Provides a vehicle for buy-in for both decision makers and potential users
  • Outlines measurable goals for the business, ensures actions are in-line with ideas
  • Reveals level of effort to implement a new SharePoint platform
  • Is a good vehicle to socialize the thinking and set expectations

A good business case can help your company focus on allocating the right resources, know what to expect, and be clear on what constitutes a successful project completion.  If your business case is convincing at a certain price point, and all your RFP responses come in higher than that, you’ll readily know if the project is really worth pursuing, or what portion of it to focus on first if you’ve written a good business case.

As author J. Peter Bruzzese  puts it, “SharePoint 2010 is jam-packed with new features that matter, ones that will increase productivity if used properly. I predict the number of companies using SharePoint is going to soar with this next release. I’ve been working with SharePoint since its first release (where I hated it) through 2007 (where it was growing on me) on to 2010 (where I can honestly say I’m really impressed by and loving it).” (Source) There are many resources available through searching online to assist with creating a business case for SharePoint 2010, but only someone with real knowledge of YOUR organization can write the business case for you, and ensure you’re using SharePoint 2010 properly to serve your business’s needs.

— — —

Related post on ROI of Enterprise 2.0:
https://edgewatertech.wordpress.com/2009/05/03/why-ceo%E2%80%99s-must-care-about-enterprise-20-as-a-strategic-imperative/

Making sense of SharePoint’s Workflow and BPM capabilities

Workflow and BPM often get lumped together but it is important to understand the difference between them if you are to pick the right tool for your enterprise. While it is generally agreed that workflow is for modeling simple sequential processes and BPM solutions are more capable of handling complex tasks the distinction between the two needs to be further sharpened. According to David McCoy of Gartner BPM can be defined as “… a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes.” Workflow on the other hand is concerned with tasks and application-specific sequencing of activities through a series of predefined steps, involving a small group of people and/or closely related applications. The distinction between the two is far from crisp and in fact it can be argued that both are part of the same continuum. However, there is a distinct difference in focus and complexity between the two. Here is a chart that attempts to further define the two based on capabilities and task suitability.

According to a recent survey by Forrester, Microsoft and SharePoint came in as #1 among the IT decision makers for use as BPM platform followed by Oracle, SAP, IBM, and a host of other BPM centric companies. Forrester report further notes that despite Microsoft’s best efforts to not position SharePoint as a BPM solution (rather as a collaborative workflow solution); the message does not seem to come across clearly. This confusion seems to thrive due to lack of clear and well-defined goals for business process automation and understanding of capabilities of SharePoint and BPM suites (BPMS).  The Forrester report outlines that SharePoint’s features for supporting true BPM are limited. Most of SharePoint’s capabilities in this arena are founded on Windows workflow foundation (WF). While a custom solution can be developed based on SharePoint and WF API to support BPM like capabilities, such an endeavor is bound to be expensive and brittle. SharePoint shines best when OTB capabilities are leveraged to the maximum and customizations are managed carefully. SharePoint’s workflow, document management and collaboration features can be used to develop robust workflow applications that can simplify and automate document & form centric business processes. SharePoint can also serve as a hub of cross-department and cross-application integration but only at the user interface level. SharePoint does not pretend to act as middleware or an enterprise service bus (ESB) and therefore does not provide any standards based application integration features – tasks best left to dedicated integration platforms or BPM solutions.

The limitations of SharePoint’s built-in workflow and underlying Windows Workflow surface quickly when tested against complexities of true enterprise business process automation scenarios. SharePoint’s workflow processes are constrained by the Site Collection boundaries. Therefore any workflow that needs to span organizational boundaries and as results site collections becomes difficult to manage and brittle. For example if a budget approval process needs to go through the finance department, corporate office and local approvals and if any of these structures use their own Site Collections the workflow process will require custom coding or manual workarounds. This constraint limits SharePoint’s workflow scope to department or local application level. WF processes are also limited to either sequence or state machine patterns. There is also no support for a user who makes a mistake and needs to go back to the previous step during a workflow. Multi-level approvals are also not supported a document needs to be routed back to one of the earlier approvers rather than the author. SharePoint workflows are executable programs and therefore cannot adopt easily at runtime (after instantiation) to changes in the rules that may result from changes in business process environment (e.g. regulation changes, corporate policy change, etc.)

While SharePoint is not ideal for complex business process automation it can certainly be used to get started. If all you organization needs is automation of simple and commonly used business tasks (approvals, document management, simple HR applications, financial approvals, etc.)  that do not require tight integration with other data systems and do not require complex exception processing, modeling, optimization, monitoring, etc., then it is a good candidate for SharePoint workflow. However, if your organization is truly looking into business process automation and business process improvement (BPI) then there are many 3rd party solutions (AgilePoint, Global360, K2, Nintex etc.) that can be layered on top of SharePoint to create a more robust solution. The advantage of a layered solution is that 3rd party vendors are able to leverage Microsoft’s significant investment in ease of use, collaboration and user interface integration capabilities of SharePoint while adding core BPM functionality. Such solutions are also typically less expensive and deploy more quickly than a traditional full-blown BPM solution (depending on the situation).

There two basic flavors of the layered BPM solutions (products that leverage SharePoint’s platform & interface for most interactions). The first flavor of these solutions relies on the underlying WF as their workflow engine. Using WF as the base they have built capabilities that are more advanced than out of the box capabilities of SharePoint. Furthermore they are able to maintain a light footprint by leveraging SharePoint and WF infrastructure. However, they naturally suffer from some of the same shortcomings as WF. The second group of solutions relies on proprietary workflow engines that are not built on top of WF. Such solutions typically have larger footprints since they create their own parallel infrastructure for workflow processing and data storage. Their independent foundation allows them to provide capabilities that are not limited by WF but typically at the cost of additional infrastructure complexity. There is a place for either kind of solution and picking the right tool (SharePoint workflow vs. SP layered BPM vs. dedicated BPM) is a vital cog in any business process automation or improvement endeavor.

However, the story does not end at picking the right tool; in fact it is just getting started. Edgewater recently conducted a case study on the effectiveness of such efforts and found that there is a significant disconnect between popular BPM messaging and the companies deploying such technologies. While ROI is considered to be the holy grail of most IT projects the respondents in the survey noted that “ROI was not the most important factor … “, other areas such as customer satisfaction were more important. Survey also found that while BPM tools are more than capable of modeling complex processes organizations implementing BPM preferred to “start with well-defined process that involved fewer people to get a quick win and buy-in first”. Perhaps the most important finding was that the success or failure or an implementation depends on “solid understanding of the business AND the necessary technical skills to implement BPM; just one won’t work.” Business Process Improvement (BPI) needs to be a continuous learning and optimizing cycle. Picking the right tool is only half the battle, having a clear vision of goals and objectives and how BPM may or may not help achieve those is just as essential.

 

SharePoint 2010 Migration: Options & Planning

Many organizations that are running SharePoint 2003/2007 or other CMS are either actively considering or in the midst of upgrading to SharePoint 2010. In this blog we will look at what is involved in upgrading to SharePoint 2010, various options available for the upgrade, and initial planning that needs to precede the migration.

 There are two basic methods of upgrading/migrating from an older version of SharePoint to SharePoint 2010 that are provided by Microsoft: in-place upgrade and database attach upgrade. In addition, there are numerous third-party tools that can help you migrate content and upgrade to SharePoint 2010 not only from an older version of SharePoint but also from other CMS’. Each method has its own set of benefits depending on the objectives of the migration and specifics of the environment. When selecting a migration path, some of the aspects you may need to consider include:

  • Ability to take the production system offline during the migration
  • Amount of change involved in content and its organization during migration
  • Number of customizations (web parts, themes, meta-data, workflows, etc.)
  • Amount of content being migrated
  • Need to upgrade hardware
  • Need to preserve server farm settings

It is much easier to migrate a clean and lean environment than an environment that is full of obsolete content, unused features and broken customization. Start with cleaning up your existing sites and check for the orphaned sites, lists, web parts, etc. Remove any content that is no longer in use, remove unused features and ensure used features are present and working. Once your existing SharePoint site is in tiptop shape you are ready to plan your migration steps.

Before you put your migration/upgrade in motion you need to understand what migration aspects you can compromise on and hard constraints you have. For example:

  • Can you afford to put your environment in read-only mode for the duration of the upgrade?
  • Does the amount of content you have make it prohibitive to copy it over the network?
  • Do you have a lot of customization that you have to deal with?
  • Are you planning to reorganize or selectively migrate your content?

The answers to these kinds of questions will direct your choice of migration tools. Here is a check list that will help you get organized.


Customizations can have a big impact on how quickly and smoothly your migration goes. Therefore it is important to identify and account for as many of them as possible. PreUpgradeCheck can help but here is a list to help you identify and uncover customizations that can add complexity to your migration efforts.