Top
Design
Process

Migrating a Corporate Intranet to SharePoint: A Case Study

By Jennifer Hocko Patrick
August 9, 2010
  3 Comments

Before 2008, SharePoint was a tool I’d used briefly at a very large company a few years prior—and was a distant memory. But once my current employer decided we should evaluate SharePoint 2007, then soon afterward, decided to migrate our intranet to SharePoint, the migration project became a large part of my day-to-day life as a usability specialist working solely on intranet applications.

As I worked with our SharePoint implementation team, I struggled with many things—and, hopefully, learned a few things, too. This article attempts to capture the most important concepts organizations migrating their corporate intranets to SharePoint—and their usability professionals in particular—should understand.

Champion Advertisement
Please become a patron of UXmatters by subscribing on Patreon.
Continue Reading…

Ready, Set, SharePoint!

It made sense for us to consider using SharePoint as a replacement for our existing intranet. Some usability problems we’d had with our intranet included the following:

  • Users gravitated toward applications that were easiest to edit, like our wiki and custom-built Project Pages application. They either avoided maintaining their department’s HTML pages altogether or asked our very small intranet team to edit the pages for them.
  • 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 interests.
  • Users couldn’t find the documents and pages they needed, because:
    • Our search engine frequently timed out.
    • We had an obsolete navigational model that made browsing via links difficult.
    • There wasn’t a consistent information architecture.

Our primary goals for migrating our corporate intranet to SharePoint included

  • self-sufficient users who could build their own Web pages without programming experience
  • improved findability
  • improved collaboration

Our Plan for Early-Adopter Departments

We started with the rough idea that we would move people to SharePoint department by department, moving those who were open to the idea of being guinea pigs for this new technology project first. After taking a few training courses, our small team had a basic idea of what we wanted to accomplish and had come up with the concept of a SharePoint Liaison—a person whose job it was to help a department move to SharePoint. We decided to tackle IT first, which included three departments: Business Applications, Systems Services, and IT Shared Services, learn from that, then 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—

shown in Figure 1. This is the page everyone in the company would come to when they had trouble with their computer or needed to purchase software. (Systems Services also had a department-facing site, which the department used for internal collaboration.) The company-facing site was deemed critical enough to have my attention as a usability specialist.

Figure 1—New Systems Services’ company-facing site in SharePoint
New Systems Services’ company-facing site in SharePoint

Creating 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 started with this user-centered design (UCD) process in mind:

  • Assess the usability of the existing site through Web statistics, surveys, and interviews.
  • Translate the themes from the usability assessment into design goals.
  • Brainstorm on design concepts.
  • Create possible design solutions.
  • Do iterative usability testing—on paper prototypes and early SharePoint prototypes—and refine our designs as necessary.

This project took about five months. Feedback about the site was positive, but I also got some pushback from the intranet manager about how long the project had taken. The UCD process is always too easy to blame, but there were actually several factors involved in slowing the progress of the project:

  • Our project team had limited access to resources from the System Services department.
  • 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 and included non-U.S. project team members.
  • When reviews and checkpoints required sponsor or executive manager attendance, their availability impacted our schedule.

Before the company-facing Systems Services SharePoint site had launched, both of the Business Applications department’s SharePoint sites—company-facing and department-facing—went live without having involved any usability resources or undergone a UCD process. These sites immediately received strong negative feedback from users, so I was called in to investigate. After conducting some user interviews, the most notable problems I discovered with the Business Applications sites were as follows:

  • There wasn’t a clear distinction between the two sites.
  • No one could figure out which of these sites contained the things they cared about—that is, the Site Hierarchy, shown in Figure 2, was unclear.

