Tag: Communication

Be Bold: If You Disagree, Leave Them In No Doubt

Written by Adrian Reed on July 5, 2023. Posted in Articles.

Very early in my career, I was probably a bit too much of a ‘people pleaser’ which led to me shying away from conflict. It’s a common trait in BAs, we want to help people out, and we want to get them the best possible outcomes. This is a positive thing, but when over-played it can spill over into conflict avoidance, and this really isn’t a good thing.

For example, imagine a stakeholder requests a new feature, but there’s clearly no time or budget for it. It would be very easy to say something along the lines of:

“Ah, yes, that’s really interesting. I’ll see if that’s possible and come back to you if it is”

Now, on the face of it no commitment has been made, the BA might consider they’ve said “no”, but it’s a very, very weak no. The stakeholder may well have heard things differently, and might have drawn the conclusion that the feature will be delivered, after all, they didn’t hear the word ‘no’ at all! In three months’ time, when memories have faded, they may well ask you why the feature they asked for still isn’t delivered…

Conflict Avoidance Isn’t Friendly

Avoiding conflict might seem like a good tactic, but it really only works in the short term. When disagreement is communicated in a subtle way, it’s easy for there to be a sort of illusory agreement. Stakeholder A disagrees with Stakeholder B but they think they are agreeing. Of course, eventually they’ll find out that they didn’t agree… but by that time budget and time may have been spent unnecessarily.

This is an area where BAs can add huge value. Firstly, by being bold and concisely stating when something is outside of scope or can’t be delivered in a particular timeframe. This doesn’t mean it can’t be delivered… it just means that a conscious choice needs to be made. There might be a trade-off, by having feature X, it means that feature Y will be delayed or discarded. Or perhaps it means that there needs to be a discussion over the budget.

All of these decisions are best made consciously. A little bit of discomfort now, followed by an honest and transparent conversation is likely better than taking the easy route and saving up the consequences for later. You might be familiar with the concept of technical debt… well this is similar, it is almost a form of decision and conversational debt. By having illusory agreement over things, the decision is never really made, and an absence of decision creates issues.

Cultural Dimensions

Of course, it’s important to take national culture and corporate culture into account when considering how to respond to conflict. I can only speak as someone who has spent most of their time in the UK. I certainly know that in the UK we are fairly indirect communicators at the best of time (“Oh I’m very thirsty” can be code for “I’d like a drink please, but I can’t ask directly because that would be seen as impolite”. Equally “Hmm.. .interesting” can sometimes mean “I have zero interest in what you are saying”. We are a complicated nation!).

There are certainly other cultures where different types of response will be more appropriate, so it is all very much down to the context. One thing that is common though is conflict is best negotiated openly and honestly, and pretending it doesn’t exist is unlikely to lead to the best possible results.

Conflict Doesn’t Have To Be Negative

There is perhaps a view that conflict is inherently negative, yet that doesn’t have to be the case. Often conflict arises because different people have different backgrounds and perspectives. As BAs, we can explore those perspectives and understand the specific areas where they agree and disagree. We can work with them to navigate the conflict, and reach a situation that they are happy with.

In many ways, if there are conflicting views, it is usually better if they are surfaced earlier rather than later. If someone disagrees but doesn’t feel able to raise the issue, then this may indicate that they feel uncomfortable. Perhaps psychological safety is lacking. Either way, this may indicate wider issues with the organizational culture, and may mean that dissenting voices are being quashed. Which can be an issue if one (or many) of those voices are right!

Lead by Example

This is an area where BAs can lead by example, by being bold and sometimes vulnerable, by asking ‘tricky’ questions and being open and honest when we think something isn’t right. It’s also important to be prepared to change our minds when new information presents itself. All of this relies on building good rapport with stakeholders, which is a key BA skill in itself!

Ode to a Picture

Written by Karen Schemmel on June 8, 2023. Posted in Articles.

Practically everyone has heard the expression “a picture paints a thousand words”. In the world of art, a picture can be used to express ideas and evoke emotions, or it can also simply be used to capture on canvas something or someone significant. In the professional world, carpenters and architects rely on drawings to build to precise specifications. In the business analysis world, the whole purpose of creating a picture, otherwise known as a diagram, is to clearly communicate information without using words.

