Skip to main content

Tag: Communication

BATimes_Aug21_2024

Best of: 10 Soft Skills You’ll Need To Be A Successful Business Analyst

You might already know the technical skills you’ll need to be a great Business Analyst (BA) but do you know the essential soft skills? The role of a BA is deeply rooted in working with people. You’ll often be coordinating with stakeholders, running workshops, or presenting documentation to teams. To be a successful BA you’ll need the following soft skills to compliment the technical ones.

 

Rapport Building

You’ll need to build rapport with your stakeholders early in a project which you can do in many ways. While you’re waiting for a meeting to start ask your stakeholders questions like, “how is your day going?”, “what are you doing in the weekend?”. I’ve been in meetings where everyone is silent until the workshop begins. Take advantage of this time to build rapport by finding common interests, showing empathy or complimenting them on something such as a tie, a picture in the background of the Zoom or their promptness. This may seem trivial, but it will set you up to succeed as the project rolls out. Your stakeholders will be more likely to attend meetings/workshops, feel more comfortable contributing and start to champion the project and the changes you’re making within the organization.

Empathy

The Oxford Dictionary defines Empathy as ‘The ability to understand and share the feelings of another’. This is an important soft skill for a BA because we need to put ourselves in our stakeholders’ shoes to understand the problems we are trying to solve. To have empathy means to understand the pain points within the organizations Current State which is essential when we’re trying to fix them. Try to imagine how frustrating it must feel to have outdated, manual process at work when the technology we use at home is so advanced these days. Use empathy to speak to these pain points and get stakeholder buy in and drive user adoption.

Enthusiasm

Depending on the scope of your project Stakeholders may be attending a lot of workshops and meetings so it’s important to be enthusiastic and positive about what you’re doing. Let’s be honest there’s nothing worse than a dull or dry workshop consisting of people talking at you with slides of written content. To get people to come along for the journey we need to engage them and be enthusiastic about what we’re doing. Speak positively about the benefits and outcomes of your project, show visual diagrams and ask questions to get people involved. Having a positive and bright disposition will pick people up when they engage with you, help them focus on the content and be more likely to contribute.

BATimes_May24_2022

Active listening

When we’re working on current state or establishing things like user journeys, user personas, use cases or processes a key soft skill you’ll need is Active Listening. Active listening is a pattern of listening that means listening to verbal and non-verbal cues without judging or jumping to conclusions. When you’re active listening you’re not thinking about what to say next you are completely focused on the person communicating. Don’t interrupt them or propose solutions at this stage, instead paraphrase and reflect what you’ve heard back to the person. This will ensure you don’t miss anything, don’t misinterpret anything and help you understand the paint points your users are experiencing in more depth.

Creativity

When making changes to the organization such as processes, we need to find solutions that work for everyone. For this we will need to think outside the box because realistically we may not be able to meet everyone’s needs, or some people may just be averse to the changes. To facilitate the transition, we can use creative visualizations to get everyone on board the journey; Miro, Figma and Visio are great tools for creating visual diagrams. You can do role plays during workshops, online or in person to outline the steps of a new process. Be creative and use your imagination to make it fun and engaging for your stakeholders.

 

Advertisement

 

Adaptability

As a BA you may find yourself on new projects for new businesses often and every situation will be unique. You will need to assess each business’s unique culture, ways of working and environment. Some businesses may be very formal and highly governed while others may be casual and more agile in their approach. To be successful in all these environments you need to be able to adapt, this means finding the right language, terminology, pace, document structure and hierarchy. Recently I worked on a project for a very successful company that still had a startup mentality. They embraced agile ways of working and feared having their autonomy taken away, because of this the word ‘Governance’ was a trigger for many of the staff. We had to adapt our language to suit the client and instead of ‘Governance’ we used ‘Guidelines’. Be adaptable and understand the culture you are working in, don’t work against it, work with it.

Communication

Clear and concise communication is important to be successful as a BA. When working with people things can get lost in translation, its our jobs as BAs to ensure they don’t get lost! Be willing to speak up and ask for more detail if you don’t understand something or when you notice others aren’t understanding it either. At times you may need to control the pace of a discussion, to speed it up to keep people engaged or to slow it down if it is moving too fast. There are times when you will need to paraphrase what someone has said to communicate it more effectively to the broader audience. You can use terms like “what I’m hearing is…” or “To put that another way might be…”. Utilizing your communication skills will ensure workshops and meetings stay on topic and you get what you need out of them.

