When and How to Include End Users in SharePoint Migration Planning

As a technology evangelist, my role is to provide feedback and enhancements to our product team based on input from customers, consultants, SharePoint experts, and partners. Across many conversations with a diverse group of people, one theme is clear: end users are not involved enough in SharePoint planning.

This article will provide a quick overview of when and where to include end users in the planning, design, and migration of your SharePoint environment. Far too many SharePoint deployments are a technical success, and yet an organizational failure because users don’t support the system.

Developers and administrators can strengthen overall planning and ensure that end users have a stake in the migration process and the new SharePoint environment, and we’ll share ideas on how to do it. The rewards of this approach include increased user adoption rates and improved SharePoint effectiveness.

Development Framework

Many organizations view migration as a technical or administrative activity, not an end user effort. As a result, end user input may be secondary at best, or their involvement may be viewed as a burden that unnecessarily extends project timelines.

The problem with this view is that your end users know their requirements, essential business processes, and data better than you do. Input from the staff and managers who are responsible for the artifacts managed within SharePoint is a critical factor for a successful migration.  This input will help the engineers and IT pros responsible for the technical aspects of the migration to both determine – and follow – the correct priorities.

Including end user feedback should be an organized activity, and part of each phase of your SharePoint migration. Why? Because study after study shows that active involvement in the design and creation of a system dramatically increases the chance of success.

People will support what they help to create. In the case of SharePoint, end users are the recipients of the completed system – and should be the main driving force behind how the system looks and functions.

Regardless of your development methodology (or lack thereof), a structured migration plan might include formal stages, such as Discovery, Design, Build, Test, Release, and Support. Given my background in technical project management, I’m partial to the tenets of the Rational Unified Process (RUP) which recognizes the sometime blurry handoffs between phases, and moves projects forward based on principles rather than policy:

1.       Develop iteratively, with risk as the primary iteration driver

2.       Manage requirements

3.       Employ a component-based architecture

4.       Model software visually

5.       Continuously verify quality

6.       Control changes

There is no specific guidance on how end users should be included in this framework – it depends largely on your company culture, the types of users who will own the completed SharePoint environment, and the scope and scale of your role.

The point is to find ways to include them. Make a concerted effort to listen, and show them how their ideas have been incorporated into your design.

4 Feedback Mechanisms You Can Use

OK, so you have the high-level scope of your project: In this example, it is to migrate several SPS 2003 and MOSS 2007 environments to a brand new SharePoint 2010 farm (or multiple farms).

Your team has a defined development methodology (or a set way of doing things) and assigned a project manager. Your management team has an idea of how they’d like to see the new site or system designed, but you need to gather input from the people who will be using the system on a day-to-day basis.

Here are four strategies for feedback that will help you get your end users more involved:

1. Surveys. One of the quickest ways to gather information is through surveys and questionnaires. Use this format to gauge interest in your planning activities, determine the level of engagement with current tools and processes, and to help determine priorities. There is a lot of science behind surveys – the shorter the survey, the more likely the response. And using a 7 or 9-point scale will provide you with more actionable data than would a 3-point scale.

2. User groups / forums. If your organization is large enough to host one or more user groups, focused on SharePoint, ECM, or possibly .Net development, this is a great place to plug in and capture end user feedback about tools and processes. Offer to host one or two sessions, bring in lunch, and address questions directly if it will help you get honest feedback from the group. If no recurring forum exists in your company, start one. This should not be a one-time occurrence, but something that you can tap into on a regular basis to validate your system’s architecture, taxonomy, and usefulness.

3. RAD / JAD sessions. The Rapid or Joint Application Design session is one technique to develop rapid designs and user interfaces. The model is quite simple: gather together all stakeholders to the system (or representatives from each stakeholder area) with a facilitator and a technical writer, lock the door, and design your new system together in real-time. Create prototypes during these sessions, and release them to the group for feedback, and then immediately incorporate that feedback into the prototype and your overall designs. (See Figure 1 below.)

Figure 1: Migration Feedback

Early in my career, I led a JAD session with the California State Health Department that lasted several days. Included were the customer (State of CA), business and marketing representatives, operations, and the technical team.

