Two years ago, I read an article titled ‘What makes a good SharePoint Analyst?‘ This was around the time I met Michal Pisarek so I assumed that a SharePoint Analyst was someone who talks about SharePoint a lot.
While that’s only half true, below are some more thoughts on this topic from recent observations and in addition to the characteristics that Michal introduced in his article 2 years ago (leveraging the platform; act as an advisor; the importance of technical and personal skills; demonstrating passion, compassion, restraint, sense of humor, and humbleness). Some of these are not necessarily unique to being a SharePoint analyst but characteristics important for many professionals in IT.
SharePoint is the domain, you are the Analyst
SharePoint or not, an analyst must define and plan the requirements gathering and management approach; identify who the stakeholders are and use requirements elicitation and analysis techniques appropriate to the project and the audience.
A SharePoint Analyst isn’t as much about finding ways an organization can use the tools and features available in SharePoint, but rather how SharePoint can support an organization and its processes, people, information, policies, and procedures. In other words, it’s about the business first and what role SharePoint plays in facilitating the things that people need to do at work every day. Whether it’s a contract approval process or a records retention policy or using metadata to identify and organize documents, you need to find the best way for SharePoint to accomodate the requirements.
Your expertise in the SharePoint domain is a combination of your experience, expert judgement, knowledge of the technology and knowledge of the industry it is operating in (E.g. energy, healthcare, education etc.).
Be a problem solver
To solve a problem you must first define and understand the problem. It is then your role to identify the solution alternatives, communicate the trade-offs with each alternative, ask lots of questions, challenge assumptions and help stakeholders make the necessary decisions.
When SharePoint out-of-the-box features are not enough to satisfy the requirements, there are a few options. Look for workarounds and/or facilitate a buy (use 3rd party tools) vs. build (custom development) decision and communicate the benefits and trade-offs for each alternative. This all comes down to knowing how important the requirement is and how much the business is willing to invest.
Ask questions and communicate
At a high level, you should be able to answer the following questions and communicate them effectively. By no means is this a complete list and as always you have to ask even more questions in order to answer these questions! You may not (or should not) be the only person coming up with the answers, but in order to communicate requirements, assumptions and measures of success, these are some of the things that need to be understood by everyone involved on the project. The method of communication could be formal, informal, documented or verbal (or a combination) – whatever works for your stakeholders.
- Who are the stakeholders and what is their involvement and influence level?
- What is the problem we are trying to solve or the opportunity we are trying to promote?
- What is the gap between the current capabilities and the solution objectives?
- What are the high priority requirements (the key things this solution must deliver)?
- What are the main benefits this solution will provide?
- How can we measure the success of our SharePoint implementation?
- What should we measure? What are the assumptions? (Assumptions are present at every level. These are the things you believe to be true but has not yet been confirmed)
- Which requirements cannot be delivered and what are the constraints preventing it? (technical or business)
- What are the impacts to the business? (these are financial impacts, impacts to process, technology and people/roles etc.)
Be a teacher
Whether you are the Business Analyst, SharePoint Analyst or SharePoint Business Analyst; chances are you’ll also be required to provide training, demonstrations, prototypes or proof of concepts to gain buy-in and solicit early feedback. This includes showing stakeholders how to use a completed (or semi-completed) solution to solicit input or even providing training on basic SharePoint capabilities (tailored around key end-user tasks) to gain comfort with the technology. The more your stakeholders understand and are comfortable with the solution, the better the feedback, which leads to better requirements and a better solution.
Just like any good teacher, it is important to know how your students (in this case, stakeholders) learn new information and tailor your training and communications accordingly (visual learners? learn by doing? learn by reading and hearing?). Don’t teach them everything there is to know about SharePoint (it’s your job to know the technology), but teach them how to perform their key tasks and find the information they need to do their jobs. SharePoint just happens to be the platform they are using.
Be a student
While the organization and end users are learning about SharePoint, you are learning about the organization. No implementation will provide value if you don’t learn what value means to them. This is often different for every organization so don’t assume you know this better than they do. This is dependent on the problems and opportunities the business is facing and the ones that provides the most benefits and has the highest impact.
Learn the current capabilities of the organization to understand what additional capabilities are required in order to meet the objectives. Be aware of the organization’s industry, culture, offerings (products & services), infrastructure, organizational structures and operational processes and policies (regulatory and compliance requirements). Under every rock there will be information that adds to your requirements. I’m not suggesting you turn over every single rock, so know which ones you’ll need to explore as part of your project scope. Find the people around you that can provide this information (you’ll meet a lot of people along the way!).
At a more granular level, learn what motivates your end users and key stakeholders and how the organization gets things done. As much as possible, learn and use the terminology and jargon that the organization understands.
Knowledge of these elements help you understand the constraints, assumptions and boundaries of the solution.
All of the points above lead to building trust. A SharePoint implementation involves change (big or small) that impacts how people work. For this reason, the SharePoint analyst is an agent of change. You are in a role to influence behavior, overcome resistance and address concerns.
Love SharePoint! Love it for what it is and what it isn’t.
Knowing what SharePoint is and what it isn’t frees you from the idea that this needs to be exactly perfect for everybody or solve every problem. Look for the high impact items as well as the “quick wins” that will leverage SharePoint in the right way. It also allows you to perform all of the points above effectively. Afterall, what makes you an expert in the SharePoint domain is how well you know the product and its capabilities and how well you can marry the strengths and constraints of the system with the strengths, weaknesses and boundaries of the organization.