The BA role, whether we call it that or not, is relatively clear. The BA is a communicator, liaison and information source. There is less clarity about who plays the role and where that person reports in the organization. The questions that must be answered are: how will the communication take place; who will facilitate it; who is responsible for the result; where that person reports in the organization and in the project management hierarchy; how much architecting, advising and designing is involved; and how much knowledge of the business context and the technology is required?
To answer some of these questions we must answer two related questions “Who has the capability and the time to do the BA work?” and “What kind of communication is needed?”
The BA role as defined requires the ability to communicate requirements in a manner that makes them objectively clear to the people who will deliver the product. This implies that the communication must be structured in a way that articulates a big picture view of the product’s context, its relationship with its environment, purpose and benefits, and then articulates requirements in layers of detail.
Whether this is done based on relational, object oriented, process oriented or physical component perspectives depends on the situation. Usually multiple perspectives are required. As requirements become increasingly detailed they require more time and effort to define. As the product is more complex there is need for more skill and discipline and a higher level of proficiency
An ideal candidate for the BA role is a subject matter expert who is operationally tied to the product. In IT application systems development projects, it might be a middle manager who lives and breathes the process that is to be automated and can write the structured requirements, perhaps using templates and questionnaires.
There are two problems in finding such a person. One is that the operationally tied subject matter expert is probably very busy doing his operational job and budget restrictions will not allow pulling him out for a few weeks to write requirements. The second is that there are many highly competent operations managers and business subject matter experts who would require significant training to be able to write effective requirements. While the BA skill set is learnable there is a certain thinking style that makes the learning easier and quicker.
So, if we can’t have the ideal, then we look for a practical alternative, a professional BA or perhaps systems developers or technical managers with communication and requirements writing skills and an appreciation for the business and for the technology and its place in the business. Perhaps it is a team of them and a process engineer and the business person, where the BA is facilitating and taking the burden of doing the writing and drawing from the others.
Where does the BA sit in the organization? I have been in the IT and process management field for decades. Even before they were called Business Analysts there has been controversy over whether BAs should report to an IT organization under the CIO or to the business under the COO or division and department managers or to a process engineering/BA group reporting to the CEO.
There has been movement from one model to another and back again. There is no one right answer. Each organization and each project team must decide on the best mix for their circumstances based on the capabilities and availability of the players to clearly articulate useful statements of requirements.
Don’t forget to leave your comments below