Generally, each SharePoint site has a navigation bar on the left, which lists all of the sites under it in a Site Hierarchy. We had removed the navigation bar from Systems Services’ company-facing site, because we felt it would be distracting for users to be confronted with the department’s internal workings, when all they wanted was help. However, on the Business Applications site, a confusing mix of things was visible in the Site Hierarchy, including names of applications, names of teams within the department, and initiatives they were working on. After the team implemented my recommendations, the sites were better targeted to satisfy their intended audiences’ information needs, and each site used a navigational model that was primarily based on applications, which essentially map to teams.

Figure 2—Business Applications’ Site Hierarchy in SharePoint
Business Applications’ Site Hierarchy in SharePoint

Between my Business Applications experience and the fact that Systems Services were not enthusiastic about revamping their site—having just done so four years earlier—it occurred to me that departments need more knowledge about information architecture and how to make their information architectures maintainable and scalable over time. Without this, we would never meet our goal of improving findability. In fact, moving to SharePoint had the potential to make things worse, because many people had become used to the way things were, and we were about to change all that.

High-Level Vision for SharePoint’s Information Architecture

The intranet manager and executive managers had a preconceived vision about what the sites’ overall information architecture would be, which centered around these points:

  • The top three levels of the intranet’s information architecture should be based on organizational structures—for example, Division Name > Department Name > Team Name.
  • Within a team’s site, the team had complete control over how they would organize their sub-sites in the Site Hierarchy and, for the most part, their Web pages. (This is the area where the Usability team helped out.)

Thus, this executive vision attempted to walk a fine line between providing users with a consistent structure and giving them the freedom to organize their information as they saw fit.

Working Toward an Improved Migration Process

We used what we learned from our initial experience to devise an improved SharePoint migration process. Figure 3 shows the five-stage process we came up with for migrating departments to SharePoint.

Figure 3—Our process for SharePoint rollouts
Our process for SharePoint rollouts

Now, let’s look at the stages in this process in more detail.

Initiation

The initiation stage includes a preliminary orientation for the project team to familiarize them with SharePoint technology, emerging best practices, and the migration process itself. We use SharePoint sites for migration projects, so teams get used to using SharePoint.

We recognized that we can create only a draft project plan at this stage. Until we get deeper into the evaluation, there is really no good way of knowing how big a project is going to be or where or how we could scale it down.

We use the initiation stage to focus and scope projects realistically, based on company and department goals. SharePoint offers a boatload of potentially useful features, but along with that opportunity comes the danger that people may sink rather than swim if they’re exposed to all of its capabilities at once. Therefore, it is always important to scope Phase 1 of a migration project appropriately, implementing the capabilities a department has today, plus just a few improvements. Then start looking at Phase 2. Leadership from executive sponsors can help keep a project focused.

Evaluation

The goals of the SharePoint implementation team that was responsible for moving departments to SharePoint were often different from the goals of the departments themselves. Calling everyone’s goals out explicitly during the evaluation stage helps ensure everyone is on the same page. We created checkpoints at which we could talk with executive sponsors about how things were going—especially those who weren’t directly involved in the day-to-day activities of the migration.

We asked some of the difficult questions at this stage—such as, How does a department want people to communicate and work together? How do they want to present and organize information? How do they want to maintain that information over time? Even if people have already considered these issues, use the evaluation stage to refine initial thoughts.

To facilitate our evaluation process, we created a guided, self-service version of our information architecture design process, complete with Microsoft Word document templates. Figure 4 shows part of one of these templates.

Figure 4—Current Information Architecture Evaluation Template
Current Information Architecture Evaluation Template
Current Information Architecture Evaluation Template

This template, along with the one we created for documenting the department’s new information architecture later in the process, helped departments to rationalize and communicate their sites’ new structures to others, ensuring both their long-term scalability and department-wide understanding.

Design

Once an evaluation is complete, it’s important to clean house—that is, decide what to keep, archive, or delete—and get a realistic picture of what you need to do. Cleaning up is a huge, early design-stage step that helps inform the new design. It’s important to avoid just dumping your existing content into a new tool—especially if your organization doesn’t have clear policies about archiving data. Consider having a Cleanup Day, when people sign up for time slots during which they’ll look through specific directories and purge the junk.

