Skip to main content

Tag: Communication

Just because you are in the minority doesn’t mean you are wrong!

Speak to any group of BAs, and they will empathize with the frustrations of a familiar experience: you have spotted a potential problem on the horizon, but you’re struggling to convince teammates and stakeholders that it needs addressing (or even that it exists at all).  Argh!  So why don’t people believe us, and how can we help them see what we see?

 

The unique BA perspective

Even if you work collaboratively with a range of stakeholders, the nature of the BA role makes you something of a solo operator.  You are often the only one of your kind assigned to a multi-disciplinary project team, and – while you will be consulting widely with others – the analysis input of your role comes from you alone.  Working at the interface of many sources of information puts you in a unique position to see things others can’t.  It is both a blessing and a curse: while you can add value by making inferences and drawing conclusions that aren’t obvious to the folks on the ground, your insights are not always readily received when those folks are preoccupied with other lines of endeavor.  You want to share your findings to help improve outcomes; they want to get on with their work without the BA derailing it.  You may not be a specialist in their area, so why should they believe you?

 

The best of times

If you have good working relationships with your team or stakeholders, a carefully timed question or constructive conversation is all you need.  Project professionals are often keen problem-solvers like you.  If you need to spend more time unpacking each other’s points of view, you can resolve most queries amicably with a chat around a whiteboard.  Be mindful that specialists won’t necessarily welcome direct challenge from a non-specialist: in these situations, you may find it beneficial to cast yourself in the ‘apprentice’ role.  Ask your specialists to help you, the interested non-specialist, understand the matter at hand by walking you through an explanation; you can then cannily insert your leading questions at the appropriate point.  You may, of course, have misinterpreted something and be flat-out wrong – so be prepared for that eventuality!

 

The worst of times

Sometimes, however, that initial conversation doesn’t cut it.  You’re still sure that you’re on to something – the discussions haven’t disproven your theories – but you cannot get others to consider, let alone understand, your way of thinking.  You feel like the prophetess Cassandra of Troy from Greek mythology: fated to see the future and obliged to speak the truth, yet never to be believed.  So what’s a BA to do – why isn’t the message getting through?

 

Advertisement

 

Understand the problem

As with any analysis, the key is to identify the root cause of the issue.  It’s easy to take it personally when your concerns are dismissed without consideration but don’t automatically assume malice.  There are lots of reasons why people may not be responding as expected:

  • You might not have communicated your ideas as clearly as you thought.
  • You communicated clearly but caught them on a bad day.
  • People with other viewpoints outrank or outnumber you – people tend to be swayed by power or a majority.
  • They might not feel secure in what they are doing and don’t want to be challenged by any ideas that could throw things off balance.
  • They may lack the contextual knowledge or technical aptitude to understand your ideas.
  • They have different priorities (or different agendas!).
  • You might not be their ‘preferred sender’.

The last point can be incredibly frustrating.  Sometimes, despite you doing absolutely everything else right, you are just not the person to whom your audience is willing to listen.

 

Formulate your plan

Once you’ve figured out what’s going on, it’s time to get a communication action plan together.

  1. Identify your target person or people.

To achieve your desired outcomes, who do you need to persuade to consider your point of view?  Sometimes, this isn’t the person you think of first.  Is there another individual whose voice is more likely to carry weight with your ultimate target?  If so, it may be better to channel your energy into helping this individual understand your concerns and letting the message travel forward via them instead.

  1. Curate your materials and your messaging.

Cut the waffle: what are the key points you need to communicate?  And how are you positioning your message?  If the presentation format you’ve used so far hasn’t worked, try something new: can you package things up differently?  People often respond favorably to visual material if it helps them get to grips with something less familiar.  Sometimes a diagram can make all the difference.

  1. Build your coalition.

Are there others who understand your perspective and could help influence the conversation with your target person or people?  More people saying the same thing can add credibility to your message through endorsement and weight of numbers.

  1. Pick your moment.
    Timing is everything. Your message is unlikely to land well if you try to share your thoughts in the middle of an unrelated but all-consuming disaster, for example!  Aim to create appropriate time and space for a calm, focused discussion.
  1. Be prepared to play the long game.

It may take several attempts to land your ideas, particularly if you have had to involve other people to help deliver your message.  Consider the overall impact of your interventions on your target person or people.  How will the sequence of interactions be experienced from their point of view?

Once you have the above in place, you can initiate your plan.  Good luck!

 

Know when to hold and when to fold

