5. Prior to Microsoft, was a senior consultant, working in the software, supply chain, and grid technology spaces focusing on collaboration
6. Co-founded and sold a collaboration software company to Rational Software. Also co-authored 3 books on software configuration management and defect tracking for Rational and IBM
7. At another startup (E2open), helped design, build, and deploy a SharePoint-like collaboration platform (Collaboration Manager), managing deployment teams to onboard numerous high-tech manufacturing companies, including Hitachi, Matsushita, Seagate, Nortel, Sony, and Cisco
8.
9. Your Role Migrate SharePoint Find and integrate intra-company partners Support the internal community
10. Why Involve End Users? Executives Managers IT Department Consultants Partners The SharePoint Fairy End Users will determine the success of your SharePoint migration
11. Why Migration Migration is not just about moving your sites and content to a new system, butit is an opportunity to correct mistakes and problems, reorganize your environment, and make SharePoint (finally) fit your operational needs.
15. Service-Oriented Modeling Evolutionary SDLC Agile SSADM Chaos Model RAD Spiral Object-oriented Top-Down RUP Fountain Most organizations view migration as a technical or administrative activity, not an end-user effort Waterfall ISO V-Model RAISE B-Method VDM CMMI Scrum Anamorphic Development Petri Nets Extreme Unified Process Iterative Dynamic Systems Development
16. Service-Oriented Modeling Evolutionary SDLC Agile SSADM Chaos Model RAD Spiral Object-oriented Top-Down RUP Fountain End Users know their content, and understand how the system should work Waterfall ISO V-Model RAISE B-Method VDM CMMI Scrum Anamorphic Development Petri Nets Extreme Unified Process Iterative Dynamic Systems Development
17. Service-Oriented Modeling Evolutionary SDLC Agile SSADM Chaos Model RAD Spiral Object-oriented Top-Down RUP Fountain Studies show that end user participation in the design and development of a system dramatically increases the chance of success Waterfall ISO V-Model RAISE B-Method VDM CMMI Scrum Anamorphic Development Petri Nets Extreme Unified Process Iterative Dynamic Systems Development
18. Service-Oriented Modeling Evolutionary SDLC Agile SSADM Chaos Model RAD Spiral Object-oriented Top-Down RUP Fountain End user involvement should be included in each phase of your project Waterfall ISO V-Model RAISE B-Method VDM CMMI Scrum Anamorphic Development Petri Nets Extreme Unified Process Iterative Dynamic Systems Development
19. Development Framework Rational Unified Process Develop iteratively, with risk as the primary iteration driver Manage requirements Employ a component-based architecture Model software visually Continuously verify quality Control changes End Users help identify priorities, problem areas Provide requirements Help define components Review designs Test, provide feedback Use the product, identify technical issues
63. Creation of Use Cases Identify your actors End users Groups Systems Map out primary and secondary scenarios Create “shall” statements Keep it simple, focusing on a single task / result Keep them brief Don’t get into solutions, UI designs Understand the problem space before you start trying to build a solution
64. Design and Prioritization Get their input on what works in the current environment, and the sites they access most often, and what doesn’t work Get their feedback on proposed designs, and based on those designs, what they feel should be migrated Business critical content Web parts, customizations Line of business application integrations Understand which sites and content need to be migrated first Understand who should be involved in testing / validation
65. Creation of Documentation Leverage the extended team to create Use cases Business process definitions Revamped / updated designs Taxonomy Project plan / timeline Pre-migration checklist (documents not older than, number of versions moved, etc) User acceptance checklists Get their sign-off on all documentation One of the benefits of a structured phase-gate process is the opportunity for formal launch activities and post-mortems
66.
67. As each component (site structure, template designs, workflows) is completed, have end users test / harden the environment and get their sign-off
68. Once the build has been completed, have the users validate the packaged SharePoint application deployment to the staging environment, and get sign-off
76. Your end users know their content better than you do. Put them in charge of identifying and classifying this data, preparing it for migration to the new SharePoint environment.
82. Testing Build a test plan and clearly define their involvement
83. Governance Jumpstart your governance model Have a plan Create an internal SharePoint user group Clearly define roles and responsibilities Outline your taxonomy, communicate it, and iterate Create a governance site Learn and evolve
84.
85. Explain what it is you’re trying to do, and get end users onboard
96. Online and offline resources 11 Strategic Considerations for SharePoint Migrations (Buckley), http://slidesha.re/d3RHNH When and How to Include End Users in SharePoint Migration Planning (Buckley) http://bit.ly/duDFBb Getting Buy in from End Users, EUSP http://bit.ly/dKQHUF Plan site navigation (SharePoint Foundation 2010) (TechNet) http://bit.ly/hcINbl How to Jumpstart SharePoint Governance (Buckley) http://bit.ly/gUfyOw How to Jumpstart SharePoint Governance - Part 2 (Buckley) http://bit.ly/dZUHvM
97. For more information Contact me at Christian Buckley, cbuck@axceler.com, 425-246-2823 On Twitter at @buckleyplanet Additional Resources available White papers The Insider’s Guide to Upgrading to SharePoint 2010 What to Look for in a SharePoint Management Tool The Five Secrets to Controlling Your SharePoint Environment Tools ReadyPoint (free) Davinci Migrator echo for SharePoint 2007
Notes de l'éditeur
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.