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.
Creation of 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).
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 / 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.
Regardless of your development methodology, find ways to include the end users in each iteration of the project plan. Some more suggestions:
o Use short iterations / cycles so that end users can see that you have incorporated their feedback into the environment, and give them a chance to validate
o As each component (site structure, template designs, workflows) is completed, have end users test / harden the environment and get their sign-off
o Once the build has been completed, have the users validate the packaged SharePoint application deployment to the staging environment, and get sign-off
o After deploying the final packaged SharePoint application to the production environment, communicate project completion to the end users and formally close out the project – with an official project acceptance and / or post-mortem.
Defining 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.