One of the crucial first stages of any project is the seeking out and to collect all-important business requirements. Establishing an entire set of needs at the beginning allows for superior planning, shorter delivery cycles, authentic estimates of project costs, along with
increased client satisfaction and the better adoption of the end product or service.
One of the main duties that a business analyst will perform is to successfully bridge the gap between the technical and business requirements. They are expected to fully comprehend the requirements of the company within the given context, then adjust these needs with the objectives and goals of the organisation. It is also essential that these results be communicated to either a development team, stakeholders or perhaps both.
In order to accomplish this successfully, the project requirements must be clearly and concisely written, in a way that is entirely comprehensible to both groups of people. It is expected that the business analyst, project manager or whoever is responsible for the analysis will have to deal with conflicting views and opinions from the stakeholders; there will frequently be challenges along the way to working out the exact plan and obtain a crystal clear picture of exact requirements.
1. Not defining the success criteria clearly
It is entirely natural for stakeholders to be aware that there are issues which need to be addressed, but not to fully comprehend what they require as a solution. One key element to help them to reach this point and address the issue is to break the project down into bitesize pieces. There are numerous collaboration modelling tools, which allow this – providing the clients with a high-level overview of the vision.
What is key, is to try to fully ascertain what they like, you can ask them to give you examples of products they prefer, and to elaborate on why they like them. Making the requirements fully quantifiable and conclusive.
2. Stakeholders may have a conflicting interest or priority
When introducing a new process, system or product, it is essential that it adheres to the requirements of multiple groups of stakeholders, these could be senior management, investors or even end users of the product. It is possible, and almost probable that these groups of people will have conflicting priorities or views on this. We have found one of the best ways to tackle this challenge, is to always have an assigned authority within the business. This is somebody who can take charge of the negotiations, and also who has the final say in making the decision. Without this person, it is often exceptionally challenging to resolve this type of conflict.
This part of gathering requirement is crucial, it ensures that any proposed terms are not out of scope, nor do they promote any individual agenda – as opposed to the overall company vision at the heart of the project.
3. Stakeholders who are over forceful or do not speak up
If you are dealing with this issue, rest assured – it is likely that it is nothing at all to do with your project. These issues are frequently experienced to be political issues within a business. People might even be afraid to get pinned down by expressing their views or solutions. Sometimes, the project may be of particular importance, and as such this will be driving everyone to want to be involved and have a say. Participation from stakeholders, along with active communication is a recipe for success when we look at the requirement gathering processes. Having these key people provide you with honest, open information will first mean you having to establish rapport and trust. Being well prepared for these meetings, listening whilst you are in them and learning from them will imply professionalism, interest and will also enable you to understand their challenges, which will enable to you focus on solving their issues.
4. Stakeholders may have a change of heart
From time to time, this can happen. It could be that the initial project requirements have not been entirely understood, or communicated, or perhaps, over the course of the project – they have evolved. Realistically, the only way you can approach this objective or challenge is to remain flexible and try to embrace the change. Any amendments will need to be correctly prioritised and there will most likely be new budgetary and timings which would need to be relayed and confirmed with the client before any modifications can take place.
5. Stakeholders insisting on a specific solution
This challenge will often surface when the stakeholders are limited with their technical knowledge in specific areas, if they had a particular technology in a past project work well for them, or perhaps, they are just unable to articulate in a concise manner what requirement they are needing to address. An ideal way to deal with this is to aim to divert their focus back to the definition of what the system should do. One way to do this would be to ask a question such as “if you were to have that system in place, which one of our problems would that specifically solve?”. Essentially it will be the technical team who work out how the system will do what it needs to, not the stakeholder.
For more information on Aspira’s Business Analysis services check out our website or contact us on info@aspira.ie