Migrating a Corporate Intranet to SharePoint
Jen has been a web developer, technical writer, and interaction designer / usability professional at both large and small organizations. She has an M.S. in Human Factors from Bentley University, and currently works at The MathWorks, where she manages a team that focuses on improving the usability of both custom-built and procured business software.
Before 2008, Sharepoint was a tool I had to use during a short stint at a very large company a few years prior, and a distant memory. Then my current employer decided that we should evaluate SharePoint 2007, and soon after, that our Intranet be "migrated" to SharePoint. Since I worked solely on Intranet applications, this project became a large part of my day-to-day life as a Usability Specialist.
As I've worked with our SharePoint Implementation team and people from different departments, I've struggled with many things, and hopefully learned a few things too. This article attempts to capture the most important concepts I feel that organizations migrating their corporate Intranets to SharePoint (and Usability professionals in particular) should be aware of. But first, some background….
Our starting line: ready, set, SharePoint!
In 2008, our Intranet consisted of a number of different, widely-used applications and systems, including
It made sense for us to consider using SharePoint as a replacement for some of these applications and systems. Some problems with our existing Intranet included:
Our primary business goals for migrating our corporate Intranet to SharePoint included:
Our plan for "early adopter" departments
With almost 3,000 employees worldwide, one might expect that a migration to SharePoint would be a large initiative requiring lots of resources and planning. Our SharePoint Implementation team however, consisted of a three person Intranet team (manager/developer, developer, and Usability Specialist) plus a few other IT folks in an advisory capacity. So, we started with the simple, rough idea that we would move people in department by department, first selecting those that were open to the idea of being guinea pigs for this new technology project. There was little fanfare involved - just a few training courses, a basic idea of what we wanted to accomplish, and the concept of what would later be known as a "SharePoint Liaison"—a person whose job it was to help a department move in. We decided to tackle IT first (which for us consists of three departments: Business Applications, Systems Services, and IT Shared Services), learn from that, and decide how to proceed with future department migrations.
My early experiences as a SharePoint Liaison
I was the SharePoint Liaison for Systems Services' "company-facing site", or the page that everyone in the company would come to when they had trouble with their machines or needed to purchase software. (Systems Services also had a department-facing site, where that department collaborated internally.) The company-facing site was deemed critical enough to have my attention as a Usability Specialist.
The Systems Services' company-facing site was a fairly simple project—really just a front end interface to an existing knowledge base containing articles about common problems, and to our Help System, where users could submit Help Requests. I went in with the following, user-centered design process in mind:
This project took about five months, and although feedback about the site was positive, there were some grumblings about how long the project took. However, beyond the UCD process (which typically enjoys a perception of making projects take longer), there were several other factors involved:
Before the new company-facing Systems Services SharePoint site launched, and without any Usability resources or UCD process, both of the Business Applications department SharePoint sites (company-facing and department-facing) went live. They immediately received mostly negative feedback from the users, and so I was called in to investigate. The most notable problems I discovered after some interviews were that there didn't seem to be a clear distinction between the two sites, and that no one could figure out which sub-site the things they cared about were stored on (i.e. unclear Site Hierarchy).
Generally, each SharePoint site has a left navigation bar (which we removed from Systems Services' company-facing site) that shows all the sites that exist below it in a "Site Hierarchy" (see Figure 2). The Business Applications department had a mix of things in their Site Hierarchy: names of applications, names of teams within the department, initiatives they were working on, and seemingly random efforts. This confused people a great deal. After my recommendations, the sites were better targeted to satisfy their intended audiences' information needs, and sub-sites used a navigational model primarily based on applications (which essentially maps to teams).
Between this experience and the fact that Systems Services was not enthusiastic about revamping their site after having just done a revamp four years ago, it occurred to me that departments needed more knowledge about doing their own information architecture, and ideas on how to make their IA maintainable and scalable over time. Without this, our goal of "improving findability" would never be met. In fact, moving to SharePoint had potential to make things worse, since many people had gotten used to the way things were.
The High-level Vision for SharePoint's Information Architecture
Before I start talking about the process we arrived at, another point about information architecture: at a high level, the Intranet manager and select executive managers had a vision about what the overall information architecture (IA) would be. Although this wasn't widely communicated or solidified when we started moving departments into SharePoint, a few points were clear:
Working toward an improved process
Given these experiences, the following chart describes the five step process we came up with to migrate departments to SharePoint. The process is elaborated on in Figure 3 below.
The Future of the Migration Process
At the time of this writing, about half of our organization's departments have been or are in the process of moving into SharePoint. (These include the three IT departments I mentioned earlier, plus Usability, Development University, Program Management, Office Services, Process Improvement, Sales Operations, Technical Support, Legal Services, Human Resources, Customer Support, and many others.) Some of their migrations have been quick (one month or so) while others have taken more time than expected or desired (e.g. close to a year).
While the process described above has dramatically improved how we move departments into SharePoint, we are considering a different approach for migrating our large Development organization (engineers make up close to 40 percent of our total staff) and remaining departments. We are making changes for the following reasons:
We think that engineers represent a highly technical audience that could, in theory:
To this end, we are working to provide the Development (and remaining) departments with:
Time will tell whether this approach is more effective.
A word about "just in time" and hands-on training for project team members
Initial on-line training and classroom is great, and I still ended up creating what I called "SharePoint Office Hours" because I became known as one of the company's few "SharePoint gurus". If people keep coming up to you (or a few other people) and saying "Hey, you're a SharePoint expert, can you help me figure out how to…"z it's time to take a look at what training you're providing, step back, and make some improvements.
One of the powerful things about SharePoint is its configurability, configurability facilitated in part by "Web Parts," small functional components that can be added to a page. In our pilot evaluation, I watched countless end users think it was really cool that they could pick different Web Parts and position them on the page, but very few were able to configure them, so they gave up, and formed a less than positive impression of SharePoint overall. Pick a few things you think will be really useful to a department, train them how to use it and get their feedback on the training. Then the next time around, when another department says, "Hey, that was cool! How did they do that?" they can find out and do the same (preferably without using your office hours!).
Additional Words of Wisdom
In addition to the things I've already talked about, here are a few other tidbits everyone embarking on a SharePoint migration project should know. These may surprise you, since they don't really have much to do with the technology - but they are equally, if not more, important!
1. Think of the migration to SharePoint as a series of small consulting projects.
The Intranet manager who was responsible for SharePoint originally came up with a plan to roll out SharePoint to different departments in our company in a specific order. This order was determined by department size, their existing Intranet "footprint", estimated complexity of the migration, the department's initial enthusiasm, etc. When a department began the process, the Intranet manager gave a kick off presentation to the executive sponsor and whoever else s/he thought should be in the room, and then turn the project over to me, a "SharePoint Liaison," who could help guide the rest of the process.
As a Usability Specialist, at first I went in only thinking about applying a user-centered design process to the project. What I didn't realize until many months later was that my role wasn't just as Usability Specialist. I was really a consultant. I've always worked as a full time employee at organizations, and didn't think I had (at all!) a "consulting" bone in my body. But consulting isn't rocket science; it's just a shift in mindset. It's about paying equal attention to all the things outside of the project itself - all the little undercurrents of control, politics, vulnerability, relationships, etc. - and managing them so they don't end up negatively affecting the work of the project itself. I got these concepts from and highly recommend Peter Block's Flawless Consulting: a Guide to Getting Your Expertise Used to help learn these skills.
2. Recognize that the migration to SharePoint is really a change management problem.
While you're making that shift in mindset, you might as well make another one. Migrating any department into SharePoint should also be thought of as a change management (rather than a technology) problem. People are creatures of habit and therefore inherently resistant to change. Change takes effort, and temporarily makes their life more difficult. SharePoint is a tool that offers a lot of valuable features, and it requires re-training yourself and others to do things that may already work some other way. Successful change requires vision, skills, incentives, resources, and an action plan. If your migration plan for SharePoint is missing one of these concepts, you can expect a less than ideal project experience.
3. Get the executive sponsor to have these epiphanies too!
After you've accepted these concepts, you have to convince others too. And the most important person you can convince is the executive sponsor of the department, who will play an important role in all those elements of successful change. You need to work with someone who believes that the migration to SharePoint will help their department work more efficiently and effectively - something that's even more important in these leaner times. They need to commit to the effort by helping to set the vision, giving you access to resources in their area who have certain prerequisite skills to work on the project, and to communicate to their department incentives and focused plans on a regular basis. If the executive sponsor isn't a regular part of your project team, they should at least be involved or consulted at the "checkpoint" phases of the process.
4. For each consulting project, form teams with the right people.
Having the right set of people on the team is a really important factor in having the project go smoothly and being successful in the end. No one will know much about SharePoint in the beginning, but who really has to know in the end? The goal is to have the departments and groups responsible for the upkeep of their sites, so the project team should ideally consist of those people, who have some understanding of what their users need and will gain some understanding of SharePoint by working through the migration project. So, consider these roles for your project team:
In our organization, the technical representative, Usability Specialist, and project managers have all acted in the SharePoint Liaison role. The rest of the people in the department are end-users that should be regularly consulted to gather needed information via various user-centered design methods or reviews (e.g. interviews, card sorting, usability testing, etc.)
If you are a usability professional who will be involved in a project to migrate your company's Intranet to SharePoint, you'll be well served by keeping these points in mind:
|Contact the Voice|