Standing in the SharePoint Gap

IT departments must manage the entire SharePoint platform, ensuring long-term stability, security and integrity for the enterprise. The business just wants what they want! This can result in dissatisfaction on both sides. How does your company resolve this conflict?

bridgingthegapCompanies using SharePoint for end-user collaboration need someone who stands in the gap between IT and the business to broker that often tenuous relationship. This is usually assumed to be a business-side role. However, it’s much more appropriate for it to be a SharePoint role.

Before SharePoint, my background was in business process improvement and project management. I did not start out in IT at all. I was not a developer, programmer, engineer or system administrator. I took on SharePoint in the context of another initiative and quickly discovered its vast potential. I was fortunate to be able to make a career change and spent the next 5 years immersed in SharePoint, dramatically increasing my skill set.

Without the options of coding or development at my disposal, I learned how to get results by pushing the envelope and exploring the platform’s native options. Along the way, I also increased my knowledge of the IT side and built strong relationships with those responsible for the “care and feeding” of the platform. We quickly learned the value of what each side brought to the table. They appreciated the presence of someone skilled in speaking both languages. I interpreted “SharePoint-ese’ for the business; I also translated requirements and pain points into well-designed, quickly-deployed sites & solutions. These solutions delivered valuable return on a (sizable) SharePoint investment without spending a dime on development. I can also walk into any meeting and speak clearly and intelligently about SharePoint to stakeholders at all levels.

Do you have such a person on board? Don’t you wish you did?

From a technology standpoint, SharePoint is something of a latecomer. Those who currently make SharePoint their career have, by and large, come to it from somewhere else. Most were already in IT- usually developers/engineers/system administrators- who continue to focus on those areas as they extend into the SharePoint space. This tends to cause a “development approach” to solving SharePoint problems which is not always conducive to building a strong relationship with the business side. It can delay delivery of solutions and sometimes negatively impact upgrade paths. My strengths offset that risk.

By first exploring all “in-box” options to their fullest potential, companies can be assured of getting the most bang for their SharePoint buck. The vast scope of features built into the product practically demands such an approach to truly realize that investment. Before throwing development dollars at the problem, don’t you owe it to yourself to see what might be possible?

It’s amazing what SharePoint provides out-of-the-box! There are so many tools and functions are already there, just waiting to be leveraged. As previously mentioned, this approach also helps ensure future compatibility for upgrades, patches and service packs. Even more importantly, such methods are much easier to make transparent to end users. Handing over a “configured” solution often means that your users don’t need to come back to IT for enhancements down the road- with a little education, they can make many change or repairs themselves. It’s vital to take advantage of every opportunity at hand to strengthen the business partnership.

That’s MY SharePoint role. What’s yours?


SharePoint sites and solutions- set yourself up for success

Inspired by this blog post by consultant Gia Lyons which specifically targets launching a social media pilot program- it’s practically the same conversation with regard to SharePoint solutions. I recommend you read her article for context but I have used it as the foundation of this post.

Don’t pretend that throwing this rock won’t make any ripples- Acknowledge the impact that implementing SharePoint will have on your team.

  • Depending on user experience, SharePoint may present brand-new technology, ALONG WITH a brand-new learning curve.
  • It’s a challenge to establish both at the same time. Who will lead your users?
  • Manage your expectations- figure out how to prove usefulness in small ways before trying to make SharePoint “do it all.”

Survey the landscape

  • What is your team’s general contribution to the business?
  • How many people will use your site/solution?
  • How long will it be needed?
  • What is the lifecycle of the site’s content?
  • Where are team members/participants physically located?
  • What is their general attitude towards collaboration software? What concerns do they have?
  • Are there inconsistencies in technology? For example, multiple Office versions or IE versions in use) among participants?
  • Are most participants considered “technology-forward?”
  • Can you anticipate pushback from those less inclined to embrace a technology-based platform?
  • Are there cultural or language differences within your group that should be considered?

Find a purpose
How does the group want to use SharePoint? This is very important- mandating one person’s vision will not produce success. There must be a strong sense of “group-ness” permeating the reasons why SharePoint is the tool selected for this job.

  • How are participants getting what they want today, without SharePoint?
  • Fix on a few key “pain points” and go from there, then branch out.

Define roles and responsibilities
In the context of the functionality your site will be providing, classify all participants into the following broad categories:

  • Site owner/Business Process Owner (~1-2 persons)
    • Top “responsible party” for the site who would have to answer to upper management when/if anything about your site came on their radar
    • Person on the hook for budget dollars related to SharePoint costs
  • Site manager (~2-3 people)
    • Could be at the site or site collection level OR both
    • I consider this the most important role in SharePoint.
      • Person(s) established as site managers must spend a lot of time in the site; they are required them to know its ins and outs and troubleshoot most situations that arise for end users
      • They may also be responsible for on-boarding new users and/or hand-holding less confident users.
    • Facilitate use of SharePoint and help others incorporate its use into their work routine.
    • They are the go-to person for anyone who has questions about the site and should present a confident, knowledgeable, pro-SharePoint attitude.
    • They must know how to quickly and accurately escalate issues beyond their expertise.
  • Site contributors (as many as needed)
    • Persons whose normal role requires no stake in the site’s design, look & feel etc. but who need to be able to interface with content elements (lists/libraries) to do their jobs- upload, create/modify list items etc.
    • These people are the best resource for feedback on site functionality- site “mechanics” must work for them or overall success of the site will be threatened.
    • They need good training that lets them clearly step through the most common site-related functionality
  • Site visitors (as many as needed)
    • Persons whose normal role only requires them to view content to gain value from the site, but may occasionally be elevated to a more interactive role for specific situations.
    • They are a good feedback resource regarding site navigation- if an occasional user experiences frustration navigating the site, it needs to be re-thought.

Define success factors- How will you know if your group is using SharePoint successfully? What will the indicators of success look like? Define measurable success criteria BEFORE launching the site/solution. If your site/solution does not support the criteria you have listed, you have a problem!

  • For example:
    • Problem: Team members are constantly email-requesting current presentations from the team PowerPoint author.
    • Solution: Centralize presentation storage in a versioned document library. Train users on the new process.
    • Success indicator: Track email request levels before/after implementing the solution. Did they drop? Are users self-serving from the library? You’ve got a success metric.

Encourage feedback on site performance and user experience.

  • Have some early adopters create good-quality, substantive feedback early on, so that others have an example of what you’re looking for.
  • Periodically send out a simple user survey: “As a result of using SharePoint, I am better able to… ”
  • Share those responses to see if others can benefit from the gains. People support what they help to create!