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.
Feedback Mechanisms
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:
- 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.
- 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.
- 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.)
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.
- 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.
Creation of 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) or other third-party tools to identify all changes to your system.
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.