Already have your technology selected? Then doesn't it make sense that your BA have good working knowledge of it, making the transition from requirements development to design smoother?
The Business Analyst Role is Changing
Due to the increasing expense and complexity of modern content management systems, organizations often make strategic decisions to use a single software platform throughout their business operations. A platform may be selected by one group, and then expected to be reused in various systems by means of separately ran projects. It may not be ideal, but very often a new website, or intranet, will have a technology solution in place way before the requirements stage has been completed, or even considered.
As a result I am going to announce the classic ‘business analyst’ (BA) role dead, with no place in many large scale enterprise projects. Gathering business requirements in isolation, and ignoring the delivery platform, is an ideal that just isn’t going to work with many projects anymore.
Consider the SharePoint "BA"
Let us take SharePoint as an example. This is a huge software platform, one that offers a wide range of tools to solve all kinds of problems in a number of different ways. But as anyone familiar with the platform will be aware, it has its own way of doing things, and its own quirks. Data will be stored in lists, pages will be laid out with rectangular web parts, document management and office integration will be strong, content layout and accessibility less so.
The traditional BA job role is too narrow, too technology agnostic, to be successful in this environment. The BA, or let us now call them the ‘SharePoint consultant’, needs to understand how to use the platform to best solve the problem. They need to ‘shape’ the requirements gathering phase in such a way that the best solution is developed using the chosen software.
That is not to say the technology should lead the problem discovery phase. But there is a need to be realistic. If somebody requests a feature that will take great cost to build from scratch, then it is probably not going to make the cut (not if your project budgets are anything like mine). If 90% of their request can be fulfilled using out of the box code then isn’t this a worthwhile compromise?
The BA Role Expands in SharePoint
We can take our remodeling of the old school BA much further. A ‘SharePoint consultant’, with their in-depth knowledge of the platform, should be able to carry on with the project into the ‘build’ phase. They don’t need to go as far as get their hands dirty with code, but a system like SharePoint will allow them to ‘configure’ functionality and content a significant degree themselves.
Using the interface, or power user tools, they are able to bring to the solution to life themselves. No need to write often ambiguous, specification documents or rely on traditional development cycles. A version of the solution can be built, working directly with the client and often on site.
This uber agile way of working puts the solution in the hands of the client far quicker than any other approach. Again it may only be ‘90% complete’ version of the system, but the immediacy of the solution may be a worthwhile compromise.
So our SharePoint consultant can now:
- Collect and develop business requirements, acknowledging the solution platform
- Design the solution, identifying the need for custom development work as required
- Configure the system on site with the client, using as much out of the box functionality as they deem appropriate.
Not only is the use of one person across these roles more cost and time effective, but it also reduces (mis)communication issues. The fewer people involved in a complex project like software design the better.
The BA is dead, long live the "SharePoint consultant!"