One of the more difficult things to accept as a BA is that things don’t always go how you think they should, even if you have the truth on your side.  It’s a great feeling when your suggestions are recognized, valued, and help shape the work to come, but it’s equally likely that you will hear: ‘Yes, I understand what you are saying, but we have to do it X way because of Y.’  Don’t feel disheartened if this happens to you.  If you have managed to get people to understand your point, no matter the eventual outcome, you have done your job.  You have identified a potential issue, surfaced it for consideration by the appropriate stakeholders, and enabled an informed decision to be made in consequence.  There is one less unknown in the project landscape; it’s time to let that point rest.  Onward to the next challenge!

Think “Re-use” When Writing Requirements

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.

 

Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page.  Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard?  This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world.  This is just one example.

 

Advertisement

 

High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow.  One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)

 

Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.

 

But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?

Constructive Conflict Is Better Than False Agreement

Over a decade ago, I was in a workshop with a range of different stakeholders.

 

Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule.  Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words.  They simply said:

“I disagree”

I remember being taken aback by the bluntness.  I live in the UK and our communication style is somewhat indirect most of the time.  It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”.  Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”.   I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable.  Someone was breaking the consensus; they were “creating conflict”.  Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead.  Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed.  What’s more, other attendees of the meeting started to question things, interject and show disagreement.   One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so.  And you know what? I am convinced that the output of that meeting was better as a result.

Advertisement

Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good.  I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement?  If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners.  Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction.  Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations.  We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion.  We can lay down an appropriate set of ground rules that allow for differences of opinions to surface.  I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion.  That’s to be expected.  With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial.  Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too.  Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”.  When someone says it they provide us with a gift, an opportunity to better understand them.

Best of BATimes: Deal Breaking Soft Skills – The Essential BA List

If you don’t have the right soft skills, you will struggle as a BA. Business domain knowledge and hard skills can be taught.

 

But finding a BA with the right set of soft skills can be a deal breaker for employers. And no, it’s not just the ability to read, write and converse. So which soft skills do you need?

Heads up

In this post I will be going over the soft skills which are essential for a BA.

Communication

  • Being a good listener, showing that you are patient and empathetic. Actually listening to the DEV team when they say a feature can’t be achieved. And being transparent with the business when explaining the same.
  • The ability to explain difficult (and sometimes simple) concepts/ideas/justifications (anything really) at all levels.

For example, walking through a business process with your DEV team. Clarifying business terms and ideas which they not be familiar with. Translating that into how the system works and explaining the value provided to the business.

  • Being able to articulate answers to questions clearly and clarify points on the spot. For example, not confusing the business with technical terms. Explaining concepts in a way that they will understand. Even if you don’t know the answer (rather than making something up) say that you will find out and get back to them later (and actually do that).

(Difficult) Stakeholder Management

  • Managing your emotions. Not all stakeholders play nice. You will always (always!) have one or more difficult stakeholders. You need to understand their motivations and why they are being difficult. The key is to maintain your professionalism and not let your emotions get the better of you.
  • Influencing. This also includes influencing without formal authority, persuasion and negotiating. Your reputation helps significantly here. If you are known to get things done and do what’s best for the company/client, your stakeholders will be more inclined to see things your way.

Managing Expectations

  • Showing you are in control. The business/stakeholders/your boss needs to know you have a handle on things. The worst thing you can do is pretend that everything is ok but in reality, it’s all falling apart. You must be clear about your workload and ability to deliver on time. If things are slipping, make sure you have evidence why. For example, maybe the business is not cooperating during requirement’s session. Possibly the vendor has screwed up somewhere. Maybe you have too much on your plate and you need to offload some work.

Diplomacy

  • The ability to understand office politics. For example, knowing who can get things done for and who always plays hardball.
  • Conflict resolution. Ideally conflict mitigation. Knowing when a situation can get out of hand and how to resolve it quickly.
  • Knowing what to say and to who. You will probably know certain people in your organization who you will want to avoid unless you really (really!) need to speak to them.
  • Having the ability to speak the truth and gain trust but also not “putting your foot in it”.
  • Learning how to tell people in power that they are wrong without them feeling like they are!
  • Not oversharing information to the wrong people and opening cans of worms which can impact you later.

 

Advertisement

 

Analytical Thinking

  • Being naturally good at working out problems. Being able to dig deep to find out the the root cause of an issue. (link to root cause)
  • Reading people/understanding people. The ability to sense when stakeholders are reserved and giving them the power to speak up and be heard.
  • When a stakeholder asks for something, being able to understand what they really want but are struggling to convey. Working out when people are masking the truth or too scared to speak up.

Adaptability

  • Handling pressure and stress. For example, working towards deadlines which might change at the last minute. And having to drop things and work on something else more urgent.
  • Dealing with WTF situations. For example, being dropped into a major production issue which is affecting the company’s revenue and the stakeholders are looking to you to get them out of it.