It’s important to continue asking the difficult questions and refining your thoughts at this stage. Beyond looking at how departments will organize things going forward, remember to think about governance, especially if you’re taking the time to set it up properly. Governance includes communication and training plans for the new structure, as well as, possibly, its enforcement. You need to decide what to do when things don’t fit neatly—that is, when and how to change the structure and who has the authority to do so. Governance will help reduce the need for major overhauls in the future, because things won’t get as out of control over time.

Implementation

We determined that the support the SharePoint Liaison and implementation team offered would continue only until a department’s staff was working primarily in SharePoint. There are likely many projects, for Phase 2 or beyond, that a department could handle on its own. (This decision helped immensely with scoping, as well as with meeting the SharePoint implementation team’s goals for getting departments moved in quickly.)

The Future of Our SharePoint Migration Process

While the process I’ve described had dramatically improved the way we moved departments to SharePoint, we are using a different approach for migrating our large Development organization—engineers make up close to 40% of our total staff—and remaining departments. We are making changes for the following reasons:

  • The many questions and issues that arise daily are already taxing the bandwidth of the people who know about SharePoint—the implementation team, SharePoint Liaisons, and System Services folks—causing them to spend more time on hands-on training than project work.
  • We want to move departments to SharePoint more quickly than we have in the past. The company is working in two different worlds at the moment, and this is becoming more difficult.
  • The developers’ information architecture and daily work artifacts are closely integrated with the templates and tools that are part of our development process—and are different from those the rest of the company uses.
  • Engineers are a highly technical audience that
    • could be more self-sufficient during their migration process
    • would be more likely to play around with SharePoint’s features and functionality
    • could train others in the Development department better than we could

To this end, we are currently working to provide Development and the other remaining departments with

  • templates or standard designs for department, team, and project sites
  • more self-service resources—for example, annotated examples, how-tos, guidelines, checklists, and best practices
  • additional mechanisms for sharing information—for example, brown bags, user groups, and a SharePoint community site
  • more formalized processes for
    • getting support—for example, providing designated office hours for SharePoint experts and business-case processes for managing project and site-design requests
    • reviewing independent work—for example, establishing more specific, scheduled checkpoints with SharePoint experts to set and correct a department’s direction for their SharePoint migration

Time will tell whether this approach is more effective.

Just-in-Time, Hands-on Training for Project Team Members

While our initial online and classroom training are both great, I still ended up establishing what I called SharePoint Office Hours, because I became known as one of the company’s few SharePoint gurus. If people doing a migration keep coming up to you and a few others saying, “Hey, you’re a SharePoint expert, can you help me figure out how to…,” it’s time to step back and take a look at what training you’re providing and make some improvements.

One powerful thing about SharePoint is the configurability its Web Parts facilitate. Web Parts are small functional components you can add to a page. In our pilot evaluation, I watched countless users who thought it was really cool they could choose different Web Parts and place them on a page. However, very few of them were able to configure the Web Parts, so they gave up, and formed a less than positive impression of SharePoint overall. We chose a few things we thought would be really useful to a department, trained their people to use them, and got their feedback on the training. Then, the next time around, when another department said, “Hey, that was cool! How did they do that?” they could find out and do the same thing—preferably without using our office hours!

Additional Words of Wisdom

Here are a few additional things anyone embarking on a SharePoint migration project should know. These may surprise you, because they don’t really have much to do with the technology. But they are equally, if not more important!

Think of a migration to SharePoint as a series of small consulting projects.

Our intranet manager who was responsible for the SharePoint migration originally came up with a plan to roll out SharePoint to different departments in our company in a specific order. He determined this order by considering department size, a department’s existing intranet footprint, the estimated complexity of a migration, and a department’s initial enthusiasm. When a department began its migration process, the intranet manager gave a kickoff presentation to the executive sponsor and whoever else needed to be in the room, then turned the project over to me, a SharePoint Liaison who could help throughout the rest of the process.

