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.
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.
4. Training and Communication
Last but not least comes training and communication -- although you wouldn’t know it based on the typical implementation! In my experience, training and communication are not only tackled way too late in most projects (they should be addressed as early on as you can manage them), they’re also pretty much the first things to be cut when timelines get squeezed.
In terms of a SharePoint collaboration implementation however, skimping on training and communication will likely have serious negative consequences. SharePoint’s familiar UI/UX lulls us into a false sense of security… because it looks like a combination of an Office product and Windows Explorer we think that it should be easy to use. And it is, but there are important capabilities that aren’t self-explanatory (versioning, working with links, column settings, etc.), and if your users don’t get the hang of these, they’ll either get less value from SharePoint or use it in ways that reduce its value for the organization (or both).
And while the training and communication needs of each organization will be different, the user segmentation, use case identification and capabilities mapping will be the foundation for identifying what training you need to offer each user type, as well as what kinds of communication are needed.
The Final Word
Although it’ll take a lot of work to put these four principles into action, this overview gives you a good idea of what you face as you try to go beyond the if we build it mentality to understand how to build it so they will come. I’d love to hear from folks in the trenches out there about their own efforts to deploy SharePoint collaboration environments that meet end user needs -- jump in and let’s get the conversation started!
Editor's Note: Additional articles on Enterprise Collaboration include:
- How to Spot a Collaboration Project in Trouble
- Enterprise Collaboration Requires Critical New Skills
- Collaboration Opportunities and Challenges for the Mobile Workforce