Patience

You may find yourself in a situation where you already know the journey ahead for your stakeholders for example a company is implementing an out-of-the-box solution. You’ll need patience to assess their current state to find gaps and bring the stakeholders along for the journey so they can get excited about their new technology and processes, even though you already know the outcome. Another example of using patience is in workshops where different participants repeat information to you, you need to actively listen so they feel heard, but it could get a little boring for you. Lastly, not everyone you encounter is going to be a great communicator, some people talk for too long, some people get off topic, some people are hard to understand, and you need to listen to these stakeholders trying to communicate ineffectively and decipher what they’re saying, this takes patience.

BATimes_May24_2022

Improvisation

You will find yourself in meetings with technical people, non-technical people and people from all different units of the business. Analogies are a great way to explain complex strategies or technology to people that don’t understand what you’re talking about. If someone doesn’t understand something a great way to describe it to them in terms they can understand may be using analogies. You can improvise and tell them about “One time I went to the supermarket and at the checkout this happened…. Which is like this technology system that does this…”. You will get better at this over time and come to understand what works for stakeholders from different Business Units.

Conflict Resolution

Often our stakeholders may disagree on things like current state or how future state should be. We need to manage both points of view and bring the team to a consensus where possible. Consensus may not be possible in all situations, but we still need to handle the conversations constructively so that everyone agrees upon the next steps.  Some pointers for conflict resolutions are

  • Defuse Anger and facilitate communication
  • Separate people from problems
  • Listen first, talk second
  • Set out the facts
  • Explore options together

Using these tips, we can find a way to move forward together and keep the project on track.

People Process and Tooling (The PPT framework) is a great way to approach IT changes within an organization. I believe the most important aspect in this framework is people because the technology and processes are no good if the people within the organization don’t use them. You can use these soft skills as a BA’s when engaging people to ensure organizational changes are adopted and in turn, you will be successful too.

BATimes_July31_2024

Decoding Stakeholder Signals: Beyond Formal Feedback in Business Analysis

If I asked you how often you get feedback from your stakeholders, what would your response be?

 

I suspect many people reading this will actively solicit feedback quarterly or annually for a formal appraisal process. That is very useful, but consciously created feedback of this type is only one source of valuable insight. Feedback is all around us, but it often requires us to look for it. However, it is well worth being vigilant, as when we spot feedback we can reflect on it and adapt.

 

Feedback as a Signal

Rather than thinking about feedback as something that has to be formally solicited, let’s imagine stakeholders let us know their thoughts, feelings and intentions through a series of signals, and those signals can be consciously or unconsciously given. Sometimes they’ll say something directly, other times we might need to read between the lines and observe their actions.

This is similar to driving a car.  If you’re in the driving seat of a car, you’ll be scanning the road for turn signals (indicator lights). These tend to indicate another driver’s intention to turn or maneuver.  However, we all know that not all drivers use these lights! We’ve probably all experienced situations where you notice a small change in another driver’s trajectory, so you hold back a bit… and instinct serves you well as they cut over multiple lanes of traffic. There are many subtle cues that indicate what a driver is about to do, although on the road rarely is it possible to validate our instinct. You can’t ask the driver what they are about to do: it’s necessary to wait and see.

A similar analogy can be drawn with organizational stakeholders, however we have the advantage that we can ask them what their intent is. Let’s examine an example:

 

Advertisement

 

Example: The Absent Stakeholder

Imagine you have a stakeholder who is crucial to the success of your project, and they are regularly ditching meetings or arriving very late. They always arrive unprepared, and rarely make decisions as they are too busy. You have sympathy for them, they seem to be spread so thinly.

Arguably there is a wider organizational issue here, as the stakeholder has too much work to do. However, assuming the person is effective at managing their workload, then there’s an unpalatable truth to swallow here. By saying “too busy” they are actually giving a subtle feedback signal which could be interpreted as “this is not a priority for me right now”.

This last sentence might be a difficult one to read, and they might say (and genuinely think) that the project is important. But if they are not prioritizing their time in a way that supports the project, they are unconsciously signaling that it isn’t significantly important for them to spend their limited time on.

 

This is no criticism, they may well be doing the best they can in difficult circumstances, and we should absolutely do what we can to make sure we support them and respect their schedules. Yet, left unchecked this might lead to a project that limps along, with other stakeholders getting increasingly resentful that progress isn’t being made.

