I am in the process of reading the Microsoft Press book by Ben Curry and Bill English, Microsoft Office SharePoint Server 2007: Best Practices. While there are numerous books on the market explaining how to technically carry out a SharePoint implementation, this book does a great of summarizing the various business and project management issues surrounding the construction of a good SharePoint solution.

When SharePoint 2007 was first released in Beta 1, customers immediately began looking for ways to implement the product. Now that many companies have used the product for several years, we’re seeing the fall-out from poorly-designed solutions, such as:

  • Out of control database growth, because proper quotas weren’t applied, and site collections weren’t distributed among content databases.
  • Poor-performing applications because non-trained end-uses were granted access to SharePoint Designer, and decided to do things like put massive list-view web parts on site homepages, etc.
  • Lists that take minutes to display because users have put over 2000 items in it, rather than breaking the list items up into folders, or into multiple lists.
  • Publishing layouts, master pages, style sheets, etc. that can’t be easily updated in various site collections because the solutions were built using SharePoint Designer instead of using a SharePoint Feature.
  • Sites that aren’t adopted because end-users weren’t consulted on what they wanted in a SharePoint site. Or, in reverse, sites that have a million and one subsites, because non-trained users were given administrative rights.

The list goes on and on. These are just a few examples I’ve actually seen at customers’ sites over the last three years. When it comes down to it, many of these problems are not technical ones (although the symptoms may be technical, such as poor performance.) I find that in most of the companies I walk into, the issues have arisen because of a lack of planning and a lack of training. Each of the items listed above are totally avoidable, if the right questions are asked ahead of time, and everyone, from the site administrator to the SharePoint developer to the end user is trained. Even “ad hoc” content can be planned, if it means planning for unstructured growth.

This book is a great resource for folks who have spent most of their time learning about the technical aspects of SharePoint, but want to learn more about what it takes to plan a successful SharePoint solution based on the people involved, (without leaving out how the technology itself plays into the solution.) This book helps new SharePoint consultants know the good questions to ask when planning a solution. I highly recommend it to anyone planning on spearheading a new SharePoint implementation.