Soft Skills

As a business analyst, one of the most valuable skills you can acquire is the ability to build relationships. This in itself may have more of an impact on your long-term BA career than your business knowledge and technical skills. Because BAs are often key participants in so many different projects and initiatives, it can be difficult to nurture all of the relationships established throughout your organization. The relationship that I will be focusing on, however, is the relationship with the developer(s). Solid business analyst-developer relationships are often easier to facilitate in agile environments; therefore, it is essential to put more effort into managing this relationship in an environment that uses a waterfall or traditional methodology. Below are some tactics we as BAs can use to make developers’ lives easier and enhance the business analyst-developer relationship.

The relationship between a business analyst and the stakeholders is one of the fundamentals to the journey of delivery. If the relationship is dysfunctional, the process of delivering the solution will be negatively impacted... Each one of us is blessed with a different personality that makes us unique. In the case of business analysts, personality plays an important role, thus making it a key to survival. Business analysts are adaptive survivors. It is imperative that every impacted stakeholder is engaged and collaborating. It's fundamental to a robust requirements analysis process. Having mentioned the need to bond with your stakeholders, let’s see what skills are needed to be a successful business analyst.

 

Business Requirements Advocacy is neglected in the business analysis practice!  Once considered to be an essential part of IT teams, the business analyst has become an integral position in any successful, market-driven organisation. Rightly said to be the change agents for any business, business analysts help organisations adapt to the changing environment while meeting the needs and demands of all their stakeholders, including employees, customers, and suppliers.

A BA walks into an elevator, is joined by an executive, and suddenly the executive asks the BA, “So, what are you working on these days?” (Sounds like the start of a joke ...)  Most business analysts, due to their project success focus, think of requirements management when questioned about their work. So the BA responds by describing the features of a business solution that the BA is currently working. The BA seldom mentions the associated business benefits with the work (i.e. why the work is vital to the business). Unfortunately, the BA ignores the first rule of conversation: know your audience. The executive asking the question is more likely to understand and be interested in the business value provided by the work, rather than the solution features.

Business analysis is a broad discipline and we have a whole range of tools and techniques at our disposal. We may get involved within projects, but also outside of them. Many BA teams are actively seeking earlier engagement—when we are engaged prior to a project being initiated we can work with our stakeholders to ensure that the problem space is thoroughly understood. We can encourage stakeholders to think about many possible solution options, and can work with them to ensure that the option that is chosen is the best fit and has the best chance of delivering maximum benefit. Early engagement also helps us avoid the 'first solution trap'.

Ground rules are essential for any meeting. It may be what makes the meeting a success or failure. As a Business Analyst we are constantly organizing and facilitating meetings of various sizes to progress through the SDM (System Design Methodology) for a project. It is important that all sponsors and participants of the project understand what to expect from the upcoming meetings to be organized. Ground rules are generally discussed during the kickoff meeting, documented, and then displayed moving forward.

While BABOK and other sources include Behavioral Characteristics as an essential underlying competency for business analysts, many analysts may have only a vague idea of how it applies to their personal work environment, or even exactly what behavioral characteristics are, so let’s define those first.... The term behavioral characteristics simply refers to an analyst’s workplace ethics and character. 

The causes of chaos are unpredictable behaviors that arise from individuals, teams, or systems. Behaviors portrayed by the mentioned three components affect how an organization is able to handle challenges and problems. By allowing individuals and teams to portray their own behaviors in the working environment, different components of an organization may either work properly or experience failure. In the subsequent sections, we will elaborate on some mechanisms that trigger chaos in an organizational context.

Let’s face it, there are just some conversations that you don’t want to have. There are some people you simply don’t want to talk to, but what happens when we don’t have these conversations? Everyone loses! It is perfectly natural for us to avoid difficult conversations. We fear rejection, retaliation, emotional outbreaks, the dismissal of our ideas, and of course those incredibly awkward moments where everyone around you stares at their feet thinking “God I am glad that’s not me.” However, these conversations need to be had and the Badass Business Analyst will have them. If we want healthy, productive teams and projects, crucial conversations must be had frequently. You can’t just keep ranting, raving, complaining and avoiding, you need to start having meaningful, persuasive conversations that make an impact. You need your ideas to be heard, and more importantly you need behaviors to change. Don’t you think its time you and I have a crucial conversation? Suddenly I feel like I have turned into my father. Sigh. For the record, all of his crucial conversations were always too late, which is maybe why I am so passionate about this particular chapter in my book (the longest chapter by far - okay, moving away from from therapy now).

Is your team struggling with the transition to modern requirements practices? As many teams explore and experiment with modern practices and agile, they often jump to apply tactical methods and techniques. But does anything really change?

 

Most teams work really hard and don’t see results. Or they find a few early benefits, but get stuck on a low plateau. They often give up and slide back into their old habits. Why? Because they’ve modified surface-level tactics, but haven’t modified mindsets.

A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story. 

Moving on, we will investigate the importance of the business analyst’s often delicate relationship with individual stakeholders.   A business analyst is a facilitator of change, and in affecting these changes within a company, the analyst must interact with multiple stakeholders of varying personalities. When identifying and delivering the necessary changes within a business, the analyst must develop and maintain a relationship with each individual stakeholder.  Each stakeholder will wield a different level of authority within the company and hold a certain amount of power over those changes that are coming into effect. Noting this, the analyst must take part in a careful balancing act, juggling these relationships in order to facilitate change with minimal difficulty.

By signing up to go through this process, you will be doing yourself a huge favor – a favor that you will never regret especially when people will look at you as the ‘wow’ person who completely transformed his or her life, achieving something that was not even vaguely possible otherwise.

We implemented A/B testing into our product 6 months ago. During that time we conducted a variety of A/B tests to generate insights about our user's behaviour. We learnt a lot about our specific product. More generally, we learnt about how to run valuable A/B tests.