There are many different types of diagrams at our disposal, and I will attempt to name a few key ones here: entity, activity, data flow, sequence, use case, flowchart, system context, workflow, object, component, and UML. However, the focus here is on what you want to convey to your audience through a diagram and the benefits of doing so, rather than how or which diagram you should use to do so. The point is to emphasize the benefits in the use of diagramming in many situations to communicate meaningful information and transform your business analysis efforts!

What a Diagram Can do for You

Diagrams can tell a story from numerous perspectives. For example, they can be used to confirm our understanding of processes, or to define system interfaces. They can illustrate system and network connectivity. They can help to explain complex processes. Diagrams can depict workflow, business processes and system interactions. They can help to define in scope and out of scope features. They can also help establish or confirm understanding between the business analyst and a stakeholder in a way that verbal or written words sometimes cannot.

Diagrams can help confirm requirements by illustrating what needs to happen in a system or workflow. They can also be used to model database structures and to depict data flow. Diagrams can cut across confusing jargon or long-winded verbal or written explanations and get right to the point in the simplest of terms. When you consider all of the benefits, the power of a diagram is undeniable!

Diagrams are Blueprints to the Past, Present and Future

Diagrams can be used as blueprints for past, current or future conditions. For instance, diagrams from the past can help explain why outdated processes or procedures might have come into existence. How many times have you come across the question “why do we do this”? The typical answer of “because we’ve always done it this way” never solves the problem.

If only you could time travel back in time to document a process using a diagram so that in the current day you or anyone else could easily answer any questions about the “why’s” of a process or procedure. Prevent this lapse of information for future questions and diagram your process!

Take Time to be in the Present

Although your stakeholders (and you) might be very familiar with the tasks and workflow used with a given process, it is still beneficial to take the time to depict current “as-is” diagrams. These diagrams are helpful to illustrate current interactions between actors and systems as well as point out manual tasks that might be targets for process or system improvements. Current state/as-is diagrams can also serve as a valuable documentation tool. New employees and auditors alike tend to appreciate the information conveyed in a diagram.

Additionally, going through the process of building out diagrams for current business systems and stakeholder processes can help demonstrate the need for better written procedures. Current state diagrams can also help point to key performance indicators when changes are proposed. For instance, when comparing the proposed future state to the current state, time-consuming manual tasks will hopefully be earmarked for potential elimination. Having these diagrams at your fingertips can make these improvement opportunities stand out, which will make the task of quantifying the time saved or cost savings (or whatever differences) that much easier to document.

Illuminate the Future

Future state or “to-be” diagrams can help to illuminate the roadmap for upcoming changes, whether that might be a business process, a system component, or a new business system altogether. For instance, they can help define system changes and plan improvements to technical interfaces, thereby avoiding future outages. They can help to confirm our understanding of impending changes to processes and to thereby plan accordingly. They can also help identify the business processes that may become obsolete. Future state diagrams can also help the organization stay focused on the planned and specified changes or help to inform decisions to adjust the plan if necessary.

Conclusion

As a business analyst, the diagram has to be one of the strongest tools in the arsenal of BA weapons. There are so many uses and applications where a diagram can transform work efforts. It doesn’t have to be fancy or complex. In fact, the simpler the better. The point is to use a diagram to convey the desired information in as clearly a manner as possible. The benefits of a diagram can be felt across all levels of the organization, communicating across different levels of knowledge and understanding. Diagrams can clarify information for stakeholders and business analysts alike.

They can validate or improve existing understanding and inform future changes. They can serve as documentation for auditors, and training tools for staff. Diagrams can highlight the need for improvements and underline performance improvement indicators.

The uses and benefits go on and on, so hopefully this will inspire you to take a little time in each of your project efforts to paint the picture that will prevail in communicating your message and save yourself a thousand words!

The Three Cs of Business Analysis

Written by Sarah Mullen on June 7, 2023. Posted in Articles.

