AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
The importance of BA’ing earnest
Subject matter experts are usually very apt at solving problems on the fly, filling in the gaps as they work through a problem using their experience to make gut calls along the way. However, when tasked with replacing the systems they use, these skills often make it more difficult for them to articulate what a complete solution would look like. Computers need to be programmed to cover all possible situations. Failing to proactively identify possible situations can result in system failures, and you can’t react in the same way as if it was a manual process. This is why the role of the Business Analyst is so important as they are the ones who bridge the gap between the technology and the humanity.
Documentation
There is an old joke in programming:
- A man is going to the shops and asks his wife if they need anything.
- She responds ‘Can you get a litre of milk…oh and if they have eggs, get a dozen’.
- The man returns with 12 litres of milk and no eggs, when asked why, he responds…‘They had eggs’.
Yes, this joke is so old it has become a cliché for blogs on topics like this, but clichés exist for a reason. Using clear and precise language helps to reduce the chances of any ambiguity resulting in misunderstandings. Everyday language does not cut it when trying to define the process that a computer will calculate verbatim. The requirements need to be written in a way that no two people can read them differently to ensure the developer, tester and business user all have the same understanding of the system. In addition to the language used, there are a lot of best practice principals for ensuring the correct things go into requirements, for example:
- Atomic – each requirement should only cover one feature, don’t try to make each requirement cover the entire process.
- Complete – all aspects of the specific feature must be documented, don’t assume the gaps will be filled in later.
- Consistent – must not contradict other requirements.
- Testable – it must be possible to write a test with specific outcomes for any requirement.
- Updated – when a requirement changes, the documentation must be changed.
This list is not complete, but it covers the main points and shows the type of thinking that needs to go into documenting requirements. I think ‘Testable’ is probably the most fundamental of these principles – not that it is more important than the others, but if you are thinking the whole time about what tests could be carried out for the requirement, it helps you to ensure the other principles are being followed.
Required elicitation
The basic role of a BA is to elicit requirements from the business users and document these requirements for the developers to then build the required features. This isn’t as straightforward as you might think. People often take their own knowledge for granted so when an expert is opining on something they know well, they will often use jargon or assume knowledge when explaining things. They will also quite often simply describe the current process and state what specific changes they want to solve the problems as they see it. A good business analyst will ask questions as they go through the process, identifying other opportunities for improvement and often uncover underlying problems that may solve many issues or solve smaller problems that the business user felt, but hadn’t yet asked to solve. This is why the phrase ‘Requirement Elicitation’ has replaced ‘Requirement Gathering’, as it is not the role of the BA to simply ‘collect’ the requirements, they should be drawing them out from the users.
BA without the A
There are plenty of BA’s who have made careers out of knowing how to write like a BA, but without actually understanding any of the requirements they are documenting. They are given a template requirements document, which they shuttle back and forth between the end users, who say what the system needs to do, and the developers, who say what it can do, and all they do is write what they are told in language that sounds like a requirements document. While there is some value added by translating everyday language into requirements language as it facilitates conversation between the developer and the stakeholders, unless they are actually ‘Analysing the Business’, they aren’t really adding the full value or reaching the full potential of what be be achieved from employing the BA role. I’ve worked on projects where the good will and flexibility of the business users and developers therefore cover up for the lack of value being added by the BA, but the project will always suffer as a result of this.
Does every project need a BA?
With a hands-on Product Owner who knows how to write a requirement, they can fill the same role without having a designated BA. Similarly it is possible, though less common, for a developer to step into the role. This can work particularly well for smaller projects or citizen developers, however as the project gets larger this gets harder to manage. You may notice that with both of these examples, the BA role has not ceased to exist, it is just being covered by other people, the actual role is indispensable so therefore you will always get more value from having someone who specialises in doing it.
One mistake that is often made is to hand a template requirements document to a junior person in the office, with no training or support in how to elicit the requirements. If they don’t have the confidence and experience to challenge what they are being told, they will fall into the patterns I’ve described above, and just gather requirements rather then elicit and analyse them.
What types of people become BA’s?
Business Analyst is probably one of the most diverse roles in IT. Some people study IT related subjects at University and go straight into BA roles, others come from the business and through working as stakeholders on IT projects learn the skills they need and move across. BA’s from more traditional IT backgrounds tend to be better at spotting gaps in requirements, highlighting technical issues earlier and creating better non-functional requirements. Business focused BA’s are more likely to spot errors in the business logic being requested or at highlighting better approaches to the solution. As BA’s are inherently project based roles, the need for them within a business can vary quite a lot over time, so often they are employed on contract basis, while others are full time employees. Employees often have greater domain knowledge as they are in and around the business for the long term, though external BA’s often come with a new perspective and ask fundamental questions. So BA’s from various backgrounds have their own strengths, and as with all generalisations, these observations should be taken with a pinch of salt and therefore treat every BA as an individual.
Conclusions
Computers cannot process ambiguity, while people often struggle with precision. Business Analysts bridge the gap between the technology and the people side of projects. It is a role that is often misunderstood, undervalued and often underutilised, but I have never worked on a successful project that has neglected the Business Analyst role.
Related Blogs
Drag