Back when I worked in a telecoms company, there were various well-defined roles – system engineers, software developers, testers, support engineers, and project managers. We never used the term ‘Business Analyst’. Later, when working for Aspira and dealing with lots of different industries, it was a role that I heard mentioned a lot, although I noticed that different organisations seemed to define the role differently.
Some organisations seemed to consider a Business Analyst to be a System Tester – someone who would be familiar with system requirements and carry out detailed testing against those requirements. More often, organisations suggested the main responsibility of the Business Analyst (or BA) was to define and document the requirements and then hand them over to the system developers. A few organisations used the BA role exclusively to carry out Business Process Analysis, identifying the “as is” process and defining the “to be” process as part of managing change projects. Some organisations seemed confused about BAs versus Project Managers often using the same people to fill both roles. In order to figure out how to join this secretive Business Analyst club, we first need to understand how to define the role.
At its simplest, the Business Analyst role is to elicit and define requirements, whether that solution is a technical system or a business process. This means pulling people together to figure out what the desired solution needs to do, so the ability to run workshops and organise people is important – a trait the BA shares with Project Managers. Once the BA has completed the requirements definition it proves really useful to have the BA then review the Testing Strategy. This ensures that the Test Cases will give the solution a comprehensive verification and validation prior to the solution ‘going live’.
So it’s easy to see why different organisations emphasise different aspects of the Business Analyst role – it is a very wide-ranging role. What I find interesting is that it is a role that has historically been under-resourced. When Aspira are asked to take over a troubled project and recover it, one common theme we see is that the project’s requirements have not been clearly defined. No project can ever deliver against requirements if nobody knows what those requirements are. I know that sounds obvious, but I bet you can think of some projects you’ve worked on (or are working on!) where there was no proper set of requirements.
What do I mean by “proper” requirements? There are seven criteria that need to be met before I am happy with a set of requirements:
“Some organisations seemed confused about BAs versus Project Managers often using the same people to fill both roles.”
The Secret Seven
Comprehensive: Requirements must be detailed. If you were building a house, would you agree on a specification that just states “a bungalow”? No – you would want to specify the size, the aspect, the number of bedrooms and bathrooms, the build quality, etc, etc.
Complete: Requirements must be all-encompassing, covering all aspects of the solution. This means including both the functional requirements (e.g. the use-cases) and the non-functional requirements (e.g. the level of performance required, the level of data security required).
Coherent: The Requirements must be understandable and make sense. Some people go on an ego-trip when defining requirements and use loads of technical jargon that may not be understood. It is important that the people who will be using the requirements to design and build a solution can understand those requirements.
Testable: A good requirement has to be testable, otherwise it shouldn’t qualify as a requirement. We have to be precise enough in our terminology that when a tester goes to write a test case, there should be no ambiguity. The system either does or does not meet the requirement – there is no ‘in between’, and this should make our tester very happy! Ambiguity exists when a requirement can be interpreted to mean different things. Multi-Billion dollar international space exploration projects have failed because of people specifying distance in numbers but no units. The French team assumed it meant metres, the USA team assumed feet. When I moved to Cork and asked if it was possible for an engineer to deliver a piece of functionality, I was told “I will, yeah”, so that was great… I thought. I have since learned that “I will, yeah” is Cork ‘slang’ for “No”. So be careful to define your requirements clearly and with zero ambiguity so that they can be tested.
Realistic: While I may yearn for world peace and to end world hunger, it is unlikely that my next project will achieve such lofty targets, so it would make no sense to state them as requirements of the project. Any requirements specified must be realistic achievable, not a fantasy wish-list.
Achievable: Part of the Project Manager’s job is to balance the project constraints of scope, cost, time, and quality. The Business Analyst’s role is to define the scope into a set of detailed requirements. But that should not be done in a vacuum – the BA must check what the expectation is for the project schedule and budget, and aim to define a set of requirements that can be delivered in line with those constraints.
Non-Conflicting: It’s easy to spot conflicting requirements for a small project – if you are told to meet “a tall, small, dark stranger” you will immediately seek clarification on whether the stranger is tall or small. But if you have a list of hundreds of requirements, or if you are passing on those requirements to a bunch of different people to implement, it is quite possible nobody will spot the conflict and will build a solution that doesn’t work. So it is up to the Business Analyst to ensure that the requirements are all in alignment and do not contradict each other.
“A good requirement has to be testable, otherwise it shouldn’t qualify as a requirement.”
Internationally Recognised Standard
Over the past few years, the role of the Business Analyst has become much better defined and standardised. An international body, called the International Institute of Business Analysis (IIBA®) has defined the Business Analysis Body of Knowledge (BABOK®). This is analogous to the PMI®s PMBOK® for Project Managers – a collection of best practices that have evolved over time. The IIBA® has established a set of certifications for Business Analysts, which require the candidate BA to have completed 3 days of approved training, have a certain number of years’ experience, and pass a multiple choice exam. Once this is complete, the candidate becomes a Certified Business Analyst, internationally recognised.
There are fewer certified BAs than there are PMs at the moment, but the rate of growth for BAs is far higher as the industry recognition of the value of qualified Business Analysts has grown considerably.
How can we help?
Aspira has invested heavily in building a range of Business Analysis services, from consultancy to help our clients create better requirements, to the provision of BAs, to the provision of the 3-day certified BA training courses, we offer wide range of BA services.
For technical Project Managers, we have found that attending the 3-day BA course is very useful. It provides the PM with a far deeper appreciation of the BA role and how to elicit requirements, and even if the PM is not interested in becoming a certified BA, the training will deliver 24 PDUs to help the PM retain his/her PMP® certification.
If you are interested in talking to us on how to de-mystify the BA role, or for advice on the most suitable BA training, please contact us at info@aspira.ie
The Project Management Professional (PMP) is a registered mark of the Project Management Institute, Inc.
