Mark Morrell, in a blog post called How to make SharePoint 2010 a success?, writes:

“Like most organisations at the moment, BT is looking at what SharePoint 2010 has to offer and how it could meet our business needs.

I really want to find out what kinds of frameworks organisations are putting in place to harness the full capabilities of SP 2010, whilst embedding best practice and policy compliance.

Any ideas anyone?“

Here’s my answer … in blog format … not in book format. And yes, a book really has to be written to answer Mark’s question, but I can’t do that before leaving the office in 30 minutes.

First, I’d query the phrase about “harness[ing] the full capabilities of SP 2010.” Any technology, and SharePoint 2010 is no exception, provides an opportunity to do things in a new / different / revamped way. So one of the first tasks that I do in examining a new or updated technology is to find out exactly what it does do. How does it work? What are its main features and capabilities? Etc …

Once that is understood, in the context of a specific client, I would look at where those capabilities could be used. This could be in the sense of “we are carrying out X process in a certain way today; it has a Y cost profile and uses these other technologies. Here’s what we like and dislike about what is happening today.”

An alternative is the scenario-led planning approach that I wrote about in Messaging News some years back (see Investing in Collaboration Tools, February 2008). The core of this alternative approach is summed is these two paragraphs:

“Taking this approach is called scenario planning. This is done by first interviewing the key user groups in the business to understand what they do. Then combine that analysis with an understanding of the new tools available for doing that work in a different way. This allows for some estimation about the benefits of working in the new way, as well as the costs of changed work practices to the people involved.

One of the key mindsets in choosing a collaborative tool is to find something that is flexible enough to deal with a wide range of end-user scenarios. By creating a new platform of commonality in tool availability and usage, things that work in one department can then be carried over and used in other departments. Put another way, skills picked up in one setting, apply to other settings. If the technology is too tightly focused on one or two use cases, then people will have to learn to adopt a multitude of tools, which is not going to happen. It also makes the movement and correlation of data between systems difficult, which makes the environment more complex.“

Once your scenarios for doing things differently are understood, you can then look at the technology to support collaboration, and the new capabilities of SharePoint 2010 may provide a good set for doing so.

So … to recap … (1) I would ask / explore / examine / experiment with what’s new in SharePoint 2010, so as to understand the technical capabilities, and then (2) I would explore where and how those could be used within the specific client organization. In Mark’s situation at BT, perhaps (and I’m making this up for BT, okay):

• They find that the search capabilities of SharePoint 2010 are much better than what they have today.
• They discover that the Intranet publishing model is much more suited to delegated Intranet creation / maintenance than the tools they have today.
• Engineers are still emailing attachments around when working on documents, resulting in document chaos. The new Word 2010 co-authoring capabilities provides a significant opportunity to revamp the way work gets done.
• … and so on …

Now to the “embedding best practices and policy compliance” part of Mark’s question.

Best practices are a misnomer for SharePoint and similar technology, in my view. “Good practice,” yes, “best practice,” iffy. See Paul Culmsee’s CleverWorkarounds blog for more on this. Thus on the “good practice” topic, for me this becomes a governance strategy. That is, what decisions are made on how to steer the technology of SharePoint for business success. There are topics like these in the “good practice” / “governance” area:

• Who can create a team site, under what conditions, and with what approval approach? I wrote the report on that question.
• What happens to sites at the end of a project / document / meeting series? I’m working on the report on that question.
• What happens about templates for creating sites? There is some stuff in Seamless Teamwork about this, but I will write a fuller report on this at some stage.
• What happens about third-party products? See SharePoint Roadmap chapter 3 for more on this.
• Who is responsible for what parts of SharePoint and its use within the organization? The roles and responsibilities question … more to come from me on this. If you ask nicely though, Sue Hanley may send you a PDF on this topic.
• … and so on …

Finally, to the “policy compliance” things. This is called “end-to-end business information architecture,” will have to include a deep discussion on records management (capture, retention, disposition, and more), will require examination of whether SharePoint is “enough” by itself or is part of / an element of the overall strategy … and then what you do at the end of that. For an organization the size of BT, give me a year onsite … and we can have an answer. It’s not a 5 minute discussion.

Actually, my second book, SharePoint Roadmap for Collaboration, talks through these different stages for applying the collaboration aspects of SharePoint – especially technology analysis (chapter 3), and governance strategy / decision process / structure / themes (chapter 4). For good measure there are a couple of other key chapters on engagement (chapter 5) and user adoption (chapter 6). You can take the same approach to the other areas too. On the user adoption question though, you’ve just got to check out my book #3, User Adoption Strategies.

So … Mark … there’s what I’d suggest / recommend / practice. I’m in London in October … let me know if you’d like me to come around for a week 🙂