Tag: Planning

Finding Success with SharePoint Deployments

Finding success with SharePoint or any other collaboration software can be a difficult thing. It has less to do with the technology than it does the people and the way its implemented. Its not that people have bad ideas, they may just underestimate the amount of effort it takes to reach the promised land. There is no silver bullet or application that you deploy and it just magically solves all of the organization’s problems. In many cases the software is deployed as part of an formal or informal effort to breakdown longstanding silos within the organization. Breaking down those silos is difficult and that road is filled with hazards.

A good first step is to clear identify and validate the goals of the implementation and get an understanding of what the expected level of effort is to reach those goals.

Easy Win or Easy Implementation?
The best way to get an easy win or have an easy implementation is to install SharePoint as a workgroup solution. Its very easy to do, and if based on Windows SharePoint Services (WSS) it can be done with existing equipment. Each department or workgroup can then do whatever they want and get as little or as much localized value out of it as they want. The people may seem to be happy with that, but there is a real limit to the amount of success and productivity. Also, it does nothing to promote sharing and collaboration throughout the entire organization. In fact it further reinforces those silos.

Enterprise Needs Governance
If you talk to any long time SharePoint architect or evangelist one of the primary topics is Governance. Its not just a buzzword, it is the single most important determining factor for success in a large organization. It is the glue that holds everything together and gives you the ability to manage the environment without it breaking down into petty fiefdoms. Getting agreement is never as easy as making an independent decision and then acting.

In an enterprise deployment it should support localized management in support of global standards. Just because Governance is in place does not mean that everything must be managed centrally.

Here are some suggestions
– Get executive sponsorship. Organizational change cannot happen without executive sponsorship. State the case with realistic benefits and get buy in.

– Involve as many stakeholders as possible. Like any change people are more likely to adopt it when they have a say in what is done. Not everyone will like every decision, but hopefully they will feel good enough about their involvement that they will participate.

– Address Governance from the start. You cannot easily retrofit these ideas or policies into an established system. The change would be costly and the need to retrain everyone pretty severe.

Benefits to Enterprise versus Workgroup Solutions?
Enterprise deployments benefit organizations by supporting cross-functional collaboration. It also provides a platform for some of the social enterprise capabilities such as central profiles fed with data from sources like Active Directory, HRIS Employee Data, and other data sources particular to the organization. These tools can help make people more productive, but also help to find internal resources and subject matter experts.

Another benefit is that you are more likely to see funding for integration efforts into other enterprise systems such as Business Intelligence (BI), Enterprise Content Management (ECM) or Business Process Management (BPM) solutions. Being able to leverage these other integrations should more than make up for the lack of control the individual organizations’ are asked to give up.

SharePoint Customization Policies and Change Control

This post will cover different forms of customization, discuss the need for IT policies that support customization, and then provide a recommendation for how to manage the customization through change control processes.

What is considered customization?
There are different types of customizations and different ways to apply them. They can include custom styles, MasterPages, Web Parts, Custom Forms, Site Definition or even applications built on top of the API.

Bad customizations are applied manually by adding to or altering system files on the server. These changes are not saved into the configuration database which can cause problems when applying system patches or upgrades. It can also make it much more difficult to add an additional server to the farm as those changes have to be manually applied again. Therefore this should never be done in a production environment.

Well built customizations are deployed using SharePoint’s robust deployment framework for Web Parts and Solutions. This not only produces repeatable results, but it also helps keep multi-server farms in sync and allows those customizations to be pushed out automatically to new servers joined to the farm. This method is also much less likely to produce problems when applying patches, updates or even upgrades.


SharePoint Success without Customizations?

While I believe strongly that there is a lot of value in the base solution, I think that SharePoint is set apart by the expandability and integration options. This is what can take it from an ad-hoc workgroup solution to an enterprise platform.

Too many IT shops have taken a No Customization stance when it comes to Enterprise Software. They will quote ballooning implementation costs, reliability of the changes or the difficulty that exists in performing normal version upgrades. Many of these are valid issues to some degree with packaged software, but it is not an irrefutable law. SharePoint is a platform that is intended to be molded to meet an organization’s needs, and customizing it is not the same as rewriting core sections of an ERP system.

In more than on instance I’ve seen SharePoint workflow projects move forward with the decision that no “code” can be written, which means they cannot use Visual Studio or create custom actions. The alternative is for them to use SharePoint Designer to create those workflows. While that may be a good idea for small or simple workflows, there are limitations, but even worse there is no reusability in their work. If something similar is needed somewhere else it has to be recreated.

By making a unilateral decision that no customizations can be made, you are handicapping the system and limiting the value it can deliver. Business and IT leaders need to consider this before making any policy changes.