Recently I returned to work from an extended leave and was immediately thrown into the deep end of the pool with an assignment on the next phase of a major project. There was hardly time to get my bearings before needing to elicit requirements and write user stories, much less be able to understand how the product owners want the product to function. As a result of my rapid reintroduction to the project, I came to quickly appreciate the Three Cs of Business Analysis: Connection, Communication, and Collaboration.

1. Connection

Building connections is one of the most important things a business analyst can do. Forming relationships with stakeholders, development and QA teams, product owners, and many other individuals is vital to reaching a good output. I had the benefit of previously working with many of the same individuals, which made it much easier to jump back in quickly, as I already had those established relationships. However, for those individuals with whom I had never worked, the lack of time to build those connections has made it more challenging to understand their processes and how I can contribute to help them perform their jobs more effectively.

Obviously, the longer you are with a company, the more time you have had to establish and strengthen connections with those stakeholders around you. Even something as simple as a quick chat in the breakroom or reaching out with a simple question goes a long way in deepening those relationships, which makes life much easier when you need to work with those individuals on a project. Connections are resources of information, and the more resources you have, the easier it is to obtain information when you need it.

2. Communication

Whether you have good relationships or are just getting to know your stakeholders, establishing good communication practices is a top priority. Each stakeholder may prefer to receive communication via different methods, so understanding the best way to communicate questions or information with each individual is something that should be established early in your relationship. Some stakeholders prefer email, some do better with IM, others need direct communication via a meeting; and if you attempt to communicate with someone in a less-than-desirable method, there may be delays in obtaining the needed information. I have dealt with product owners who rarely respond to emails but will respond to an IM within an hour; I have also known other stakeholders who are the exact opposite.

In my case, since I had previously worked with many of those stakeholders, I already had a good idea of how best to collaborate. This made it much easier to quickly jump back in and get the answers I needed to my questions. For those individuals with whom I had never worked, we’re honestly still figuring it out. Obviously, whether you are co-located also makes a big difference in establishing relationships and best practices for how to communicate. Being able to walk to someone’s desk vs having to send a meeting invite does matter and can make it more challenging to get started.

3. Collaboration

The third C is what completes the circle…collaboration. We can build connections and learn how to communicate with those individuals, but it will all be for naught unless we collaborate. The Webster’s definition of collaboration is simple but explains exactly what we need to do: “To work jointly with others or together especially in an intellectual endeavor.” As business analysts, our job is to bring stakeholders and team members together, which means we must be the bridge that allows all interested parties to be part of the discussion. Now, what that looks like in reality can mean many different things depending on the scenario. It could look like:

A requirements elicitation session with stakeholders
Working with UX designers and product managers to understand how the design will allow the requirements to be met
Meeting with developers/testers to review stories and understand the level of effort
Reviewing the level of effort with product owners to determine priorities

Being part of the collaboration discussion with stakeholders on a project, as well as simply facilitating the discussion so various stakeholders can collaborate amongst themselves, are both tasks we perform as business analysts. If decisions are made in a silo without that collaboration, the result can be missed requirements, incorrect implementation, and dissatisfied clients. We must collaborate in order to understand the big picture and how requirements fit within the design and how the implementation functions, so we can ensure the client receives the intended outcome.

Forming connections, establishing good communication practices, and collaborating with all individuals involved in a project are three of the key pieces to building a successful product. They also make it much easier to float when you’re thrown into the deep end of the pool on an inflight project!

Factors Impacting Analysis

Written by Virginie Terry on May 3, 2023. Posted in Articles.

As Business Analysts, we are experts at defining good quality requirements and processes that enable the implementation of solutions which are fit for purpose and deliver the benefits from the business case. We may have several Business Analysis qualifications and many years’ experience working on all types of projects, from simple process changes to complex technical overhauls with multiple integrations, data migration and significant business change elements, and everything in between.

Yet our skills are just one of the many components that enable us to do our job well. There are some other factors which we don’t have much control over but which are also hugely important. We need to be aware of them and should consider them upfront and throughout the delivery of our projects to set ourselves up for success. Unsurprisingly, they can all be grouped under communication within project teams and organizations’ delivery standards and processes.

Consider the delivery model

