This article assumes that SharePoint has already been established as the technology of choice. If your project includes evaluating whether or not SharePoint is the right technology for your solution, this article may only partially apply.
There is a lot of room for interpretation on what a “SharePoint Business Analyst” actually is. For this article, I am referring to what I am seeing in the market for people with this job title currently. This job role usually includes a mixture of:
- Meeting with end users to recommend solutions to business problems that could be built upon SharePoint & related technologies
- Creating and gathering business, functional, testing, design & technical documents
- Being a minimum of a “power user” with SharePoint, and sometimes even being a light-weight administrator or developer
- Working with stakeholders and end users through the full life cycle of a SharePoint project from beginning to the final implementation (sometimes even managing it in regards to scope creep, budget, timelines & more)
- Being the liaison between the administrators, developers, managers, end users, and others (sometimes an external consulting company, 3rd party vendor or offshore team)
As SharePoint software is reaching a more mature state in organizations, I have personally found that the SharePoint Business Analyst is becoming more involved in adding functionality on top of or fixing issues with an existing environment. If you are one of the fortunate few who are working on a brand new, full trust farm SharePoint 2013 installation with shiny new servers, this article may apply only somewhat to you. However, feel free to give me a call so I can come work with you instead of cleaning up the never ending mess I did not create at my current job! 🙂
All kidding aside folks, here are my thoughts on what are the most important keys to becoming a great SharePoint Business Analyst.
1. Know Your SharePoint Environment
Personally, I think this is one of the most important keys to success. I ask, “why dangle candy in front a of a child if they can never have it?”. Yes, it usually is the job of the SharePoint Business Analyst to recommend new solutions or improvements using SharePoint. However, if you do not know what version you have, what the infrastructure set up is, what you are allowed to do based on IT governance or what already may exist from previous customizations, you might get user’s hopes up for something that will only lead to disappointment. Here are a few examples:
- “I saw that new continuous crawl feature in SharePoint 2013 so we can see all of your uploaded documents almost instantly now” – Not if you are using Office 365 or have an old, slow server.
- “We can create a workflow that will copy pages to other sites based on which boxes you check on a form” -The offshore development team returns your project with a SharePoint Designer workflow. The issue is your IT administrators don’t allow anyone to use SharePoint Designer in the environment.
- “We can buy this 3rd party translation product to use on our SharePoint site” – The 3rd party product works great if you have variations turned on, now if only you weren’t using language packs instead of variations.
Learning your environment might not be an easy task. The people who have worked on it may no longer be at the company, there might not be documentation and sometimes IT can be a bit difficult in sharing knowledge. Do what research you can and be politely persistent. If a project turns south and you are involved in it, there will probably be some blame that comes your way. Try to prevent as much of that as possible.
2. Know SharePoint Back to Front & Front to Back
Alright, so I know this is far, far easier said than done. Even after five years or more of working with SharePoint I have much to learn myself. However, it is a weekly commitment of mine to continually learn as much about the product as much as I can. I strongly believe you cannot make informed recommendations to users if you do not understand the product itself and how it operates. Also, and although it will take time to learn, I believe that understanding what the limits of functionality for each of the following will be helpful:
- What can be done OOTB (Out of the box)
- What can be done with no code solutions such as SharePoint Designer & InfoPath
- What 3rd party products are out there
- When you will have to use custom code
The good news is that there are so many resources available to learn SharePoint now that it really boils down to commitment and time on your part.
3. Wear Many Hats, Relate With People, Keep Your Cool and Give “props”
As you probably know by now, projects never really go according to plan. I think you should have some experience in each role of SharePoint, as depending on the day and issue, you may be changing hats or playing a different role. It is also a beneficial skill to be able to socialize and chat with people to build rapport and calm nerves when issues arise. Being able to keep your cool when things such as “we just realized we installed the entire SharePoint farm with the wrong Active Directory domain name and need to start from scratch” happen.
Also, give credit where credit is due. I will never forget the time I was leaving a SharePoint user group and there was a manager talking to recruiter saying “Yeah, SharePoint developers are a dime a dozen and I need one” as the recruiter shakes his head in agreement. Don’t forget to give “props” (credit) to the people who really made the work happen. Unless there is some specific reason that one would need to not disclose there is an external resource working on the project, I like to make everyone feel included and appreciated for their work. I have often seen a manager come in and take credit for an entire project when they have done very little of the work.
4 . Know Your Primary & Peripheral Audience / Stakeholders
I think that a lot of people try to get their audience for a project correct, but I have seen a difference between the primary audience and the peripheral audience / stakeholders. For example, if we are building a project and we have met with the IT administrator, the developer, the end users and person approving the budget, we might think we have covered everyone that needs to be involved with our project. How about when the Director of IT, whom you have never met, suddenly shows up out of nowhere 6 months into your project declaring that you should cease all work and communication with a vendor because he wants to go back and renegotiate an already signed agreement to save money. First of all, this really happened to me (sadly). Second, people that make big decisions that you don’t realize could have an effect on your project are what I refer to as Peripheral Audience Members & Stakeholders. I have tried to take into account their potential effects on my projects going forward.
5 . Consider the Past, Present & Future
If it is one thing I have learned, users will have no issue blaming you or IT for issues that occur even if it is long after you are gone or not directly your fault. Understanding the user’s needs now, understanding what existed in the past and where they hope to go in the future should all be considerations. A couple examples of this are:
- Search in SharePoint 2013 is great, but if the long term plan is to start indexing file shares and other external sources of data to create one unified search experience over time, are you sure the budget to build the server infrastructure to support this is available? If the search becomes slower and slower over time due to overload from crawling, queries and index sizes people will most likely start to complain.
- If the company has a need to retain previous versions of documents for compliance or legal reasons, versioning might be a great idea. However, versioning takes up a lot of storage in the SQL database. Making sure you are going to have that hard drive space available without having to do a massive migration would benefit everyone.
6. Getting Stakeholders and End Users Engaged and Involved
Yes, sadly, most everyone is tuned in to their favorite radio station Wii.FM, also known as “what’s in it for me”. I am always amazed at how users will be working with the project you are building for them to use for the next however many years, but they can’t find 1-4 hours of their time to help build and test it. Obviously getting a user engaged and making “helping” them to understand how the project will impact them is important. It is also another huge risk for project failure if stakeholders have not been involved or engaged before the project implementation and development begins. I recently attended a session at SPTechCon where Michelle Caldwell shared some great ideas on how to gather requirements for SharePoint via Collaborative Play, Innovation Games and Gamestorming which could help.
7. Extracting What a User Really Needs and the Real Value
It is true that stakeholders and end users may not always know what they want. Some analysts use tools like Mind Mapper, XMind & Balsamiq to help draw mock ups and generate ideas. Many times they are looking to you, as the analyst, to make recommendations based on what SharePoint can do. They might not think about the time savings in electronic forms or being able to categorize items with managed metadata. Show them the benefits the technology can produce for them.
There will also be times you will need to balance the user’s needs for little things that are only important to them vs. the greater objective of the project and the inevitable time and budget. I have personally seen stakeholders battle over the color of a font for weeks and I am thinking “How many thousands of dollars did we just spend deciding to make this yellow?”. I am all for great design and user interface, but sometimes decisions need to be made and if there is time and budget for a second phase those items can be addressed later.
8. Don’t You Dare Start Building that Project Without a Flow Chart, Functional Design, Clear Definition of Success or Technical Specs!
Sometimes initial business requirements can be written in generic statements regarding what the solution you are creating will accomplish. For example, “the application will send the document owner an email upon final approval in the workflow” is a nice business requirement. However, “interpretation” is best left to dance and the Supreme Court, not your SharePoint projects. Here are a few examples of where the importance of having the complimentary documentation to business requirements will help:
- “The final approver of the document rejected it, so no email was sent.” – A flow chart might have prompted concern when the user sees an arrow for a decision point that goes nowhere.
- “The email didn’t include the date of the approver, how long it took for the document to be approved, the reference number and my life story — oh and I want the third word in the email to be hot pink.” – Technical specifications and functional design documentation go into more detail about exactly what will be built and how it will be built.
I almost always include pictures of mockups or diagrams in my requirements. If possible, I even try to create partially functional demos. I find a visual representation of what one is creating triggers something in people’s minds that words simply do not. One other note, perhaps in some situations where you are working on small projects or changes, not all of this documentation will be necessary and it can also depend on your audience.
9. Testing is not Fun, but it is Necessary
It is true I don’t get up in the morning, jump out of bed and shout “I get to do UAT today!”. It is definitely the last step in setting your ship to sail however. It is good to have proof that the items were checked to be according to specs, that there was no human errors on your part and that any of those little “misinterpretations” are cleared up. Once again, try to get sign off that each user involved has completed the testing scripts. When I write UAT scripts I usually try to make each one go back to an original requirement as proof of task criteria being met. UAT is also a great time to noodle in some training so your stakeholders will know how the system will function at a very specific and detailed level. You may also want to hold separate training sessions as well.
10. Wrap it Up With Sign Off and Some “Touchy Feely” Stuff 😉
When a project is coming to a close everyone can feel drained and tired (or at least I do). However, always get final sign off from the stakeholders that the project has been successfully implemented and completed. Thank everyone for their efforts on the project on the phone or in a group email or however you like. Leaving a good impression makes, well, a good impression.
I understand that their will be differing opinions on this article, so feel free to take away what you feel is important to you and leave the other parts behind. I have only listed a few key traits I have learned in this article. I could go on for days (weeks even maybe) regarding everything you could learn to be a great SharePoint Business Analyst. Hopefully these items will get you going in the right direction and when you have a good understanding of them you can continue to learn more in the future.