Banner Advert
Chris Wright
Posted on June 20, 2012 by
3 Comments

Business Analyst number 1

A good business analyst will ignore any technology that will be used to develop the eventual solution. During requirements gathering they will focus on the problem space, ask lots of questions, and document what the client wants in terms of use cases or user stories. The technology will not come into it until later, when a more technical resource will work out who to build something that meets the requirements.


Business Analyst number 2

A good business analyst won’t bother the client with the technology that will be used to develop the eventual solution. They will gather requirements, but be constantly thinking in their head how they the technology will meet the needs of the problem. They will use their skill to ‘shape’ the requirements (openly or not depending on the type of client) so that the project can be delivered ontime/to budget by the technology in mind.


A SharePoint Business Analyst 

A good SharePoint business analyst will actively discuss the technology that will be used to deliver the solution. They will gather requirements, and understand the specifics of the problem. But they will also be upfront about SharePoint, and how it delivers certain functionality. They will be frank about adopting out of the box functionality as and when it is suitable. They will also gather requirements that suggest custom code being written, but try to define the problem in terms of SharePoint concepts and fundamentals.

The job of a SharePoint business analyst is that of a delicate balancing act. On the one hand they need to do everything required of a traditional BA. They need to understand the problem, and effectively gather requirements without bias. On the other hand they know they will be using SharePoint to deliver the solution. They understand SharePoint limitations, its core functionality, and they know how best to put it to use for various problems.

That is why a good SharePoint business analyst is worth their weight in gold!


3 Comments

Jim Ehrenberg on June 26, 2012

So true and necessary for expectation management!

BA masterclass – #018 – You don't need to get 100% of the client's requirements – The Microsoft SharePoint Blog on July 3, 2012

[...] rescue. As you will know SharePoint is a fully fledged project with its own expansive feature set. Just as you should consider the platform throughout requirements gathering, you can use the SharePoint feature set to short cut defining [...]

BA masterclass – #023 – The 3 SharePoint terms to use in your requirement gathering – The Microsoft SharePoint Blog on July 16, 2012

[...] are a BA, but you are also a SharePoint BA. This is a tricky juggling act. We have already decided you should be frank and talk about SharePoint, as a technology, in your requirements gathering. But [...]

Add a comment