Are the delivery frameworks from your organization and any third party you are working with aligned? Organizations tend to have slightly different definitions of the same terms, for example “delivery phase”. Does the delivery phase consist purely of coding and configuring what has been defined in great detail in previous, distinct analysis and design phases? Or will the delivery phase also include collaborative sessions at the start where technical teams, BAs and users flesh out these details together?

Consider roles and responsibilities

This is particularly important in organizations which have a high staff turnover, use many contractors or employ staff on short, fixed term contracts. The execution of testing can be a grey area for example, particularly User Acceptance Testing (UAT). Who is expected to write the test scripts? Is it the Tester(s) on your project, the business Subject Matter Experts (SMEs), or even yourself?

Consider the experience from other key roles within the project team

Do the Project Manager and other key roles within the project team have a good understanding of the role BAs play, what we do and don’t do? For example, do they know that BAs need to be present in all meetings with the users and technical team(s) where the scope is discussed? Or that we cannot make an on-the-spot decision about the validity of a change request, such as descoping an area of functionality because of new budget constraints, without assessing the impact on the processes and the integrity of the solution overall?

Consider the project plan

How will the project plan be produced? Do you need to do some “right to left” planning, because the go-live date can’t be moved, which is common on a lot of commercial or regulatory projects, or can you estimate the duration of each phase before agreeing on a go live date?

In the first scenario, you will need to timebox each activity and almost certainly compromise on some elements of your analysis. In both cases you need to really think through any assumptions which are being made around the effort required to produce each deliverable and any dependencies. You should also document any risks you foresee as a result of the approach being undertaken.

One common oversight is the business users’ availability to support the project, which can really hinder progress if not managed effectively. This can range from planned absence, such as annual leave, to having to perform Business As Usual (BAU) activities no one else can backfill, or supporting other projects which have a higher priority.

Consider the project governance

Does your organization have well defined processes to govern the decisions required around the different project milestones and the challenges you will meet in the course of the delivery? For example, are you clear on the documentation that you need to produce, or contribute to, at each stage gate? What is the change control process you need to follow when a new requirement emerges after the requirements catalogue has been baselined?

Consider the Sponsor’s role

Sponsor engagement, and the BA’s access to the Sponsor, are critical to the success of the project. Are you able to have one-on-one meetings where you can speak openly to update them or seek guidance when you are uncertain about the direction you should follow? Does your Sponsor know the level of involvement they need to have so that they support you, the Project Manager, and the delivery of the project, without interfering with the methodology or the due diligence required, for example?

Conclusion

There are no simple answers to these issues. Every organization has its own culture, and each project team has specific dynamics.

However, identifying them as early as possible means that you can prepare for them and address them effectively within the constraints that you operate in, even if it means you’re not able to follow best practice. When dealing with these challenges, regardless of your level of experience, you will achieve something much bigger than the delivery of your project.

This may be learning something new about the way that you communicate, educating your colleagues about the role of the Business Analyst, or even instigating an improvement in the way in which your organization delivers change.

360° Feedback for BA Teams

Written by Christina Lovelock on April 12, 2023. Posted in Articles.

Does your BA team actually care what other people think of the BA services provided?

Many business analysts do not consider their internal stakeholders to be ‘customers’. So when we try to understand ‘what customers think of us’ it’s common to only consider the ultimate end user of the organizations’ products or services.

Feedback

It is important for BA teams to seek regular feedback. This enables continued service improvement and growth. Knowing what our stakeholders think of our services provides both suggested improvement areas and a baseline from which improvement can be evidenced. It also helps BA leaders make the case for strategic and financial decisions, such as recruitment or investment in professional development activities.

Zones Of Feedback

Using a 360 approach allows us to consider the different groups of customers and stakeholders whose opinions matter. The perceptions of the performance and capacity of the BA team all impact the reputation, effectiveness and influence of business analysis within the organisation.

If the BA team is considered to be unresponsive or inflexible in our approach – internal customers may try to work around the BAs or actively avoid engagement. Ensuring the BA practice or team has a positive reputation is key to being engaged at the right time and being able to carry out appropriate business analysis activities.

Zone 1 – The BA Team/Practice

As with any team, its important for managers and leaders to understand if its members are happy. Do people like being a member of this team? By asking questions about wellbeing, workload and future plans, we can understand if people are happy in their BA role. This includes:

