This article can also be found in the Premium Editorial Download "SharePoint Insider: Who is allowed to customize SharePoint?."
Download it now to read this article plus other related content.
SharePoint is a highly customizable platform. You can click on site actions -> edit page and
actually edit the page. You can add Web parts, configure them and drag them around from zone to
zone. It’s easy to download SharePoint Designer and figure out how to make dramatic changes to
SharePoint’s branding by clicking, pointing, dragging and saving. It’s quite a liberating feeling,
and it doesn’t stop there.
SharePoint can be customized in all kinds of ways before it ever occurs to you to do things the old fashioned way—through code.
Proceed with caution, however. The SharePoint platform is open and invites customization, but it’s still a software product. Careless customization can lead to poor design, unhappy users and performance problems. It can even wreck your system entirely, forcing you to test that disaster recovery plan you hoped you’d never have to pull out from the closet.
You can avoid those kinds of nightmare scenarios with an appropriate governance plan that includes rules for customization. Follow these tips, and you’ll get the best of both worlds —a highly customized SharePoint solution tailored to your company’s business needs that is also stable and efficient for your user community.
Defining roles for customization
When you first consider SharePoint customization and governing activities relating to customization, you need to establish a handful of roles. These include:
- Casual users: These people use SharePoint infrequently or have little or no interest in making system changes. They want their search function to work well but are interested only in results, not changing how the system operates.
- Power users: These are the high volume users who also tend to be the best internal evangelists for SharePoint. These users are not programmers—otherwise, they would be part of the IT department—but they are keenly interested in business processes and issues and always look for ways to improve them using SharePoint.
- Site administrators: Frequently power users, they are also explicitly “in charge” of one or more SharePoint sites.
- Developers: These are the ones who live in the mysterious world of SharePoint CAML files.
Casual users should rarely make any SharePoint customizations at all. They won’t have the training to make sensible changes to the environment and will ultimately be a drain on IT resources.
Power users, however, should be encouraged to learn about SharePoint’s customization opportunities and should be trained on their proper use. Power users are close to the action. Combine their interest in business process with a training program that enables them to solve business problems, and your SharePoint environment will grow in a good way.
Site administrators should expect to do the bulk of the customization work for a site and be the first line of support for a given site’s audience.
Despite SharePoint’s enormous flexibility, many business requirements cannot be met without programming. Although SharePoint places lots of customization power in the hands of end users, programming tasks should be undertaken only by developers.
Common customizations with SharePoint
For many companies, document libraries and custom lists provide backbone functionality upon which their entire SharePoint implementations rest. At the same time, it’s quite easy to customize them through views.
SharePoint has two types of views: personal and public. Public views should normally be created by power users or site administrators. Depending on the efficacy of a company’s SharePoint training program, developers may also need to create public views. Casual users should not create public views.
Personal views, on the other hand, should be open to everyone. Keep in mind, however, that personal views cannot be “promoted” to a public view.
Using SharePoint Designer, users can re-brand their entire SharePoint environment, individual sites or even individual Web pages by creating new cascading style sheets. Branding can become complex very quickly and, as a result, should normally be managed via a strict development process and carried out by developers. However, a properly trained power user or site administrator can make branding changes. This would normally be an exception to the rule.
Developers should be available to assist as needed. It’s possible to accidentally bring down an entire SharePoint environment, leading to lost time and a mad scramble to restore it from backup.
Last but not least, training is vitally important and should be tightly integrated into any SharePoint governance plan. This is especially true as it relates to SharePoint customization.
It’s important to balance the power that SharePoint’s tools put into the hands of end users while avoiding risks that arise from that very same thing. If you take the tools away altogether, then you reduce risk and the support requirements associated with user customization.
The downside of taking away customization is that you won’t unleash the power of those users. This sad outcome will mean longer development times and useful projects that never get off the ground, leaving inefficient business processes intact that can be a permanent drag on your company.
As with many SharePoint governance issues, striking the right balance is essential. The trick is to weigh the benefit from end users doing their own customization work with SharePoint tools versus the effort IT will have to give to support them. Each enterprise will calculate that particular equation in its own unique way.
About the Author
Paul Galvin is a Microsoft SharePoint MVP and a SharePoint solutions architect at EMC Corp. Galvin has worked in the IT industry for more than 15 years in areas such as software development, consulting and SharePoint solutions design, where he works with clients to create business solutions using the SharePoint platform. He contributes to the SharePoint community through MSDN forums and his blog at http://paulgalvin.spaces.live.com.
This was first published in February 2009