What made this a successful effort was that all stakeholders were completely dedicated to the session – no cell phones, no email, no other meetings. The group removed themselves from all other responsibilities so that we could concentrate on the project at hand.

A technical writer captured requirements, and an engineer built a prototype as we watched, with his screen projected on the wall. We were able to very rapidly generate a prototype, and then refine the UI and our various business scenarios until everyone agreed with the final product. We completed in less than a week what would have taken months through more typical project management methods.

4. Interviews, through one-on-one interactions, team sessions / roundtables, or off-sites. Based on your company culture, geographic diversity, or stakeholder availability, you may need to be flexible on how you engage with people and document their requirements and priorities.

The key to success here is to identify your key stakeholders beforehand, and then figure out the right method for capturing their input. If you do the reverse, determining the method before the stakeholder, you will likely exclude one or more of your key stakeholders. 

How you engage your end users is somewhat determined by your output.

For example, a JAD session is not the right method for capturing a detailed requirements document, but it may be a great way to validate those requirements with your key stakeholders, while also quickly translating them into a working prototype.

The types of output are also determined by your methodology: more agile methods may not require the same detailed documentation that a more traditional, waterfall method calls for.

I won’t attempt to prescribe a methodology here, only recommend where you might include the end user stakeholders that need to have a voice in the design of your SharePoint environment. This has a direct impact on how to prioritize your migration.

Here are some of your core outputs, with guidance on how end users can be involved – or even drive the process.

Creating Documentation

At the beginning of any migration should be a detailed understanding of your current system: what works, what doesn’t work, what features are missing and critical to the success of the business, and which features are just nice to have.

This is your “as-is” or current state documentation, which includes your end user and key stakeholder requirements and enhancement requests, and lists the types of content and interactions that you currently use within your system. 

From these initial requirements you can create a content inventory, and get a firm understanding of the broad scope of your existing environment, including the features and customizations that must be moved as part of your migration.

Work with individuals and teams to outline a high-level view of current business processes and interactions with the SharePoint platform. List what isn’t working for you now and get feedback from all the users of your intranet. At this point, the goal is to cast a wide net and gather team and business unit requirements, critical scenarios, user stories, and current gaps.

When planning for a migration, one of the most critical factors is to document the various customizations on your source system. You should not rely solely on PreUpgradeCheck (see Figure 2 below) or other third-party tools to identify all changes to your system.

Figure 2: PreUpgradeCheck

Work with your end users to understand and document any custom web parts, workflows, UI changes, unique navigation or permissions, or any other changes to SharePoint file system so that you can determine whether these things should be migrated, and, if so, how.

Depending on the scope of your project, capturing this documentation could be a massive undertaking (SharePoint is the center of your company’s universe, and the central launch pad for all critical business processes), relatively quick (SharePoint is just a document repository), or anything in between.

Whatever the case, work with your end users to document all requirements, validate them, and get sign-off from all key stakeholders.

Creating Use Cases

Once you have a clear picture of the current state of your SharePoint environment and key business processes to be managed, you’ll want to evaluate and map out your critical use cases to ensure that your future system matches the operational needs of the business.

To begin, interview potential site users to find out what would help them in their jobs. Do they need a better way to automate common tasks and reporting? Organizing and tagging presentations and other marketing collateral? Finding HR information?

Identify the audience for each use case, and understand the key scenarios, working with users to flesh out the various states and flow of each (see Figure 3 below).

Figure 3: Identifying Audience and Flow

If your organization is not familiar with visual modeling techniques, you might start by first writing a gap analysis --what is missing between what you have now in the business process and what you want to have in place? What is the primary SharePoint interface? What are the key business processes behind the interface? Are there ad hoc collaboration scenarios that interrupt the workflow?

From these scenarios, you can begin to design of the future-state environment, beginning with the data model. This might include your high-level site taxonomy, with sub-sites, lists, columns (content types), relationships between lists, BDC connections, and so forth.

You can also begin to design the user interface, including custom list views, data views, forms, pages, navigation, master pages, and cascading style sheets (CSS), and begin thinking about custom workflows. As you refine these use cases and initial designs, work with your end users to validate your designs through regular design reviews, and get sign-off.

