Migrating a Corporate Intranet to SharePoint

Jen Hocko

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

• A Wiki (MediaWiki), largely used by our engineering organization for everything from meeting agendas and minutes to team pages and specifications
• Official department and team HTML pages, which originally followed a template and were editable with a preferred editor (Macromedia Contribute)
• "Project Pages", a home-grown application that offered rudimentary document sharing and collaboration capabilities for project teams via a browser
• Public folders, or standard file shares (SFS) set up per employee, that like Project Pages, promoted sharing of documents outside of e-mail attachments
• SFS areas per department, for department-wide collaboration and file sharing

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:

• Users gravitating to the applications that allowed for easiest editing (Wiki and Project Pages), avoiding edits to their HTML pages, or asking our very small Intranet team to edit their pages because Contribute wasn't easy to use
• Users weren't sure which application to use to share and collaborate on their documents, and developed preferences that weren't always in their best interest
• Users couldn't find documents and pages they were looking for:
  • Using our outdated search tool that frequently timed out
  • Browsing through links where the navigational model had not been maintained

Our primary business goals for migrating our corporate Intranet to SharePoint included:

• Zero-programming web page building
• Improving findability
• Improving collaboration

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.

Figure 1: The New Systems Services' Company-Facing Site in SharePoint

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:

• Assess the usability of the existing site (via web statistics, surveys, and interviews)
• Translate the themes from the usability assessment into design goals
• Brainstorm, create, usability test, and iterate on design concepts (via paper mockups and early SharePoint prototypes)

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:

• Access to the resources from the System Services department (for the project team) were scarce
• The project team wasn't well versed in SharePoint or UCD
• We had little interaction with the executive sponsor along the way
• We paid more attention to content from countries outside the U.S. than possibly ever before (which included having non-U.S. project team members)
• Schedules impacted when we could conduct design reviews and checkpoints with the sponsor and other executive managers

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).

Figure 2: The business Applications' Site Hierarchy in SharePoint

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:

• The top three "levels" of the IA were to be based on organizational structures (e.g. Division Name > Department Name > Team / Group Name).
• Once on a site for a Team/Group, that team had complete control over how they would organize their sub-sites (in the Site Hierarchy) and for the most part, their pages. (This is the area where Usability was sometimes tasked with helping out.)
• This executive vision attempts to walk the fine line between providing users with a consistent structure, and the freedom to organize their information as they see fit.

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.

Figure 3: Our Revised Process for SharePoint Rollouts (Timeframes Vary)

• Initiation:
  • This stage now includes some preliminary orientation for the project team about SharePoint technology, emerging best practices, and the process we use for the migration project. We also use SharePoint sites for the migration project, so the team gets used to SharePoint this way as well.
  • We can only draft a project plan at the Initiation stage. Until we get deeper into the evaluation, there is really no good way of knowing how big the project is going to be, or where / how we could scale it down.
  • Use this stage to focus and scope projects realistically, based on the company and department goals. SharePoint offers a boat-load of features that could be useful, and with that opportunity comes the reality that people may sink rather than swim when they're exposed to everything at once or stumble upon cool new features. Phase 1 (the migration project) should always be scoped appropriately: move what you have today with some improvements, and then start looking to phase 2. Executive sponsors can help with this in their communications throughout the project.
• Evaluation:
  • The goals of the SharePoint Implementation team responsible for moving departments into SharePoint were often different than the goals of the department itself. Calling these out explicitly helps ensure everyone is on the same page.
  • We created checkpoints where we could talk with the executive sponsors about how things were going, especially if they weren't directly involved in the day-to-day activities of the migration.
