According to industry figures, about 80 per cent of errors in software development projects are introduced at the requirements-gathering stage and business analysts often find the finger of blame pointing at them.
Why do business analysts get it so wrong? Many reasons have been suggested but the common thread is the lack of good communication.
In a software project, the role of the business analyst is to establish, analyse and document the requirements.
There are many techniques for eliciting requirements but the assumption is that the users know what they want.
My experience suggests that even if the users know what they want, they do not necessarily agree.
Frequently it is the role of the analyst to question the business case and challenge the requirements.
This needs courage and skills of diplomacy that many analysts do not have.
So now the analyst has a specification that maybe he or she understands but few others do.
The business users will agree the specification without understanding it but they will hold the analyst responsible if it does not fit the bill.
It is easy to see why business people distrust IT. If you received a system late and over budget, you might find your trust ebbing away.
And if the system does not deliver what you asked for, the analyst’s credibility slips further.
Trust must be earned through successful delivery.
So should we shoot the business analyst? I don’t think so.
Their only folly is believing that users understand the models they create and that is because the users tell them that they do.
The whole business needs to accept its part in project failures. Business analysts must understand there are no magic bullet modelling techniques and should test the users’ understanding rather than just accepting their word.
Perhaps the surprise is not that 80 per cent of errors occur at the requirements-gathering stage, but that the figure is not much higher.
Stewart Armstrong is a BCS contributor
Opinion: Should we shoot the business analyst?
By Stewart Armstrong on Feb 6, 2009 6:45AM