HOT TOPICS: Customer Experience Marketing Automation Social Business SharePoint 2013 Document Management Big Data Mobile DAM

SharePoint Collaboration: Build So They Will Come

In the last post, I talked about the if we build it, they will come mentality, i.e., give people something, anything, to use, and they’ll use it. After all, they have no dedicated tool now to use for collaboration, so whatever we give them will be better than nothing, right? 

As I discussed there, adopting the if we build it approach to SharePoint is the number one reason I see out in the field for implementation failure — users will always avoid a solution that’s simply better than nothing and fall back on the ways they work today, turning your SharePoint collaboration environment into shelf-ware overnight.

What I want to do in this post is to walk through some ways to avoid the if we build it mentality and better tailor your SharePoint implementation to the people who matter the most — the end users.

There are four broad activity areas you need to focus on to not only understand your end-users’ needs, but have a fighting chance of meeting them as well:

  • User Segmentation
  • Use Case Analysis
  • Technology Mapping
  • Training and Communication

1. User Segmentation

At its heart, user segmentation analysis is about understanding who your users are, exactly. It should be a key part of any technology initiative, not just a SharePoint collaboration project, because ultimately you can’t deliver a suitable technology solution without knowing whose problem you’re trying to solve.

In my experience, all organizations have at least a rough user segmentation in place already, e.g., knowledge workers versus process workers, home office versus field reps, shared services versus line of business — organizations typically have a variety of ways they conceptualize the different kinds of folks who work there.

To be useful in the design of a SharePoint collaboration environment, however, a user segmentation analysis needs to deepen and expand upon these existing categories of users, giving them more nuance, detail and accuracy.

For example, the distinction between home office and field reps: are all field reps the same, or are there important differences between managers and line level reps? Are there a variety of roles within the home office that need to be considered — managers versus line level employees, functional area? Are there any important similarities between home office and field reps that need to be kept in mind?

2. Use Case Analysis

Once you get a list of user types relevant to the use of SharePoint as a collaboration platform, you can’t stop there, because you need to determine what they’ll be doing with the SharePoint capabilities you’re planning to give them.

Using the language of application development, we’re really talking about identifying business level use cases — i.e., the scenarios or activities that each user type will engage in using the new technology.
In terms of the home office versus field reps example, for SharePoint collaboration capabilities, they might look something like this:

User Type: Field Rep — Manager

  • Use Case 1: collaborating on performance reviews
  • Use Case 2: participating in projects as team member
  • Use Case 3: contributing to knowledge base

User Type: Field Rep — Project Manager

  • Use Case 1: collaborating on group deliverables
  • Use Case 2: managing team projects
  • Use Case 3: accessing knowledge base

3. Technology Mapping

At this point, you’ve got your users segmented (i.e., you know who your users are) and you’ve got your core use cases lined up (i.e., you have an idea of what they’re going to do with SharePoint). All that remains now is to begin to sketch out how they’re going to do it by mapping SharePoint capabilities to your use cases.

For all you SDLC-heads out there, this isn’t the place for detailed architecture and system-level design (these will happen during implementation), but rather for decisions about what capabilities will be required to support the use cases you’ve identified.

The best way to link SharePoint capabilities to use cases is to create a matrix that indicates what capabilities are required by each use case.

Shepley - SharePoint Collaboration - Build it so they will come - Figures.jpg

When you’re done, a matrix like this one will give you a clearer idea of which SharePoint capabilities you need to support the things your core user segments will likely be doing with the system — and perhaps as importantly, it will also tell you what capabilities you don’t need, which allows you to avoid implementing more than your users need.

 

Continue reading this article:

 
 
 
Useful article?
  Email It      

Tags: , , ,
 
 

Resources

 

Featured Events  View All Events | Add Your Event | feed Events RSS