Recently one of our readers asked about how to determine if the level of requirements he wrote was deep enough. He explained that his work was being reviewed by a senior developer who aspired to his BA role and who reported to the same manager. The manager appeared to place more credence in the developer’s viewpoint than that of the business analyst.
Without more context around this, the issues here are very broad, and open to some speculation. I thought I would respond in broad terms anyway, as it raises some interesting considerations.
Understand the Business Analysis Scope
Firstly, apart from any personal concerns, it’s vital for a BA to fully understand the scope of the task, or project, at hand. Usually a kick-off meeting would be held to help define and clarify the scope of the task. For a BA it’s important to understand that you are usually dealing with two lots of scope:
- The scope of your piece of work
- The scope of the project
Use Reflective Listening
For the purposes of this blog I am focusing on the scope of the BA’s piece of work. In clarifying the scope of a new task or role I would, in the first instance, use reflective listening skills in a meeting. So once a stakeholder has made a statement, I might respond by reflecting back what had been said. For example, I might say “Are you saying that as an outcome of this investigation you would like to clearly understand which aspects of the helpdesk functions could be automated?”
Define the Why Behind the What
After the kick-off meeting I would clearly document the scope and send the document to the manager or project manager. I would then request agreement or clarification to ensure that all parties have clearly understood and agreed on the task.
When writing up the scope it’s a good idea to articulate the “why” or the benefits of each aspect wherever possible. Being able to articulate the benefit of the scope gives you the insight to really meet the scope.
For example, you could write up part of the task as:
Define the number and types of tasks for each of the helpdesk staff on a daily and weekly basis.
Such a task results in a simple table by person, day, and week. However, look at the difference of the same task defined with a reason:
Define the number and types of tasks undertaken by each of the helpdesk staff on a daily and weekly basis to determine where the new system could automate or streamline the workloads and create efficiencies
This would guide you to carry out a very different investigation and the resulting documentation would also be different. So it’s important to understand why the project has the scope that it has, and to get sign off on the why as much as on the what.
Understanding the “why” behind the “what” goes a long way to understanding the depth of the analysis required.
Avoid Perceived Conspiracies
Our reader’s concerns extend to how to deal with a senior developer who reviews his work and, at the same time, aspires to the role as BA. Without having a full picture of the circumstances, I would advise the following guidelines:
- Do the best work you can to meet the scope and the “why” of the scope.
- Request constructive feedback from both the senior developer and the manager.
- Be prepared to whole heartedly accept any feedback that is valid and that can improve the project.
- Be calm and able to brush aside any feedback that is not valid.
- Be open minded, and be sure you can clearly differentiate between points 3 and 4 above.
- Do not be afraid to acknowledge your own failings and be grateful when you can learn from others.
- Stand up for yourself and your findings when you know they are valid and should be respected – but make sure you do this in an unemotional way, being very clear and professional.
- Never take anything personally, even when you believe it’s meant personally.
- Keep communicating, ask questions and don’t make assumptions.
- Talk to both the senior developer and the manager – find out what makes them successful and do your best to support them to succeed, become an ally.
And finally, talk to your manager! Clear, calm communication is how things change.
Be sure to be completely calm and at ease before you talk. Be ready to consider any feedback and clearly articulate your truth where necessary. And be ready to accept ideas and suggestions that are valid and that would help you to improve.
Communication is very important to understanding others around you. If you have the slightest concern that there is a conspiracy or conflict of interest going on then talk about it. Get the matter out in the open and deal with it in a clear and professional way. In many cases the problem is not as big as it is perceived in our minds.
About the Author
Michelle Kandiliotis has worked predominantly in the role of business analysis over the past 20 years with some diversions into project and general management. Michelle is passionate about creativity, communication, mentoring, inspiring and motivating people, having fun, and benefiting the organisation.