Prioritizing the Future-State Environment

What you migrate and how you prioritize your existing system components (content, permissions, taxonomy, master pages, navigation, etc) is the direct result of your end user discussions.

As you gain approval from management and your end users on the future state design, work closely with all stakeholders to identify which aspects of the system are to be built out and/or migrated first.

It’s important to remember that a successful migration and deployment of a new SharePoint environment requires both management buy-in (top-down) and end user buy-in (bottom-up).

Migrations are a phased, iterative process, and having a clear roadmap with an agreed strategy will mitigate any business impacts by allowing you to migrate in steps, validate the results and then move on to the next piece. This will greatly reduce the inherent risks of migration, and reassure the business.

Prototyping. Prototyping is one of the most powerful ways to demonstrate the capabilities within SharePoint. Whether working with an individual end user, a business unit, or a cross-functional team in a formal JAD session, developing quick prototypes allows you to validate your requirements and other inputs, and verify capability of the system.

Once you have gathered basic user requirements, create a prototype site within a staging system (or segregated space/site collection on your target server), and reach out to your end users for feedback.

Meet with them regularly to verify what is being built (complete the site structure and data model, mock up complex components); save the prototype as a site template and deploy to production; validate the prototype and get sign-off; and hand over the prototype to the development team (save as a template, backup the site or use SharePoint Solution Generator).

Content migrations. A critical aspect of many migrations is the consolidation of legacy systems, such as file shares, various ECM platforms, and paper-based files.

Your end users know their content better than you do, so put them in charge of identifying and classifying this data, preparing it for migration to the new SharePoint environment.

This might include development of the new taxonomy, metadata assignment, and if you’re migrating to the new SharePoint 2010 platform, creating the governance rules around the ongoing management of the Managed Metadata Service and various term stores to be set up and managed across the enterprise.

Testing. Once the migration is underway, end users are also the best resources for testing the new SharePoint environment, validating that content has been successfully moved and that search is working properly. They can also sign off on the test plan, verifying each use case, testing functionality, and identifying any issues or enhancements that the project and development teams need to address.

Project planning. A great way to get end users involved in the project early is to include them in the formal project launch or kickoff. Once the initial requirements have been captured, you may also want to provide a window where they can review and provide edits or feedback before finalizing them for project team signoff, and then again open the formal design reviews to a broader audience.

The key is to include a wider range of end users in these formal activities – clearly outlining the scope of the project each time, defining the success factors (including what has already been accomplished at each stage) to help people understand and feel a part of the process.

The more people feel involved in the process, the greater they will accept the change or new system.

4 Ways to Better Include SharePoint End Users

Regardless of your development methodology, find ways to include the end users in each iteration of the project plan. Some more suggestions include these:

Defining SharePoint Success

There is no single way to manage a project. Your methodology, the documentation you generate, and the level of involvement of your end users all depend on your corporate culture, the size and scope of your SharePoint upgrade / migration, and the standard project management measurements (time, cost, resources).

However, the key to success is the same no matter how you approach the problem: Understand the scope before you begin, and remind yourself of that scope throughout the project.

Right behind that project truth in importance is an equally critical success factor: get your end users involved early, and often.

Decide where and when to involve users as part of your pre-planning activities. This is the most fluid of the strategic considerations, as it really just depends on who your users are, what the current environment looks like, and the overall goals of your migration. Understand the culture of your organization, and be aware of your end user’s needs.

Remember: Users who participate in the creation of a system are more likely to accept and support that system once deployed. This is sage advice for any project.

Your users know their content – so let them drive activities around file share migrations, taxonomy development, metadata assignment, and signoff of the overall project plan. If you do this, you’ll find that people actually care about the system. And if they care about it, they’ll use it.

Christian Buckley is Director of Product Evangelism for Axceler, where he helps drive partner and community development. Christian previously worked at Microsoft as a Senior Program Manager on the enterprise hosted SharePoint platform team (now part of BPOS), and also managed an engineering team in advertising operations. He can be found online at Buckley Planet and on Twitter.