In all my years as a Consultant Business Analyst, having reached a level of proficiency, I have realized that being a business analyst is seldom about the hard skills. In fact, it is more about the soft skills and BAs who operate at that level are more impressive and effective in their job. Hard skills like documentation, requirements elicitation, process maps etc. are easily taught and acquired but the soft skills are developed with experience and the right attitude towards this role. Over time I feel the perception of the value of BAs has diluted and I blame those who have been superficial about performing this role. Those who think their role is just about the tangible artefacts like the business requirements document, process maps, business case, etc. Those who think they are here to deliver a project and nothing else. Those who think the BA’s job is to take orders and execute. But the fact is that the role of a BA is a lot more subtle than one thinks. There is a much broader aspect to this role, which is often forgotten, and we get caught in deliverables and artefacts.
Let’s look at some aspects of this role, which are common knowledge and broaden our perspective of that. When the mindset of the Business Analyst changes to the bigger picture and to the more delicate facets to this role, you perform much better as a business analyst and are a more reliable and thus a desirable professional for companies.
Communication over documentation
The purpose of preparing artefacts was never about documentation but communication. When you intend to communicate with the reader of your document, your artefacts become more meaningful and easily understandable. I have read a few documents written by business analysts and I must say it was excruciating and tedious. Mostly because the documents just had pages and pages of text using sophisticated words which required that I refer to a dictionary to understand what the sentence was trying to convey.
On the other hand, I have read documents where the author has attempted to convey the concept in a very simplistic fashion using a combination of words and pictures. Such writers weave a story into their documents, which makes it easy to read, understand, review, approve and refer to, at a later stage. Little wonder the terms/techniques such as user stories, journey mapping, customer experience and the like have emerged and evolved.
Attempt to communicate through your documents and not just for the sake of ticking a box to say that you have produced an artefact. This will come if you look at this facet of your job through the soft skills lens.
Requirements elicitation vs understanding needs
Eliciting requirements is a fundamental part of a Business Analyst’s role. Some of us forget that the act of eliciting requirements is not limited to running interviews or workshops where we ask, and they tell. The softer side of gathering requirements is to understand their needs and know what their business objectives are. From this approach, stems the ability to help the business formulate their requirements. Sometimes business don’t know what they want, they sometimes do not know what they need and they rely on the business analyst to draw a picture for them to understand what the future could be like. A vision of the future state can prompt the business to come up with requirements. Sometimes the people the Business Analyst deals with are stuck in the problems of the present and need help to visualize what success actually looks and feels like.
It is up to the Business Analyst to guide the business and extract the requirements. This ability can be cultivated only if you understand their needs, understand the underlying problem that needs addressing or the opportunity to explore. Only then will you be able to question their requirements when they don’t match their needs. Otherwise all you will do as a BA is to bring everyone to a room, you ask, they tell you what they (think they) want, you would have noted them down, documented, signed off, delivered a solution and when the business say “This is not really meeting our needs”… you will think “But I gave you what you asked for”.
Process maps vs visualization
Just like requirements, process maps are like second nature to a Business Analyst. But the point of process maps is not just to say what tasks come after what. Instead, it is to draw a picture that helps the viewer visualize the current situation and have a vision of the future state.
Business Analysts also don’t always do process maps to draw that picture. We also sometimes do journey maps, business context diagrams, data flow diagrams, etc. to help our stakeholders understand the current state and imagine what success will look like. When a Business Analyst approaches this with their soft skills’ lens, they are able to weave a story to provide insight using pictures. I have always found documentation with a combination of pictures and text as a more interesting read and also easily understandable, than without any pictures.
Delivery vs enabling change
Business Analysts are popular for delivering projects and doing the hard yards to ensure projects are completed and expectations of the stakeholders are met. That is something every Business Analyst is expected to do anywhere. But the BABOK and the world’s BA community who authored it defines Business Analysis as follows:
“Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.”
The key words for me here are “Enabling change”. If you expand this a bit further, you will realize a big part of the BA’s role is to ensure that the business successfully transitions from the old to the new. This also means you have to deal with fears and inhibitions of the end users or other impacted parties, empathize with them and address their fears, concerns and uncertainties. It’s about building relationships with the stakeholders, so they feel safe sharing their anxieties with you and trust that you to have their best interest in mind. The more they trust you, the better you can enable change. This can’t be achieved unless you bring your softer side to work.
Workshop facilitation vs negotiation
BABOK identifies “Negotiation and Conflict Resolution” as a key underlying competency for a Business Analyst. When we elicit and manage requirements, it is likely there will be conflicting requirements coming from different stakeholders. That’s when the Business Analyst not only brings everyone to a room and facilitates the session but also negotiates and drives a consensus among stakeholders on the requirements. It takes a special skill to be a negotiator. To be able to do that in a way that both the opposite parties see you as a neutral person and truly unbiased. This will be possible only if the Business Analyst has the emotional intelligence to not take sides and get swayed away by personal opinion. It is not about the winning voice but what’s the best for the organization. The Business Analyst needs to be clever to negotiate in a way that all stakeholders realise that we are doing the project in the best interest of the organization. It takes a special person (with a heap of the other underlying competencies in the BABoK) to get the stakeholders to realize that amidst their anger or frustration.
Conclusion
Business Analyst’s role is always larger than requirements, process maps and artefacts in general. The Business Analyst’s role was, is and always will be a challenging role and it takes a special personality to be successful in this field. People who think it is only about deliverables and artefacts will only go so far with the stakeholders but building trust and relationships with the business to enable change and deliver value is what it is needed to go the distance and be recognised and valued.
Author: Arvind Arcot, Consultant and Business Analyst
Arvind brings over 20 years of professional experience, including 13 years as a Consultant and Business Analyst. He has extensive Banking, Finance and ICT sector experience, rounded out by experience in Government (Australian), Transport, Petroleum, Higher Education and Retail. He has been deployed on numerous consulting engagements throughout the Asia Pacific region, enabling him to engage in highly varied client organizations.
Arvind is a passionate BA leader and has established and run various BA practices in his career. He also has a passion for writing and publishing white papers/articles to document and share experiences, learning and observations from his professional career. Arvind is also a nationally recognized industry speaker and has spoken in various BA conferences in Australia. He is the Melbourne branch chair of IIBA, Australia Chapter.