Sadly, there’s no easy solution to this, however it’s important to address the issue head on. Ensuring the stakeholder knows why they are so important and valued, the benefit of the project to them and the implications of their non-participation is crucial. Offering to do what we can to lighten the load for them will often be appreciated, and it is worth asking if they have a delegate who can help.  Ultimately, if they are truly crucial and can’t delegate, then perhaps delaying the project is a better option.

Indeed, openly saying “would it be better to delay this project to a time when our crucial stakeholders have enough bandwidth to support it?” could potentially prompt a useful (albeit often difficult and emotion-filled) discussion!

 

Interpretation Is Hard

Once you start looking for feedback signals, they are all around us. However, interpretation is hard. It’s important to speak to stakeholders to understand what is going on for them, rather than assuming. The key is to start looking, and make any adjustments early. That way we can make things better for our stakeholders and our project teams—and who wouldn’t want to do that?

BATimes_July17_2024

Contribution as a Form of Professional Development

As practitioners of change, we are probably all acutely aware that we need to continually develop. There is always more to learn, and there are countless ways of learning it. The fact that you are reading this article now, on a business analysis website, shows that you are interested in your professional development—and kudos to you for doing so! After all, it is those that develop and keep up to date that will thrive in an increasingly competitive environment.

 

However, professional development is often seen as a consumption-based activity. Ask a typical BA what development activities they have undertaken recently, and they’ll likely respond by telling you about articles they’ve read, training they’ve been on, webinars they’ve watched and so forth. All of these are fantastic ways of hearing different perspectives, and it is great that there are so many cost-effective (and free) options out there.

 

From Consumption to Competence (Through Practice)

Yet consumption alone rarely enhances a skill. I could ‘consume’ (read) a book about how to fly a passenger jet, yet you probably wouldn’t trust me to fly one if that’s the only experience I had. In fact, even if I’d been on a one-day course and we’d done some group-work simulating flying, you’d probably argue that isn’t enough. And of course you’d be right, pilots (presumably) need lots of time in the simulator, and hours flying generally, before they are qualified to fly a commercial airliner.

 

Although you or I are unlikely to be racing to the cockpit of an Airbus A380 any time soon, it’s likely that we will need to learn new skills, techniques and concepts. The broader point here is that just reading about them, or watching a YouTube video about them isn’t enough. Actually using them is crucial. This is where the ‘rubber meets the road’, where even more learning happens, as the technique or concept is put into practice within a particular context. It’s often the case that some adaptations are necessary—a technique that works just fine in the classroom may need some finessing to work in the real world. And that’s just fine, deliberate and selective adaptations to the nuances of the world are precisely what we should do as analysts.

 

Advertisement

 

From Competence to Contribution

It’s often been said that if you want to really test your knowledge of something, try and explain it to others. There is a strong element of truth in this, as anyone who has ever created a presentation or training course will tell you! Putting together an article or presentation tends to highlight any gaps in thinking, and it’s an opportunity for reflection.

This is where contribution to the BA community can become part of a deliberate professional development strategy. Perhaps there’s a technique that you’ve mastered: that would be a fantastic topic for a ‘skills exchange’ session with your colleagues. Perhaps that would involve a short presentation and a Q&A. Your colleagues would learn about the technique, within the context of your organization and by creating the presentation (and responding to the Q&A) you’d likely learn more too.  A real win/win.

It’s possible to go even further. While we may be members of a Community of Practice within our organizations, we could also consider ourselves to be members of a global Community of Practice of interested BAs. You and I are connected via this article and this website. Others are connected through social media networks such as LinkedIn.

 

This provides us with the opportunity to write, blog, create videos and share experiences with people outside of our organizations too. Of course, it’s crucial not to share anything confidential or commercially sensitive, but sharing ‘how to write a user story really well’ or ‘how I used use cases to clarify complex requirements’ is unlikely to be controversial! It also has the advantage that it helps us all to connect with other interested BAs around the world. Hitting the ‘publish’ button can be scary, but the act of creating something is hugely worthwhile, and others will benefit from it.

Incidentally, if you’re reading this thinking “I’m too inexperienced to write or create anything” or “I don’t have anything worth writing about”, in my experience you are probably doing yourself a disservice. BAs tend to be somewhat modest, and everyone has an interesting professional story to tell!

 

Take a Blended Approach

