Strategies for Involving End Users in Your Migration -- GraceHunt Webinar 01272011

2,103 views

Published on

Content from my webinar Jan 2011, with best practices for involving end users in

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,103
On SlideShare
0
From Embeds
0
Number of Embeds
146
Actions
Shares
0
Downloads
37
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.Image 1. Working with your team to design templates based on out-of-the-box componentsEarly 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.
  • 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.
  • 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. Image 3. Creating use cases for the most common end user scenariosIf 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.
  • A great way to get end users involved in the project early is to include them in the formal project launch / 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 / new system.
  • 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.
  • 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.
  • 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.
  • ×