In organizations that utilize or want to utilize SharePoint, the name itself has many meanings, from the CEO down to the data entry folks. But for all of them, the level of passion is the same, whether positive or negative. So, how do you manage this in your organization?
You must become a geek interpreter. I will define this and provide three tips in order to attain this qualification.
First, a Geek Interpreter does not have to be the technical person or the business analyst working on the SharePoint project. Sherlock Holmes would have made a terrific geek interpreter. He solved mysteries through deduction by analyzing the facts. The mystery in your organization is determining what needs to be done by SharePoint. Analyzing the facts is the skill.
Put another way: We are all Geek Interpreters, and if you do not have the skill today, you must acquire it and foster it within your organization. I guarantee your SharePoint implementation will benefit.
Market penetration and brand awareness have made the term SharePoint part of the lexicon of many businesses. This is great for Microsoft sales, but as SharePoint evolves, matures and splits into different platforms, I see all levels of business using the word “SharePoint” as a crutch. This is a huge issue, because from being a crutch, SharePoint often devolves into being a scapegoat.
Defining “crutch” in terms of SharePoint is simple. The very term “SharePoint” symbolizes to users why a project did not succeed, how a project should be built, or how it is a solution to a problem. But SharePoint should be none of these things.
Remember, the true function of a software tool, whether it is an app on your iPhone or enterprise software such as Project Server, is to solve a business problem. An encouraging sign in this arena is how speakers are approaching the breadth of SharePoint technology at SharePoint conferences. I see more and more that technology is spoken about in terms of the business problem: the use case.
The best method for explaining my tips for becoming a great Geek Interpreter is through true story examples:
True story #1: I was at a customer site last year doing requirements gathering for an upcoming SharePoint implementation. As I spoke about what the customer was looking for, I was told that they could not tell me until they understood the limitations and possibilities in SharePoint.
Geek Interpreter Tip #1: When gathering requirements, do not even mention SharePoint. Take it immediately out of the equation. Talk about the business pain point they are trying to solve. Folks can talk about this all day long. Soon, they forget all about SharePoint and stop wondering what it can do, and instead focus on how their job is in some way obstructed, whether it is by technology or the lack of it.
True story #2: You walk into your boss’ office, and he lets you know what a great new tool he has seen that is going to solve all his dashboard woes. It is called PerformancePoint.
Geek Interpreter Tip #2: After politely listening, explain to him that in order to get started on the technical solution, you will require the following: a whiteboard, a pen, and him (or her). Once you have these, ask him or her to sketch out his or her dashboard design. This does three things: It takes the technology out of the equation; it focuses him or her on the mechanics of how the data is surfaced; and it forces him or her to begin with the end in mind (Habit 2 in “The Habits of Highly Effective People”).
I find the last statement to be key in all my engagements. What is the end vision? Draw it out, literally.
True story #3: A few years back, I performed one of the very first SharePoint Deployment Planning Service engagements at a very large enterprise. Following Microsoft’s guide, I went into a SharePoint 2010 feature overview right after introducing everyone. This caused the engagement to become immediately sidetracked: The customer wanted to delve into the features and see which of them they could use.
This is done in the sales process, not in delivery. Even Microsoft’s delivery method for partners is skewed. A customer—your boss—calls us because there is a business pain point (see Tip #1).
Geek Interpreter Tip #3: It is inevitable that some customers want a show. Use a multi-sensory approach; stimulate them visually, verbally and hands-on. When I encounter this, I immediately use a whiteboard with a SharePoint site projected onto it. I have the customer write over the site, showing me how they would like to use it.
The auditory process is simple: I listen. The sale is done; I do not have to dazzle the customer with my knowledge. I have to listen to their needs. Another way to interpret this tip is:
a. Involve the customer
b. Get out of the way (listen)
This is your start at becoming a Geek Interpreter. Good luck and remember: It’s elementary, my dear Watson.
Peter Serzo is a published author of the “SharePoint 2010 Administration Cookbook,” a founder of the SouthEastern SharePoint group, a speaker, and SharePoint Architect for High Monkey Consulting. Peter has been in the IT industry for 20 years. He has extensive experience with SharePoint implementing business solutions for several enterprise organizations over the past seven years.
