SharePoint Adoption Tips

Home Forums Program and Project Management SharePoint Adoption Tips

This topic contains 0 replies, has 1 voice, and was last updated by  Benjamin Hoff 4 years, 4 months ago.

  • Author
  • #182749

    Benjamin Hoff

    I’ve been involved in SharePoint User Adoption activities for the the past year and a half. This is a document my organization has developed to hel drive user adoption. “Coach” is a term my organization uses to refer tothe staf taking a lead role with SharePoint. Thanks for reading:

    How to Drive SharePoint (SP) Adoption

    Expectations and Realities for SP Coaches

    1. An SP coach is expected to perform several different roles including team-builder, trainer, and technical expert. One more important role is that of a salesperson for SP. Promoting the advantages of using SP will greatly increase the chance of a successful user adoption.
    2. Recognize that this is not an overnight process. As an example, it took QA over a year to build SP use up to its existing levels.
    3. Do not view SP as a panacea. There are some processes that it will not work on SP.
    4. Seek out leadership support. If the Deputy Secretary and Bureau Directors are not fully supportive and pushing the use of SP, it will not happen.
    5. Build an internal SP team to brainstorm solutions and guide the deputate.

    Building an SP Team

    1. Recognize User Strengths and Weaknesses
      1. Look for people who are already excited about SP to act as champions within your teams.
      2. Get supervisors on board. Ensure staff members are empowered to spend time on development and use of SP.
      3. Recognize which staff members will need extra help and which need the freedom and flexibility to explore SP on their own.
      4. Assemble SP Resources
        1. Consider creating an SP implementation team which meets regularly. (See sample here.)
        2. Create an SP implementation timeline. (See sample here.)
        3. Become familiar with the DOH SP Support Site to develop the SP skills you need. Refer co-workers to the site and other resources that have essential information.
        4. Request a Sandbox (or test SP site) to practice SP use; test SP functionality and test design ideas.
        5. Request a project SP site to organize all the work related to SP implementation.
        6. Use visual aids and demonstrations whenever possible. Find SP sites that are already created to show new SP users what their future SP site could do.
        7. Eliminate the need for everyone to know coding or how to manipulate SP “behind the scenes.” Focus instead on what staff members need for ongoing use. Focus on the business process rather than the SP technology. Ask staff what do they need for their business process rather than what do they want to do in SP. Treat the conversations with a change management approach. It’s not about SP, per se, it’s about changing how staff conduct their business.
        8. Look at the long-term vision of the enterprise you’re assisting and identify ways to push the team toward that vision through the use of SP.

    Implementing Individual SP Sites or Automating Processes

    1. If possible, make every team move one project, process, or workgroup to SP.
    2. If possible, do not offer SP as a “choice.” Expect that staff will have to make the change and approach discussions in this fashion.
    3. Take baby steps and start with small projects, single processes, or a small piece of a broader SP site.
    4. Seek out quick wins that make everyone involved happy. It may be easier to start with new projects or workgroups than existing ones. Find usage where SP can make an easy fix, develop a quick mock-up, and then show the changes to the team lead.
    5. Identify the “pain points” within a team and figure out how SP can improve upon the things staff are already complaining about.
    6. Encourage communication. Make sure all SP users know who their coaches are and how to reach them. Listen to feedback from SP users and respond by doing whatever is possible to create a positive end-user experience.
    7. Jump on requests as quickly as possible. Do not make users wait for a solution.
    8. Document the implementation process by recording decisions that are made. Record SP policies within the deputate, bureau or division and completed and ongoing projects that relate to SP implementation.
    9. Document SP site content when needed including permissions, libraries and lists included on the site as well as site use instructions.
    10. Keep SP sites dynamic. This is not a “once and done” project. Solutions which work now can easily be changed later as a team’s needs change.

You must be logged in to reply to this topic.