• Design:
  • Cleaning up (i.e. deciding what to keep, archive, or delete) is a huge, early design step that actually helps inform the new design, and helps the cause of not just dumping existing content into a new tool (especially if like mine, your organization has few policies about archiving). However, it is important to clean house after doing the evaluation, so as to get a real picture of what's going on. Consider having a "clean up day" where people sign up for time slots to look through specific directories and purge the junk.
  • Asking some of the difficult questions is important in this stage, such as: how does the department want people to communicate and work together? How do they want information presented and organized? How do they want that information maintained over time? You might even consider doing some of that before the Design stage, such as in Initiation, and use the Evaluation stage to refine the initial thoughts.
  • We created "guided" and "self-service" versions of an information architecture design process, complete with document templates (in Word) to help departments evaluate their current structure and create / communicate their new structure for long-term scalability and department-wide understanding. (See Figure 4)
  • Beyond how things will be organized going forward, remember to think about governance in this stage (especially if you're taking the time to set it up properly). Governance includes plans for communicating, training, (and possibly enforcing) the new structure, deciding what to do when things don't fit neatly (i.e. when and how to change the structure, and who has that authority), etc. Governance is what will help reduce the need for those major overhauls later, because things won't get as out of control over time.
  • We provided a template in SharePoint for department, team, and project sites.
• Implementation:
  • We clarified that the support offered by the SharePoint Liaison and Implementation team would happen only up until the department's staff was mostly "living in" SharePoint - there are likely many phase 2 (and 3, and 4) projects that the department could handle on their own. (This helps immensely with scoping, and meeting the SharePoint Implementation team's goals for getting departments moved in quickly.)

Figure 4: Current Information Architecture Evaluation Template

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:

• The bandwidth of the people who know about SharePoint (the Implementation Team, SharePoint Liaisons, and System Services folks) is already taxed by many questions and issues throughout the day, causing them to spend more time on hands-on training than project work.
• We want to move departments in more quickly than we have in the past; we are working in two different worlds at the moment, and this is becoming more difficult.
• Developers' information architecture and daily work artifacts are tightly tied to the templates and tools that are designed as part of our development process (and is therefore different from how the rest of the company works).

We think that engineers represent a highly technical audience that could, in theory:

• Be more self-sufficient in their migration projects.
• Train others in the Development department better than we could, because they are more likely to play around with SharePoint's features and functionality.

To this end, we are working to provide the Development (and remaining) departments with:

• More self-serve resources (e.g. annotated examples, "how to's", guidelines, checklists, and best practices)
• Other mechanisms for sharing information (e.g. brown bags, user groups, etc.)
• More formalized processes for:
  • Getting support (e.g. designated office hours for SharePoint experts, business case process to manage project and site design requests, etc.)
  • Reviewing work done independently (e.g. more specific, scheduled checkpoints with
  • SharePoint experts to set / correct directions)

Time will tell whether this approach is more effective.

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:

• Executive sponsor (in a regular capacity if possible, and ALWAYS involved in the check points).
• A technical representative, who understands the opportunities and limitations of SharePoint.
• Representatives from different functional areas within the department (e.g. HR representatives from Benefits, Recruiting, Training, etc.) who can take over as site owners after the migration is done. Someone from the department would ideally have some light technical knowledge or aptitude for it (e.g. HTML).
• A Usability Specialist or someone trained in user-centered design methods, including information architecture.
• A project manager, who can help keep the project on track and follow up on action items.

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.)

Summary

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:

• Make sure you are clear on the (overall and department-specific) SharePoint vision, goals, project phases, and expectations.
• Advocate for and interact with an executive sponsor on a regular basis.
• Before you get too far, be sure your company has a solid training and support strategy, which will grow in importance as the SharePoint user base does - feed the team with information to facilitate this.
• Participate as much as you can to ensure that an information architecture strategy exists and will work for users across and within the organization.
• Creating a move-in process (that includes UCD activities) and revising it over time will help determine what works and what doesn't, so each time it will get easier. (Think of it as a usability test or pilot of the process itself.) I recommend this approach over a massive push of everyone in at once (which could also slam training/support).
• Recognize that SharePoint will require everyone to engage in an iterative, ongoing learning process and won't be without struggle or confusion. Some struggle and confusion will pass with time.
• SharePoint is as much a change management and consulting problem as it is a technology rollout.