As a usability specialist, I at first thought only 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 that of a usability specialist. I was really acting as a consultant. I’ve always worked as a full-time employee within organizations and didn’t think I had 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 everything surrounding a project—all the little undercurrents of control, politics, vulnerability, and relationships—and managing them so they don’t end up negatively impacting the project. I learned these concepts and skills from Peter Block’s Flawless Consulting: A Guide to Getting Your Expertise Used, and I highly recommend your reading it.

Recognize that a SharePoint migration is really a change-management problem.

While you’re making that shift in mindset, you might as well make another one. You should also think of migrating a department to SharePoint 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 people’s lives more difficult. SharePoint is a tool that offers a lot of valuable features, but it requires retraining yourself and others to do things in a different way—things that may already be working just fine for them. Successful change requires vision, skills, incentives, resources, and an action plan. If your migration plan for SharePoint is missing any of these concepts, you can expect a less-than-ideal project experience.

Get your executive sponsor to have these epiphanies, too!

Once you’ve accepted these concepts, you have to convince others, too. And the most important person you should convince is the executive sponsor for a department, who will play an important role in all of these elements of successful change. You need to work with someone who believes that a migration to SharePoint will help their department work more efficiently and effectively—something that’s even more important in these lean times. This executive sponsor needs to commit to the effort by helping to set the vision, giving you access to resources in their department who have certain requisite skills for working on the project, and to communicate incentives and focused plans to their department on a regular basis. If the executive sponsor isn’t a regular part of your project team, he or she should at least be involved or consulted at the process checkpoints.

For each consulting project, form a team with the right people.

Having the right people on a team is a really important factor in determining whether a project goes smoothly and is successful in the end. No one knows much about SharePoint in the beginning, but who really has to know in the end? The goal is to make departments responsible for their sites’ maintenance, so the project team should ideally consist of those people who have some understanding of what their users need and can gain some understanding of SharePoint by working through the migration project. Consider the following roles for your project team:

  • executive sponsor—who should be involved in a regular capacity, if possible, and is always involved at the checkpoints
  • technical representative—who understands the opportunities and limitations of SharePoint
  • representatives from various functional areas within a department—who take over site ownership once the migration is complete. Ideally, someone from the department should have some technical knowledge or an interest in the Web sites.
  • usability specialist—who is trained in user-centered design methods and information architecture
  • 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 manager have all acted in the SharePoint Liaison role. The rest of the people in the department are users from whom you should regularly gather needed information, using various user-centered design methods—for example, interviews, card sorting, or usability testing.

In Summary

If you are a usability professional who is involved in migrating 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.
  • Ensure that an information architecture strategy exists and will work for users across and within organizations.
  • Create a move-in process that includes UCD activities. Revising it over time can help you determine what works and what doesn’t, so each time the process will get easier. (Think of each project as a pilot of the process itself.) I recommend an incremental approach over a massive push to migrate everyone at once. Doing too much at a time could also slam training and support.
  • Recognize that migrating to SharePoint requires everyone to engage in an iterative, ongoing learning process and won’t be without struggle or confusion, but most of this passes with time.
  • Appreciate that SharePoint is as much a change-management and consulting problem as it is a technology rollout. 
In Design Process | Web Site Design

Jennifer Hocko Patrick

Mind-Body Wellness Consultant

Waltham, Massachusetts, USA

Jennifer Hocko PatrickJen currently works at The MathWorks, where she manages a team that focuses on improving the usability of both custom-built and procured business software. In the past, Jen has been a Web developer, technical writer, and interaction designer at both large and small organizations. She has an M.S. in Human Factors from Bentley University.  Read More

Other Articles on Web Site Design

New on UXmatters