I’m often asked for advice on how to ensure that a SharePoint project is completed and implemented successfully. Following some pointed questions, I provide some tactics to try, but the reality is that there is no single tip or strategy that will provide such an insurance policy.
Even with the most finely tuned adoption or governance plan, your project can still fail for a variety of reasons: mismanaged requirements, development errors or simply the wrong training. It takes a perfect storm in order to get everything rolled out and implemented correctly. Though it’s impossible to identify just one item that can save you from such issues, a pilot project is a great way to measure twice and cut once with your rollout of SharePoint.
A pilot project is a soft launch that puts your deliverables into the hands of a subset of your user community. Following a shortened cycle of design, development and delivery, a pilot runs for a defined period of time in order to review and obtain feedback on the rolled-out functionality. Once a corporate perspective has been obtained on the rollout, the project team can then begin developing for a wider deployment to the business.
Possibly the best advice I can give is to take your pilot project as seriously as you would a full deployment. Staff your project with A-Team players and make sure that everyone who needs to know about the project does. What you are limiting is not functionality, but the distribution of the product in order to get the feedback you need to ensure corporate rollout success.
Once you have made the decision to roll out a pilot, you must next decide who will be involved in it. Depending on who brought SharePoint into the organization, this may be an easy choice. For example, if HR is responsible for SharePoint coming into the business, they are also an easy choice to be in the pilot. They will provide strong, user-defined requirements, honest feedback, and a keen interest in its long-term success. If IT is responsible for SharePoint, look for business units or user groups that will provide the same strong requirements driven by business needs. You can also start backwards when defining your pilot group by choosing a business problem that you know SharePoint can solve, then define which user group can best be affected by its deployment.
Define your success measurements by thinking about what will make this project an internal “win.” What will users say or do in the pilot environment that will establish a credible baseline for the functionality to “work”? Will users be able to complete their tasks easier and more efficiently than before? Will they go to SharePoint first in order to send a document or search for information? As you read these suggested questions, develop some that are relative to your business environment and corporate situation. Don’t forget to communicate your success as the pilot becomes reality and people are using the functionality you have deployed.
Don’t overlook the importance of documentation, training and setting the robust policies required in order to support the project. Support is critical to success, and typically the most overlooked component of an implementation. I have seen many projects fail due to lack of support. Project teams feel that because they have matched requirements with deliverables, the functionality will be adopted, and this is not the case. Your documentation should highlight the importance of the pilot, functionality to be rolled out, and how users can ask for help if required. Also plan on staged feedback sessions in order to receive the feedback you need. Depending on your project schedule for the pilot and full deployment, this can take place biweekly or monthly to gather feedback and mark changes for the deployment.
Upon completion of the pilot project, you will have an instance of SharePoint in production that serves a particular niche set of requirements and user community. At this point in your project, great strides will have been made in developing the expertise required to roll out your pilot. Once the system is up and in the hands of your users, you can move your focus from rollout to feedback. Have an area on your pilot environment to gather feedback from your user community. Remember, feedback is everything at this stage, as it validates what you have built and allows you to obtain honest perspectives on what has been deployed.
Eric is the EVP of Systems Integration for Concatenate, a software firm focused on maximizing SharePoint through product innovation and systems integration based in Toronto. You can reach Eric by e-mail at ericr@concatenateinc.com or on Twitter at @rizinsights. Read his other SharePoint thoughts on his blog at www.ericriz.com.