How are we doing as a team?
What could we do that would make your role easier?
What can we learn from other places you have worked?
Are you hoping to progress within the organization within the next 18 months?
Is your workload manageable?

When team members feel that they are supported and appreciated, they are much more likely to perform well in their role, and stay longer within their organization.

This should be one of the zones from which feedback is sought most frequently. This can be a combination of anonymous quantitative feedback (quick polls, pulse surveys etc.) to inform simple metrics and more detailed qualitative feedback based on conversations to allow a deeper understanding of views.

Zone 2 – Multi Disciplinary Teams

These are the teams which individual BAs contribute to. This might be project or delivery teams brought together for a fixed time period, or product teams with ongoing responsibilities for product development and maintenance. It is useful to understand the experience and perspective of the customers who work with business analysts day-to-day. Do these close colleagues understand and value the contribution made by business analysts to the team?

Feedback should be sought at sensible times, such as delivery milestones, when a BA leaves an assignment/team, or as in input to structured performance review cycles.

Where projects/stakeholders continually request the same business analyst(s), it suggests a lack of faith in the BA team and a reliance on the skills/knowledge of an individual. If that is the case, how can the BA team share knowledge and skills and improve consistency of the BA services delivered?

It’s also worth considering if feedback received is actually about BA capacity (being over loaded/ too stretched) rather than capability, and how that issue could be addressed.

Zone 3 – Other Professional Disciplines

This zone includes all the related and adjacent professional disciplines within the organisation, who the business analysts sometimes interact with. This includes business functions such as HR, finance, marketing, compliance, business teams and subject matter experts. Often they don’t form part of multi-disciplinary delivery teams, but BAs may often interact and engage with them. Its useful to understand the reputation of BAs amongst project managers, product owners and developers – even ones who don’t regularly interact with BAs. How likely would they be to spot the need for business analysis activities and seek out a BA?

Zone 4 – Pipeline Professionals

This is the potential talent pipeline into business analysis from elsewhere in the organization. Roles such as IT helpdesk, call center operatives and front line business teams. Do they know business analysis exists within the organization? Do they aspire to become BAs? Are there routes for them to follow? Do we provide opportunities to share our skills and knowledge to make business analysis visible, accessible and desirable? In a competitive recruitment market and for a competitive advantage, we cannot afford to ignore internal development routes into business analysis.

Zone 5 – Senior Leaders

This zone includes all senior leaders and decision makers. Not just whichever executive has reporting line responsibility for business analysis, but all influential leaders. The skillset of business analysts has a huge amount to offer those in leadership positions: BAs are objective critical thinkers, able to identify and define problems and investigate feasible solutions. Few zones of the organization need access to these skills more than the leadership team!

Do they know how business analysts offer value? Do they know how to get BAs involved? Are they factoring business analysis time and resources into their strategic plans and estimates? Do they genuinely want more evidence based decision making? If so, they need more business analysis!

It’s hard to get the time and attention of these leaders, but for us to help them (and the organization, to the best of our ability), they need to know we exist.

External Stakeholders

Any of these zone could also extend to cover external stakeholders, such as third party suppliers, partners, regulators, and external clients. While it may not be possible to engage in formal feedback processes due to organizational relationships, it is still possible to seek appropriate informal feedback to strengthen relationships, understand expectations and ultimately improve results.

Methods Of Obtaining Feedback

A variety of different approaches can be used, and this needs to take into account the culture of the organization and the expectations of different groups.

Consider a mix of:

Informal catch-ups over coffee
Email requests
Online surveys/ system
Formal recognition and review processes.

“We haven’t done it before” and “no one else does it” are not good reasons to avoid seeking feedback!

Conclusion

By thinking about these zones of stakeholders it is possible for the BA team to get a 360° picture of our performance, perception and reputation. If we don’t like the feedback, or don’t feel it reflects reality – then what action does that prompt? We can’t change opinions for the positive, if we are too scared to ask about current perceptions.

If BA teams can be brave and lead the way on establishing a 360 feedback culture, it will lead to better results and better relationships in the long run. It will also normalize the giving and receiving of feedback, which is a key contributor to high performing teams.