Community contribution can be part of a blended professional development plan. Alongside consumption and practice, it can be a great way of reflecting, while also sharing experiences and building BA networks.  The nature of the blend will vary depending on practitioner, but considering the options is key.

And if you do decide to create and share something, be sure to connect with me on LinkedIn and let me know about it!

BATimes_Jun18_2024

A Business Analyst/Project Manager Guide to Untangling the Technical/Process Debt Mess

Usually, there would be a discussion about how only IT Business Analysts encounter technical debt as it is a Code Mess. Regardless of the industry you are working in, it may be something other than a technical debt. Still, when you are working on projects that can contribute to a similar concept or backlogs that were cleared to meet deadlines or immediate requests but weren’t cleared the right way, it is referred to as a process debt. Technical debt is specific to code, but accumulating debt from shortcuts applies to any project. Process debt refers to problems created by rushed or incomplete work outside of coding. Both technical and process debt can hinder future progress and require additional effort to resolve.

 

Who are the Culprits of Technical/Process Debts?

Truthfully, there isn’t one specific culprit, as fingers should be pointed at the project managers, business analysts, developers, and business stakeholders; hence, there is shared blame. By working together and understanding the long-term costs of technical/process debt, teams can make better decisions about how to build software, products, or projects.

 

Is Technical/Process Debt in itself a bad thing?

In some situations, technical debts can be a strategic decision to get a product or a feature out the door as quickly as possible. This might be because of need, deadlines, unclear or evolving project requirements, or even resource shortages. In this scenario, it might not be a bad thing in itself, but the key is to be aware of whatever debt accumulates and ensure a strategy to pay it down eventually. It becomes bad when it isn’t fixed and becomes the norm.

 

Another question would be, what is the role of Business Analysts and Project Managers in the Debt Den?

We exist as a bridge between business needs and technical realities. Why, as a bridge, most of us do not write the codes, but the individuals who do are part of our key stakeholders. We must keep them on track to slash the technical debt to its bare minimum until it is non-existent. By acknowledging that everyone can contribute to a project’s “debt,” teams can work together to prioritize quality and avoid shortcuts that create problems later.

Advertisement

 

What are some reasons for a quick fix that could lead to the accumulation of technical/process debts?

Deadlines (Realistic/Unrealistic): This is usually the primary cause of debts. Truthfully, some of these deadlines may be unrealistic, and some might even be realistic. Still, before deadlines are fixed for every task in a project, business analysts must have estimated the effort required for every feature/product/process. This estimation should have considered the complexity of such a task, possible roadblocks, stakeholders’ expectations, and risks. If this estimation isn’t done appropriately, unrealistic timelines or deadlines might be created. Another focus would be a dependence on Speed versus quality. In an ideal world with realistic deadlines and processes, there would be no need to cut corners; however, cutting corners is almost unavoidable when the pressure is on delivery by a specific date. In code writing, developers should have ample time to write clean, well-documented code that’s easy to understand and modify. But under pressure, corners are cut. Code becomes spaghetti-like, with functionality prioritized over readability and maintainability. This makes fixing bugs and adding new features later much more complex and time-consuming.

Solution:

Proper time estimation and setting realistic deadlines, allocate buffer time in project schedules to account for unforeseen issues or delays, allocate dedicated technical/process debt cleanup sprints, or integrate small improvements into regular development cycles and existing business processes.

 

Unclear or evolving project requirements: If the requirements are ambiguous or not well-defined, this could lead to technical debts. The business analyst’s role is to ensure the requirements are clearly identified, verified, validated, and accurately prioritized based on business value and user needs (other prioritization criteria exist). Potential relationships and dependencies are also expected to be accurately identified. When this is correctly done, it ensures that the project scope is clear and the project direction is visible to all.

Solution:

A proactive requirement-gathering system is recommended where early and frequent stakeholder involvement exists in the project/software development lifecycle. Different elicitation techniques can be used, but regardless of which technique is used, there must be a comprehensive understanding of needs and expectations. Also, remember that features or requests must be based on business value/user need/impact, not sentiments.

 

Absence of code/process reviews: This would serve as a quality check to ensure that inefficiencies and errors do not exist. Code reviews act as a safety net, catching bugs and potential issues before they become significant problems. Inexperienced developers are more likely to make mistakes that can introduce bugs into the codebase. Also, if processes aren’t documented or reviewed, they can be applied inconsistently across the team. This can lead to confusion, errors, and wasted time.

