Is the world destined to be littered with a whole mess of ill-fitting, barely usable SharePoint 2010 sites in a couple of years?

In the context of the SharePoint ecosphere and the thousands of talented and eager professionals who call it home, I'm a relative newbie. But after about two years and two major SharePoint engagements (one on SP 2007, one on SP 2010), I feel like I've developed a good handle on its feature set, its potential as an enterprise collaboration platform, and the business challenges that SharePoint aims to solve... as well as those it presents. The steps to answer the questions that SharePoint raises are where I think I'm seeing a gap.

For an enterprise-scale SharePoint deployment, what I've come to know in the last decade as "information architecture" takes on a whole new meeting. Designers are challenged not just to organize a fixed set of content for presentation on the web, but to first define a scalable structure and strategy for the network of sites that will comprise the SharePoint farm, and then to figure out how content should be organized and navigation should work within each site, optimizing for each site's unique mix of content and functions, but taking care to ensure some level of consistency across sites so as to maximize usability, all while recognizing that the sites' content will be inherently dynamic and subject to user-governed organizational decisions. (Apologies for the symbolically long sentence.) IA for SharePoint applies the same concepts and fulfills the same underlying objectives as "typical" IA. But a really good SharePoint information architecture requires SharePoint expertise to a degree that, in my view, far exceeds the product-specific knowledge required by most portal products and certainly the average WCM.

Further, before it's ready to start defining an information architecture - a task which will never truly be finished for a successful SP deployment - the organization must identify the functions to be provided to each audience. Some of those functions will be out-of-the-box; others will require customization. Good old fashioned requirements, but tailored to SharePoint. Which web parts do users need? Do we want to use the Content Organizer? Do the out-of-the-box workflows suffice, or is a custom process in order? Performing a fully abstract, technology-agnostic requirements gathering process prior to implementing SharePoint has its advantages, but the reality is that SharePoint requires a lot of unique questions to be answered in order to realize its full potential and maximize efficiency during the delivery phase. As such, business analysts with SharePoint knowledge are key players.

On to my point... shouldn't there be a Microsoft-sanctioned certification and associated training plan for non-technical resources who need to learn how to lead SharePoint requirements and design activities? Doing so is a distinct job that requires distinct skills and knowledge, far different from knowing where to find the right radio button or how to develop a custom web part after the feature has been defined/designed. And the same types of people aren't necessarily drawn to all of those different pursuits, so even if a certified SP developer knows what questions need to be answered, they may not be well-suited or inclined to lead the process of gathering those answers.

As far as I can tell, existing MS training and certs span Sales, Configuration, Development, and Administration. There's a pivotal step in the solution's life cycle missing: the part about defining what SharePoint should be configured to do and what needs to be developed. Resources addressing this gap do exist - I'm currently reading this excellent book, and others are out there, including pay-to-play training alternatives - but the absence of such a track from MS and the fact that SharePoint sales have accelerated so greatly (almost assuredly outpacing the growth rate of genuinely skilled/knowledgeable resources) suggest to me that there are a lot of projects out there which are at high risk of long-term failure.

I'm wondering how many sites are being "designed" by smart people who are trying really hard, but who fundamentally don't know what they're doing, through no fault of their own, but because of this talent and training gap. This risk seems especially high given the roll-your-own, ungoverned legacy of SharePoint in many organizations, which has led to a misguided perception that enterprise-class SharePoint deployments generally don't require the same level of design rigor that other sites or portals do. Cases where a SharePoint free-for-all is the right approach certainly exist, and excessive governance can hinder adoption and reduce efficiency gains; however, cross-functional, sophisticated SP deployments demand a thorough requirements definition phase, a well-designed information architecture, a sound and scalable navigation paradigm, and a comprehensive user experience strategy.

So, in short, my conclusions are:

  • MS's formal certification track and training is missing a key piece: SharePoint requirements and design.
  • Learning resources to fill that gap exist, but are disproportionately few in number, relatively difficult to find, and may vary in quailty.
  • The complexity and challenge of SharePoint-oriented requirements and design actvities are not fully recognized, in part due to the nature of the product and in part due to the absence of formal training/certification.
  • In the long-term, enterprise-scale SharePoint deployments may suffer as a result of these factors.

Am I missing something? Does the corporate world know what it's doing with SharePoint 2010 better than I think?