Business Improvement Architect conducted a research survey of Business Analysts attending Project World/Business Analyst World in Toronto, Canada and identified ‘Lack of Clarity in the Scope of the Business Functions’ and ‘Business Requirements Not Well-Defined” as the top two challenges they face in managing requirements.
Being a Business Analyst comes with many challenges. It’s important to be aware of these challenges so that when they do come up, you understand how to respond to them.
Getting Stakeholders To Make Time
Where stakeholders lack interest in a project, it can be challenging getting them to make time for the project. BAs in this situation may end up spending a significant portion of their time chasing after stakeholders who would rather be doing something else with their time. Common examples include trying to get stakeholders to participate in UAT sessions, dealing with irregular attendance at elicitation sessions and cancelled meetings. Where users are not committed to the project, the BA has to spend extra time and effort trying to getting them to do their bit. One approach that has worked for me is ensuring that managers are copied in all communications and are carried along. Once functional managers are involved, even if it is to a small degree, team members become more willing to fall in line.
Lack of Clarity
One of the most difficult aspects of any project is achieving clarity of scope, business objectives and communicating same to stakeholders so that everyone is in agreement. Clearly, one of the main responsibilities of a Business Analyst is to clear up any confusion surrounding the scope of the project. However, what happens when the BA is dealing with business users from different departments seeking to tailor the project to meet their individual needs? Until objectives and scope are fully defined and agreed upon, there will be no generally-accepted definition of what represents success. This is why defining scope and objectives is such a vital project phase. A BA cannot confidently dabble into a project without signoff on these.
Inadequate Time Allotted For BA Work
Life would be great if you got handed a new project and were told that it could be completed whenever it suited you. In the real world however, it is more likely that the time allocated to your project will be limited. Lack of adequate time to complete Business Analysis tasks can be a major impediment to delivering high-quality deliverables. Time constraints can lead to incomplete specification documents and the implementation of requirements that do not solve the business problem. One way to deal with this is to plan well and start early. A comprehensive plan with all the key activities mapped out, adequate resources and some contingency time built in can help you stay ahead.
Conflict Among Stakeholders
One thing that can be extremely difficult to control on any project is how stakeholders relate to one another. For instance, some stakeholders may not get along and find it difficult to work well together. In such cases, it is important to help stakeholders separate work issues from business concerns, manage stakeholder interactions proactively and be sensitive to any political undertones and power games that may be at play. It becomes even more important for the BA to reinforce the importance of working together towards a common goal and facilitate it. In some cases, requirements may clash and it is up to the BA to assist the stakeholders in arriving at a common ground. BAs must understand how to reduce conflict during stakeholder interactions and manage conflicting requirements.
Misalignment Between Business Needs and Technology
Another common issue occurs when the business wants something that the IT department simply cannot deliver – either due to unavailability of resources or some other cogent reason. A lack of understanding of the concerns or limitations of the technical infrastructure can cause issues. This can be minimised by educating stakeholders so that they understand the technical limitations rather than just focusing on their own requirements. The more stakeholders understand the big picture, the more they will be willing to accept alternative solutions that offer a practical match between their needs and the technical infrastructure.
Imagine a situation where requirements have been agreed and signed off only for stakeholders to indicate during UAT that they want key functionalities changed. You would have to start another phase of analysis and re-write software specifications to implement these requirements. Changing requirements should be expected from time to time (we are all human after all and can hardly be expected to get things right all the time) but when it happens too frequently, it can lead to project delays and frustration especially if it’s not properly handled. Changes should be assessed for their relevance through a formal change control process and in cases where they can afford to wait till a later release, they should be delayed.
The BA-Is-Always-At-Fault Mentality
If things start going wrong with a project, one of the most common first steps is to start investigating the requirements! BAs are often under pressure to deliver systems that meet business requirements. If a system is put to production and fails to meet the needs of the business, the BA may end up being blamed for the outcome. That’s why BAs are constantly under pressure, both real and imagined, to get things right. Successful BAs are aware of this and have the capacity to deliver results while accepting the pressure that comes with the job.
Do you experience any of these challenges? Don't forget to leave a comment below.