No one wants to be seen as someone else’s stooge, not even a business analyst, which I consider myself to be (among other things).
But this, I feel, is often the way BAs are seen by others. The reason for this is often where the BAs are situated within their organisation. In fact, the question of where organisations should locate their business analysts seems to have become quite a hot topic recently. Only a few days ago the question was asked in the Modern Analyst.com group on LinkedIn, and the question has come up time and time again among my own network of colleagues both past and present.
I was fascinated by the initial premise that some of the respondents used to answer this question on LinkedIn — that the primary role of a BA is to act as a bridge between the business and IT? Is it really? Surely, it is to accurately and impartially elicit and document business requirements. And, assuming that this is indeed the case, then BAs should be embedded within the business to the greatest degree possible, and kept out of either the IT department or the Programme Management Office (PMO).
In my experience, there is a danger that BAs who are located in an organisation’s IT department become compromised when eliciting and documenting requirements. Almost without pre-meditation or conscious thought, they find themselves immediately trying to estimate how the existing IT systems and processes could facilitate an expressed requirement.
While this may seem a good idea — even a productive one — the end result is that the elicitation and documentation of requirements become biased in favour of those requirements that can be certainly (or perhaps possibly) facilitated by the technical status quo. Requirements that cannot be satisfied by the existing systems, and especially those that challenge the organisation’s existing technical orthodoxy, are downplayed, de-prioritised, or even ridiculed.
The eventual fate of the BA is that he or she, within the business, becomes associated with a “can’t do” attitude, and is seen as a block to progress and innovation — a stooge of a conservative IT hierarchy. All this might be very unfair on both the BA and the IT department for which they work — but, that hardly matters when perception is more important than reality.
The inherent problems associated with placing BAs in IT seem to be one of the reasons why they now often find themselves located in the PMO instead. But, the same problems of compromise exist. The BA who is answerable to the PMO will likely, and again almost without pre-meditation or conscious thought, find themselves immediately trying to estimate how an expressed requirement can be realised within the existing budgetary and temporal restraints of a given project, programme or process. Again, elicited requirements that challenge these orthodoxies will be de-emphasised, and the BA will become viewed in the business as the stooge of the PMO.
Of course, prioritisation, an assessment of technical fit and capability, and time and cost implications are vital considerations, but to the BA they should not come first, before the real requirements are honestly elicited and documented. And, apart from prioritisation, I would contend that these tasks are actually better carried out by technical architects and project managers anyway.
So, where to put the BAs? The idea of a RMO — a Requirements Management Office — is an enticing and exciting one, but it would seem to me to be possible only in the largest organisations. I have often wondered why BAs are not located in the planning, strategy or CEO’s office. These seem far better locations for BAs than either the IT department or the PMO.
But, wherever located, the BAs should always be sent out into the business whenever possible, and see themselves primarily as the impartial elicitor and documentor of the business’s requirements, unfettered by the compromises of IT, the PMO or the CEO.
Ultimately, the answer might be for most organisations to stop directly employing BAs at all, and instead outsource the work of eliciting and documenting requirements to external consultants. This would seem to have two major benefits: firstly, the BAs so engaged should, if managed and deployed correctly, owe allegiance to no particular special interest in the organisation; and, secondly, the organisation need only engage BAs when required, potentially realising considerable cost savings.
Related reading (from Amazon.co.uk):
- Business Analysis, by Don Yeates
- Mastering the Requirements Process, by Suzanne Robertson, James C. Robertson
- Requirements by Collaboration: Workshops for Defining Needs, by Ellen Gottesdiener
