SharePoint 2007 has done what no other enterprise content management product has ever done, experiencing unprecedented growth through broad user adoption and unbridled support from IT and executive management.

And in that vein, SharePoint may become the victim of its own success: There are no clearly defined standards and best practices for designing and deploying SharePoint in a cohesive manner. This is not to say that expertise does not exist and that people don’t have opinions and valid experiences. But let’s get real -- the product was only shipped in November 2006, and organizations can get rather desperate as they search for balanced and practiced governance standards.

In their absence, SharePoint is prone to poorly coordinated efforts with little cohesion across an enterprise. So until governance standards are established, chaos may reign. To minimize or circumvent the business and technical challenges that may arise, here are some pointers gleaned from early adopters.

Think big, but start small
Too often, organizations look to invest a lot of time into establishing standards prior to working with the technology and users of the technology. Instead of investing heavily into governance standards prior to implementing SharePoint, select a small number (fewer than five) of controlled projects and implement them in a coordinated capacity. Once your team has developed a reasonable baseline of knowledge, governance standards can be established for future deployments. Key point: Those first few should be iterative in nature, and the business units that elect to participate should have thick skin as you go through multiple iterations.

You'll need dedicated resources
Think of SharePoint as a tool that will ultimately demand more attention than email. Why? Because it provides a richer feature set and will be used in more creative and diverse ways than email. Consequently, dedicated staff -- maybe fulltime, maybe part time -- is necessary, be they internal team members, outsourced personnel, or a combination.

Be clear about who does what
SharePoint can be easily installed and configured (but not optimally) by both business people and technologists. So it's important to define roles, responsibilities, and boundaries for the distinct groups engaged with SharePoint. For large companies, this means definitions for the global IT teams, regional IT teams, and business liaisons (or other segmented groups of participants). As a case in point, Erin Luby, SharePoint team leader at Liberty Insurance Underwriters (a subsidiary of Liberty Mutual Insurance) identifies designated people as “Content Contributors” within each business unit. Their job is to serve as shepherds of content and also as liaisons to IT for SharePoint. This has worked reasonably well; however, LIU is now in the process of establishing specific boundaries for each of its groups as they relate to roles and responsibilities.

Regardless of how the groups are segmented, clear roles and responsibilities must be defined to minimize overlap and avoid frustrations and alienation amongst the community. While the IT roles are more commonly known (architects, developers, configuration specialists), there is a clear need for the SharePoint liaisons, business analysts, and project managers. It is also advised by many to establish a committee or cross-functional team that meets regularly to review what is and is not working for SharePoint. This group should work closely with the IT team supporting SharePoint.

Maker good use (and re-use) of templates
SharePoint allows for a variety of objects to be saved as templates. These include most list types as well as sites. When templates are employed, users can easily create new lists or sites based upon an established template. It is important to note that content can be stored with templates, and caution should be observed when performing customizations to any sites/lists that ultimately serve as templates. If this takes place, SharePoint has a very definitive approach for deploying customizations through the use of SharePoint features.

Standards should be documented, monitored, and adaptable
As SharePoint is a veritable Swiss Army Knife of functionality, infrastructure standards (scaling, disaster recovery, sizing, performance optimization) should be established specific to your organization. Such standards will require ongoing attention and adjustments, since organizations use SharePoint very differently. In some cases, there may be a large number of lightly used sites. In other cases, a few sites may be configured; however, the usage may be very intense. And of course, there are the "tweeners"! So, fitting your standards to your organization’s requirements is key and these standards should be regularly monitored and always evolving.

Take advantage of third-party developers
SharePoint's popularity has spawned a thriving, third-party ecosystem. And the members of this fast-changing ecosystem fill important gaps within the SharePoint platform. For example, when it comes to imaging, KnowledgeLake is a key partner; for site backup/recovery, look to AvePoint; and for workflow, K2. Identify your functionality gaps with SharePoint, then consider third-party product roadmaps as you plan out your SharePoint standards.

After all that, there are still a few other factors to consider, including who decides which SharePoint projects get funded, or how the enterprise perspective is maintained in that process. Would-be users may also bump up against whether to support multiple initiatives or capabilities, and how to identify and authorize such projects.

That's a small sampling of standards and best practices. Got others to share? Chime in on the message board below, or email us your SharePoint tip or best practice.

— Russ Edelman, President and CEO, Corridor Consulting

This blog is part of Internet Evolution’s IT Clan, which addresses the continuing impact of the Internet on enterprise networks, applications, and management. Register here to join the IT Clan’s conversation, and you just might win something unspeakably cool.