Relationship Building

  • More than just chit chat. You need to build effective working relationships by being known for:
    • Getting things done
    • Doing what you say you will do
    • Going the extra mile when needed
  • Being able to call in favors based on trust
  • Knowing who to ask when you need answers to difficult questions
  • Know who to ask (if they don’t know) to find out who else might have the answer to your questions

Leadership On Demand

  • Leading a group of BAs (e.g. in your managers absence), leading workshops and coaching junior staff

In this post I went over the soft skills which are essential for a BA. Effective soft skills are often taken for granted. I was guilty of this myself early in my career. Over time I have worked hard to develop my soft skills (and still continue to do so). Are there any surprises in my list? Anything you would like to add?

The Strawman: When a Wrong Makes a Right

Sometimes, the easiest way to find out what someone really wants is to show them what they don’t want.

The strawman approach is frequently used by business analysts – sometimes knowingly, and sometimes not. Actively inviting stakeholders to engage with and criticize an inaccurate reflection of requirements can provide insights that greatly speed up the requirements elicitation process. However, it can also be a risky approach.

This article describes that strawman approach, its potential pitfalls, and tips for using the approach to support productive requirements elicitation.

What is the Strawman Approach?

You may have heard of a strawman argument – an argument that distorts an opposing stance to make it easier to attack [1].

In business analysis, a strawman can be created by presenting knowingly incorrect, incomplete or distorted requirements to stakeholders in order to provoke a response. This is usually done in the form of a model or prototype solution, providing a visual representation that stakeholders can engage with and refute. The idea is that the way stakeholders respond to the inaccurate strawman will inform more complete, coherent and representative stakeholder requirements.

Stakeholders often find it difficult to articulate their requirements. They can be vague when it comes to specifying their wants (I want a bright color…), yet very specific when it comes to specifying what they don’t want (…but not pink!) This is because people often find it easier to specify their wants and needs in opposition to something. In such cases, presenting an inaccurate or incomplete model/prototype representation of requirements as a strawman can provoke a strong response from stakeholders, creating a better understanding of what they don’t want, and providing a starting point for conversations about what they do want.

 

Advertisement

 

The Pitfalls of the Strawman Approach

While the strawman approach can be a powerful requirements elicitation technique, the approach should be used with caution. Some of the potential pitfalls associated with using a strawman include:

  1. Impact on your credibility: When done right, presenting a strawman to stakeholders can make a business analyst appear open, co-operative, and responsive to stakeholder needs. However, presenting something that is clearly wrong can also impact a business analysts’ credibility, leading some stakeholders to question the analyst’s abilities.
  2. The strawman becomes the answer: The point of the strawman is that it isn’t accurate! You want stakeholders to refute it and provide information that will allow you to change and/or improve it. However, in cases where stakeholders really do not know what they want, they may not challenge the strawman. This could lead to the strawman (either in part or whole) becoming the answer.
  3. The business analyst can feel exposed: Presenting a strawman is not an easy thing to do. It takes a degree of professional courage to produce a piece of work and present it, only to have it criticized – even if that was the intention.
  4. Some stakeholders are too nice: Some people find criticism difficult and may be unwilling to say what they really think about a strawman, particularly when they are being asked to criticize it in a group setting.

Tips for using the Strawman Approach

The following are a few tips to consider when using a strawman to elicit requirements:

  • Do you research. Make the ‘strawman’ as accurate as possible. Differentiate between elements of the strawman that are based on known, more accurate requirements, and those that are ‘best guesses.’
  • Know your stakeholders. Think about how your stakeholders might react to the strawman. Think about how you present the strawman to different stakeholder groups. Consider presenting the strawman to ‘friendly’ stakeholders 1-on-1 to get feedback to improve it, prior to exposing it to more influential stakeholders and/or a larger group.
  • Acknowledge it is a strawman. Sometimes acknowledging what you are presenting is a ‘strawman’ will give stakeholders the permission they need to constructively criticize it.
  • Don’t rely on it. The strawman approach should not be used as a primary requirements elicitation approach, but rather a tool that may be deployed to elicit those more subjective requirements, engage a particular stakeholder group, or as a check for validating what you know and what you don’t.
  • Clearly label your strawmen. Once in the wild, the strawman can obtain a life of its own, being reproduced and/or discussed in unintended places. Therefore, it is important to clearly label, store and/or otherwise indicate the strawman is a draft, prototype or experiment.
  • Don’t take is personally. Remember, the stakeholders are reacting to and criticizing what is presented to them – not you personally!

 

Reference
[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology, www.effectiviology.com/straw-man-arguments-recognize-counter-use/