What about Change Control?
In organizations where there is a Change Control policy in place, it is important to categorize the types of changes. I would advocate grouping changes into the following groups Content and Site Configuration, Packaged Code, and System Level Changes.
Content and Site Configuration – This includes using the toolset to add and update content in lists and libraries along with the creation and design of Sites, Lists, and Libraries. These tasks should not require approval.

Packaged Code – This includes the installation of custom or third party web parts, solutions, workflow actions and templates. Since these packages can possibly cause harm, and should be part of the system’s documentation, it should pass through the Change Control process.

System Level Changes – This includes adding an additional server to the farm, changing a servers’ role, reconfiguring personalization features or rebuilding the Shared Service Provider. These changes can possibly have a huge impact on the entire system. It is important to capture the details of those changes in the documentation, and also make sure that all stakeholders are aware of the changes being made.

Advantages of BPM/Workflow and Selection Criteria

Advantages of Business Process Management or Workflow
There are countless advantages to using BPM / Workflow, but here is a list of the most immediate advantages:

* Reduce Cycle Times
* Better Process Visibility
* Increased Accountability
* Smoother task orchestration and hand offs
* Process Standardization
* SOX Compliance


What processes should be selected?

There are many ways to select a process improvement project. First and foremost you need to select a process that is clearly defined and repeatable. If you have to build support for ambiguity and exceptions you will be left with a process that is difficult to use and maintain which will likely lead to a failed adoption. Another consideration is to select a process that uses people to rout and keep track of where a process is at. That orchestration can be difficult to maintain manually and normally does not give the other participants visibility in the current state of an individual request.

I then look for processes that are regulated such as purchase requests, common financial transactions, or IT account provisioning.

You can measure it using traditional Return on Investment (ROI) models, or you can take a more holistic approach and select your projects based on a broad range of criteria including Business Objectives, User Adaptability, and Technology Capabilities. While ROI is very important I think it can be misleading with BPM projects because it fails to include many of the soft return values for things like Process Visibility, Accountability, and less human bottlenecks in the process orchestration.

Planning for Separate Site Collections

When planning out the site structure of a new SharePoint system, here are five things I take into consideration. Taking these into account during your planning phase will hopefully reduce the amount of rework needed as your system evolves.

Amount of data

If you are expecting a large data set, perhaps you are scanning all supplier invoices and using SharePoint for Content Management, its important to consider the size of a Site Collection and the underlying Content Database from an Administration standpoint. Larger Site Collections and Content DBs require more care and attention along with a more advanced skill set. There have been a number of discussions on what the guidelines are, but I aim to keep Content DBs under 40Gb unless there is a real exception. In this case, the size of the data over rules any of the other answers.

For site collections I expect to grow large, I set them up in a dedicated Content DB right from the start. This saves the trouble having to move it to a different content DB later which can take some time with large sites.

Type and Purpose of the Sites

In a small to mid-sized organization I typically treat sites that support Intranet or department level collaboration a little different than cross-functional or project type sites. Its easy to define the groups around the functional areas and you can reuse those groups in other sites where there is overlap.

In larger organizations sites typically require more isolation. There may be a some interaction between the groups, but not within divisions. In this case the Site collections can be structured to support the organizational boundaries.

Groups Definition and Membership

Groups are defined within the site collection container. If you setup a group called “Management” in Site Collection A, it wouldn’t be available to Site Collection B unless its setup separately. It may not sound like a big deal, but it gets very tedious when you have to manage the same group in multiple places. To make matters worse administrators often take for granted who is in the group based on the name. When setting Site Permissions a group’s members is not directly visible.


Navigation

WSS and MOSS have some good out of the box navigation systems. They are limited though when it comes to trying to tie together multiple Site Collections. There are solutions like defining custom providers but then you are introducing sophisticated customizations that not every company can support. A last ditch option is to manually link to sites and resources but then everything becomes much more difficult to manage.

If it is important to have a consistent horizontal navigation scheme, look to keep as much as possible within a limited number of site collections.

Aggregating or Reusing Data

One of SharePoint’s greatest values is in its ability to support syndication and aggregation of content to deliver it where the users need it. You can aggregate the content using tools like the Content Query Web Part or DataViews. These techniques get a little more complicated when content is in different site collections. Custom code or third party tools are then required to accomplish bring things together.

Feedback?
Agree? Disagree? Let me know, I would love to hear your feedback.

SharePoint Requirements

Defining requirements for a SharePoint related project is a very important exercise. Seemingly small changes to the requirements can mean the difference between one with a low level of effort and one with a lot of customization and coding required. Project sponsors new to the platform may also have misconceptions about what can be done, or at least what can be done easily.

Paul Galvin recently posted his presentation from the SharePoint Best Practices session on Defining “Great” SharePoint Requirements.

Anyone with plans for future projects or implementations should check this out.

%d bloggers like this: