(a previously undiscovered fable by Aesop)
A long time ago, before Business Analysts existed, it was believed that people in the business would be able to define their own requirements.
When a business department wanted to have a new piece of software, they would go to the IT department and the developers would ask them what they wanted. The business people would express this as best they could by writing down lists of things and having meetings to explain them, and then the IT department would build or buy whatever they seemed to want.
But a number of problems would almost always emerge. These could usually be divided into three main areas:
- It was sometimes difficult to decide exactly who ‘the business’ was. The people visiting the IT department on behalf of a particular business area would all be at different levels of seniority and would sometimes have very different ideas about what was needed. The IT people would start out on one track, and then have to change everything because the next person they spoke to said something different. Sometimes, when they’d finished a piece of work, it turned out that the most senior business person hadn’t been involved at all, and refused to accept the end product.
- People in the business weren’t always very good at expressing exactly what they wanted. They would write a few ideas down in lists, but sometimes these were contradictory, and quite often things were missed out that turned out to be important later on. People often seemed to concentrate on what was ‘going wrong’ with their current way of working, and didn’t necessarily express what they really needed as an end product. It also turned out there were usually ‘hidden needs’ which were not obvious at the beginning, and only became clear when it was too late to include them.
- Sometimes, especially where the new software was going to be used by more than one business area, there was conflict between what different people said was needed. Usually the IT department just tried to please everyone, but quite often this was impossible, since the requirements could be in direct contradiction with each other.
This caused a lot of problems for IT departments in general, and they went about solving these in several different ways. One way was to say that it was the project manager’s responsibility to get together a decent set of requirements for the developers to work with.
The trouble with this was that the project managers didn’t really know how to approach the problems any more than the developers did, and they certainly didn’t have the time to do it. They usually tried to solve it by insisting that the business produce a formal list of requirements by a certain deadline. This still left the problems pretty much as they were before, because although there might be a document with the requirements in, there was no guarantee that everyone had contributed to it or that the items were really the right ones.
The other way of solving the problems was for the IT department to invent a mythical, ideal world where the people in the business behaved exactly as they wanted them to, and then insist that this world should be true. They would say, over and over again throughout every project, that everything would be all right if only the business would tell them exactly what they wanted, in clear, unambiguous language after resolving their conflicts first. This didn’t solve the problems of course, because the business didn’t have the skills to fix things any more than anyone else did, but at least it gave the developers a chance to get their feelings off their chests.
At last, after this had been going on for a very long time and projects kept on failing, there began to be a group of people who specialised in exactly the skills needed to define requirements accurately.
They were called Business Analysts.
Although they had the word ‘business’ in their job title, they weren’t the same as the people who worked in the business areas. They had very specific skills that they needed to be trained for. These particularly included:
- analysing a business area to find exactly the right people to talk to about a problem
- getting to the bottom of what ordinary people were trying to say, and expressing it in language that developers could understand
- getting together in a room with a number of people in conflict with each other and helping them to resolve the conflict.
Sometimes the Business Analysts worked in the business areas, but more commonly they worked in the IT department so that their skills could be used for any business area that needed a piece of software.
When Business Analysts started to get involved in a project from the beginning, it was discovered that a project had a much better chance of succeeding. Conflicts were resolved at the beginning, the requirements were expressed in clear, precise language, and everyone in the business area felt involved. This meant that the software that was bought or built matched what the people in the business really needed, and everybody was happy.
And that is how the Business Analyst was born.
Author: Gillian Metheringham, Senior Business Analyst with West Sussex County Council. Gillian has been working as a business analyst or project manager for about 20 years, in both the UK and the US.