In my last post, I spent some time giving advice on how to get SharePoint right the first time at your organization. In this post, I want to roll up my sleeves and dig in to the details on how to get SharePoint right the first time and step you all through the kinds of activities you need to do to adhere to the six things we discussed in the last post.
To be successful with SharePoint the first time, you need to address the following mix of strategic and tactical concerns.
- Raise awareness that SharePoint is an enterprise platform requiring enterprise governance
- Create a cross-functional governance body
- User segmentation
- Use case development
- Process mapping
- Capabilities mapping
- Training and communication
Some of these I’ve written about at length elsewhere, some will be net new. But by pulling them into one post, I hope to provide you all with a practical guide to what you’re getting into if you’re committed to being successful with SharePoint.
Let's dig in to each of these in more detail.
1. Raise awareness that SharePoint is an enterprise platform requiring enterprise governance
This one is the foundation for getting SharePoint right at an organization -- without it, you might as well pack up and go home. I haven't seen a large-scale SharePoint implementation be successful over the long haul that wasn't approached as an enterprise platform with enterprise governance needs.
Unfortunately, there's no easy way to do this, because how you go about making it happen will depend largely on the culture of your organization, and the culture of each organization is different.
At some organizations, a top down approach is the way to go, so you’ll have to gain support from executives with a stake in SharePoint's success before socializing the effort out to the organization. At other organizations, executives won't get fully behind an initiative until they see some evidence of broad based support for it, so you’ll need to build support from the ground up.
However, all things being equal, I find that beginning from a grass roots effort works best at most organizations. If you can get a base of support from key stakeholders, it makes it much more likely that the executives you need on board will agree to support you. It also gives you a chance to vet your ideas with folks before you air them in front of your execs.
2. Create a cross-functional governance body
This one is related to the first -- so much so that I often tackle them at the same time. I find that they tend to work together to generate the support needed for SharePoint to be treated as an enterprise platform, with all the governance that it requires.
In almost all cases, this is a grass roots effort. I can count on one hand the number of times that I've seen an organization birth one of these cross-functional bodies fully formed by executive fiat.
More typical is for the body to form from the ground up, out of a group of concerned stakeholders, all of whom have a vested interest in SharePoint succeeding at the organization.
No matter how it forms, however, such a governance body needs a couple of things to be successful.
- IT, compliance, and line-of-business participation. Having coverage from all three is critical to making this governance body truly cross-functional. It allows the body to balance business operational concerns, IT operational concerns and the legal requirements of the organization when structuring the SharePoint implementation.
- Influence or authority (or both). Depending on whether you took a top-down or bottom-up approach to building the governance body, you'll likely start with a certain amount of one or the other...although don't underestimate the importance of both to your success or the difficulty of acquiring them.
3. User segmentation
At this point, we take a tactical turn and broach the first of the implementation focused activities you need to accomplish to make SharePoint a success at your organization: user segmentation.
I've written quite a bit about this elsewhere, so I’ll skim the surface a bit here (readers who are interested in a deeper dive can read more here). But at its most basic, user segmentation is about grouping your users into high-level buckets so you can efficiently address their needs. Done right, it allows you to avoid tackling user needs en masse in a one size fits all way or catch as catch can in an ad hoc way.
Most organizations already have an organic segmentation in place: front office, back office, field reps, home office, line employees and so on. A more formal user segmentation exercise simply builds on these categories, giving them specificity, rigor and precision.
For your typical SharePoint implementation, you want to begin by examining the total universe of expected users, which may be everyone at the organization or a smaller subset. In either case, you take this superset and slice and dice it to arrive at a collection of user types that represent the range of folks who you’ll need to support with SharePoint.
4. Use case development
Once you have your user segments, you then turn to use case development, i.e., what business activities is SharePoint going to be expected to enable/support?
Like user segmentation, this is one I’ve written a lot about, so I’ll just address it at a high level here (those of you who want to dig in deeper can click here).
Basically, beginning with the user segments you identified in the last step, identify the activities, jobs or tasks that each will need to do with SharePoint. Some of these will be unique to a given user segment, but the vast majority of them will likely be shared across more than one user group. In either case, it’s important to make sure that you haven’t got duplication of use cases on the one hand, or missed use cases on the other.
At this point, you’ll likely have more use cases than you can reasonably support given your resources and timelines -- so you need to perform triage to determine which use cases you’ll include in your first phase of development.
I normally use the following list of criteria for triaging what use cases to include in a SharePoint deployment:
- Is the process document centric?
- Does the process primarily involve unstructured content or structured data?
- Is there a high degree of integration with other systems?
- Will the successful migration of this use case to SharePoint contribute to our critical success factors (CSFs)?
The first three are pretty self-explanatory: the more document-centric a process is, the more it involves unstructured content rather than structured data, and the less it integrates with other systems, the better “fit” it is in general for a SharePoint implementation.
The last criteria depends entirely on your context: is IT under pressure for wide adoption? For shutting down shared drives as quickly as possible? Or is user satisfaction the key? Or is reduction in email traffic the goal? Maybe some combination of some or all of these?
No matter what your CSFs are, you want to make sure that the use cases you select to include in your SharePoint implementation will contribute positively to them.
6. Process mapping
Once you have the use cases that make the cut according to your triage criteria, you can drill down and begin getting the information you need to enable/support them in SharePoint.
There are many effective methodologies for gathering requirements and lots of folks out there who understand them far better than I do -- so I’ll leave this to the experts and avoid making this a treatise about requirements gathering.
Instead, I want to walk through a technique that I’ve found useful for gathering some key information about business processes, information that can easily get missed (or turn into a science project) during typical requirements gathering for SharePoint: document types and metadata.
It goes something like this:
- You step through each use case at a high level, staying out of the click here, click there weeds and focus instead on the basic, high-level steps that make up the process.
- For each step, ask your users to detail what documents feed into the step, what documents are created or manipulated in it, and what documents are its output.
- For each document, you want to capture some key information:
- Document name
- File format (e.g., .doc, .ppt, .xls, .pdf, etc.)
- Repository it lives in
- Metadata used to store or retrieve it
- Comments or things to note
What results is a high-level process map as well as a spreadsheet that captures the core document types and metadata required for this use case.
When replicated across all your in-scope use cases, what emerges is a clear picture of the documents you’ll need to manage in SharePoint along with the metadata your users rely on to store and retrieve their content.
7. Capabilities mapping
The remaining step is to determine what SharePoint capabilities will be required to support/enable your in-scope use cases. This can best be accomplished with a capabilities mapping exercise.
I written about this at length elsewhere, so if you’re interested, you can read more here. But at a high level, capabilities mapping involves plotting each use case against the capabilities required to deliver it, typically done using a matrix like the one shown in Figure 1.
Figure 1 – Example of a Capabilities Mapping Matrix
As you can see from the figure, the capabilities required for each use case are laid out, with some indication of level of need for each capability.
As with the process exercise of the last section, this one is not meant to replace your core requirements gathering processes, but to augment them, filling gaps where you might miss things particular to SharePoint.
In this case, the capabilities mapping matrix gives your development team a heads up on what parts of the SharePoint stack will be needed…and not needed. This helps you avoid functional overkill, where IT simply delivers everything SharePoint offers to end users. Of course, functional overkill is much easier for IT (and spares them the hard work of figuring out what users do and don’t need), but disastrous for end users, who quickly find themselves drowning in features they don’t want or need.
8. Training and communication
Ah, that rarest of beasts: training and communication for a SharePoint rollout!
It seems like just about every organization I come across has horror stories about rolling out SharePoint with little to no training or communication: timelines and budgets get crunched, leadership falls prey to the “SharePoint is an Office product just like Word” delusion, and end users are dropped into SharePoint with little more than a PowerPoint or online tutorial to help them manage the transition off email, shared drives and hard drives into this new enterprise tool.
I won’t belabor the point that this is a horrible worst practice -- I’m sure you’ve all been through what results when IT skimps on training and communication. Instead, I’ll point out that the user segmentation, use case identification and process/capability mapping exercises I’ve presented here make training and communication much easier and increase the chance of their overall effectiveness.
After all, it’s much easier to design effective training and communication if you know who you’re training, what they’re going to be doing, how they’re going to do it and with what capabilities in SharePoint. This knowledge lets you avoid a broad brush approach (where you try to train folks on everything SharePoint has to offer) and instead targets your efforts on the aspects of the SharePoint stack that are most relevant to your end users.
The Final Word
So there you have it: my best shot at laying out what I’ve seen work out in the field for getting SharePoint right the first time. Although this has been a long post, there’s a lot more to say, so I encourage those of you who’re interested to track down more detailed resources on these topics, because there’s lots available.
In the meantime, I’d love to hear from folks out there about my approach to SharePoint, your own experiences and anything else that might be on your mind -- jump in and let’s get the conversation started!