Solution:

Code reviews by senior developers can catch these errors early on, preventing them from becoming more significant problems and leading to a cleaner, more maintainable codebase. This reduces bugs, improves performance, and makes future development more straightforward. For processes, reviews provide a structured way to identify bottlenecks, redundancies, and areas for improvement within workflows. This allows teams to address these issues and streamline processes.

It is essential to state that Code/Process reviews should be seen as a learning opportunity, not a blame game. A positive and collaborative review environment encourages open communication and helps team members feel comfortable asking questions.

 

Conclusion

Technical and process debt doesn’t have to be a burden. By equipping yourselves with the right tools and strategies, you, as BAs and PMs, can become champions of clean code and efficient processes. You can expose these debts, develop a plan, and work together to build a robust and sustainable foundation for your projects. Remember, a little planning today can save a lot of headaches tomorrow –  so go ahead and untangle that debt mess!

BATimes_Jun12_2024

Beyond Jargon: Bridging the Gap Between Precision and Clarity

A while back, I was taking a flight from London City airport. It’s an airport I don’t fly from very often, and I was looking for a place to fill my water bottle. Unlike other airports, I couldn’t find a water fountain anywhere. The airport staff all seemed busy, so I did what any good BA would do, I took to Twitter (or is it X?) to ask the airport social media team where I could get some water.

I got a reply really quickly, with the social media team letting me know that I could get water from any food concession in the airport. So, I went to one of the food shops to grab some sandwiches and got them to refill my bottle at the same time. Problem solved.

However, another Twitter user pointed out at the time that it’s a little odd they used the term food concession and not food shops or food stalls.  I mean, what even is a concession? A little bit of digging uncovers this definition:

 

“A retail concession is a dedicated space within a single-brand store that is used by a non-related but complementary brand. Retail concessions are essentially shops within a shop…“ (Quote from Unibox site)

So here, the airport is technically correct. The food shops are technically concessions, they are ‘shops within a shop’, or in this case ‘shops within an airport’ (let’s face it, airports feel like one big shop these days!).

But who, outside retail, regularly uses the term ‘concession’? And in the context of my query, does it really matter that it’s technically a ‘concession’ and not a ‘shop’?

 

A Balance of Precision and Understandability

As it happens, I did understand what was meant, so this wasn’t an issue. But I wonder if a tourist who has a basic grasp of English would understand (this was an airport after all). It strikes me that with communication there’s a balance of precision and understandability.

Some terms will communicate things very precisely, but only to those who are within a domain. My career started in insurance: words like “cover”, “peril”, “loss’, “policyholder”, “insurable interest” have very specific meanings. Those things are important within the insurance company… but outside most people just want to “insure their car” or “protect their house”.  Of course, for all sorts of legal and regulatory reasons, there needs to be precise and formal T&Cs and policy wordings. But the way that the organization communicates needs to be in a way that’s understandable.

 

Advertisement

 

Does Your Internal Lingo Accidentally ‘Trickle’ To The Outside?

This is an area where BAs can help. Often, Subject Matter Experts (SMEs) will be defining the text that needs to appear on websites, letters, emails and so forth. SMEs are usually fantastic stakeholders with so much knowledge. They are great to have on board!

Yet, the challenge of having so much knowledge is they might forget what it’s like not to know so much. An SME who has worked in insurance for 30 years might not easily remember what it’s like to buy your first insurance policy. Yet, it’s likely that the solutions we define (and the communications that go out) will need to be understandable to someone completely new to insurance too.

Highlighting where internal lingo has inadvertently trickled to the outside world can be useful. Asking questions like “would an average customer understand this phrase?” or “what about someone who has never bought our products before, would they know what this means?” can help. Having a set of personas can be even more helpful.

 

Prototype, Test and Learn

Another stage that is often missed when defining and designing websites, emails, letters and other forms of interactions with customers is to take the time to test and learn. Showing a customer a rough prototype with the wording and seeing how they react would be a great way of getting an early steer. Prototyping a letter that is going to be sent to 150,000 subscribers and getting input from 100 might help uncover misunderstandings or ambiguities. This might save thousands of confused calls to the call center, and thousands of quizzical emails.

In summary, communication is always a balance of precision and understandability. Knowing the audience, testing and learning helps avoid miscommunication and misunderstanding. BAs are well-placed to foster these types of activities.