Skip to main content

Tag: Communication

Who Moved My Cheese and Stakeholders?

The Sniff’s, Scurry’s, Hem’s, and Haw’s of Transformation Efforts

Author: Amanda Zurn

Stakeholders can be seen as the wildcard in our engagements. We may not know or understand how they will react to our engagement efforts which can cause uncertainty and anxiety as we prepare to do our work.

IIBA BABOK v3 describes Stakeholders as:

A group or individual with a relationship to the change, the need, or the solution. Stakeholders are often defined in terms of interest in, impact on, and influence over the change. Stakeholders are grouped based on their relationship to the needs, changes, and solutions.

 

Stakeholders are one of the components of the Business Analysis Core Concept Model (BACCM) as defined by the IIBA.

Each component is equally important and necessary to the practice of business analysis. Neglecting one component can have a negative impact on our work activities and the overall success of initiatives. This blog will focus on the Stakeholders component.

The BACCM is applied to each Knowledge Area in the BABOK and frames each component to the specific Knowledge Area. The following frames Stakeholders with respect to each Knowledge Area:

  1. Business Analysis Planning and Monitoring: perform a stakeholder analysis to ensure planning and monitoring activities reflect stakeholder needs and account for stakeholder characteristics.
  2. Elicitation and Collaboration: manage the collaboration with the stakeholders who participate in the business analysis work. All stakeholders may participate in different roles and at different times during a change.
  3. Requirements Life Cycle Management: work closely with key stakeholders to maintain understanding, agreement, and approval of requirements and designs.
  4. Strategy Analysis: collaborate with stakeholders to understand the business need and to develop a change strategy and future state that will meet those needs.
  5. Requirements Analysis and Design Definition: tailor the requirements and designs so that they are understandable and usable by each stakeholder group.
  6. Solution Evaluation: elicit information from the stakeholders about solution performance and value delivery.

Successfully navigating the people/stakeholder aspect as a business analyst can be part of the art of our role. Each of the stakeholders related to our work responds differently to change and transformation efforts. This difference is not only found between each of the stakeholders but can also evolve over the career of an individual.

Dr. Spencer Johnson pens a short fictional story about navigating change in his book titled “Who Moved My Cheese?”. The characters in the book represent the different ways we see ourselves and others responding to change.

Characters:

  • Sniff: is always looking for what is different, anticipating change.
  • Scurry: quickly moves into action when change occurs.
  • Hem: denies and resists change and is known to say, “it has always been done this way”.
  • Haw: contemplates change and adapts after processing and accepting change.

As business analysts, we support the ability of the organization to successfully transform. Through our initiatives, we engage and guide our stakeholders who embody the Sniff, Scurry, Hem, and Haw characters.

The more we learn about our stakeholders and decipher which character represents them, the better we can determine how to engage each stakeholder during our work activities. We want to do this as early in the engagement as possible. The following are a few points for consideration related to each character in “Who Moved My Cheese?”:

  • Sniff:
    • Pro: Is an early adopter and change advocate. Known for finding new options to address challenges in the organization.
    • Con: May be distracted by the next “shiny” thing.
    • Strategy: Leverage their enthusiasm for new ideas.
    • Actions: Involve them early in brainstorming sessions and innovation discussions. Encourage them to spread the word and show adoption.
    • Communication: Provide updates with the latest developments and potential opportunities.
  • Scurry:
    • Pro: Quick to action and accepting change.
    • Con: Is reactive and may not understand “why” the change needs to occur.
    • Strategy: Capitalize on their readiness to act.
    • Actions: Assign them tasks that require quick execution. Provide clear and concise instructions to ensure they understand the objectives and move forward in the correct direction.
    • Communication: Be direct and to the point. Regularly check in to ensure they are on track and address any issues promptly.
  • Hem:
    • Pro: Provides historical reference as to “why” and “how” things have been done to date.
    • Con: Can be contradictory and resistant due to unwillingness to let go of what has become comfortable.
    • Strategy: Address their resistance to change.
    • Actions: Provide reasoning regarding necessity of change. Help them see their role in realizing the future state. Involve them in discussions to gather their insights and address their concerns.
    • Communication: Be patient and empathetic. Make a safe environment to share their concerns and truly listen and understand their perspectives. Use data and evidence to demonstrate the need to change is based in thoughtfulness.
  • Haw:
    • Pro: Through contemplation, can ground the team and ensure thoughtfulness is applied to change efforts.
    • Con: Can drag out the analysis process creating the risk of missing the opportunity the change would create.
    • Strategy: Support their thoughtful approach to understanding the need to change.
    • Actions: Give them time to process information and buy into the change. Encourage them to share the reasoning behind the change.
    • Communication: Engage in detailed discussions and provide comprehensive information. Highlight the benefits and potential risks of the change to help them gain understanding.

A point I contemplated was group work. What if each member had strong tendencies of one of the characters? Or the team was a mix of the four characters? As an example, it would be important to know early if the team had Scurry tendencies. I can foresee a team eager to find the path to change but moving in many directions at once and engaging in “trial and error” methods until the envisioned future state is realized. What if a Sniff or Haw were added to the team? Will these individuals balance the team?

As business analysts, we may or may not have the luxury of choosing those in which we engage, but we can certainly conduct stakeholder analysis to understand those we engage and create an engagement strategy to maximize the strengths each character brings to the team.

“Who Moved My Cheese?” is a simple story with an applicable message to our business analysis work and to our personal lives. I invite you to read and contemplate the message contained in this book found in the Development Center.

Questions to reflect upon:

  • Which character do you relate to the most? Has that changed over time?
  • Which character best represents those in which you engage?
  • What has or has not gone well in your stakeholder engagements? Why?
  • What strategies can you use to capitalize on the pros and minimize the cons each stakeholder brings in your engagements?

 

Cultivating Curiosity

Cultivating Curiosity

Curiosity is the BA superpower. But is it a trait we are born with or a skill we can cultivate?

Benefits of curiosity

Bringing genuine curiosity to our discussions helps to foster deeper connections. It improves our understanding of situations and creates empathy with those involved. Curiosity leads to better solutions to problems. Being curious stops us from using mental short cuts, making assumptions and applying biases.

There are several studies showing that:

  • There are positive correlations between curiosity and wellbeing
  • Openness to new experience predicts levels of life-satisfaction
  • Greater levels of curiosity are associated with greater resilience.

Curiosity also protects us from poor decision making and jumping to judgement.

Curiosity versus judgement

When we rush to judgment, it closes our eyes to different perspectives and different possibilities.

Remaining curious for just a little longer, before formulating judgements helps us to keep an open mind with our stakeholders, projects and products.

Curiosity is really the opposite of judgement as it is incredibly difficult to be judgemental if we are truly curious about a situation or person.

Barriers to curiosity

What can get in the way of applying an appropriate level of curiosity in our work?

  • “Time” (which really means “priorities”)
  • Too much domain/ subject matter knowledge
  • Bias towards action
  • JFDI culture
  • Lacking tools, support or willingness
  • Worry about asking a stupid question
  • Feeling inadequate, intimidated or afraid

There are lots of things which can prevent us from being curious, or from acting on our curiosity. If that happens our organisations will make the same mistakes, fall into the same traps and fail to learn and innovate.

Curiosity, experience and aging

Children a naturally inquisitive, but most of us lose this attribute as we age, because we have found many answers and now have frames of reference for so many situations. Curiosity can be seen as analogous to naivety, which is not the same at all! Gaining experience does not replace the need for curiosity. Curiosity is the route to increasing our knowledge and experience. As we age, we must be more conscious of the need for curiosity and build it into our approach. Research from the University of Reading (2018) suggests that “While curiosity seems to decline with advancing age, it can also be a proxy for maintaining cognitive functioning, mental health, and physical health in older adults, thus serving as a conduit for “successful aging.”. It seems that maintaining curiosity is good for us.

Techniques for encouraging and enabling curiosity

There are a number of ways we can bring more curiosity into our lives, and in particular our professional practices. Including:

  • Brainstorming for questions about a topic  before we start asking for suggestions and answers.
  • Adopting “Learn it to teach it” – set learning tasks with a view to sharing that knowledge with others
  • Leveraging existing interests – encourage people to share existing skills and knowledge (which may or may not be work-related) as a “skills exchange”.
  • Applying active listening techniques – giving our full focus, using probing to get more depth and summarising to confirm understanding.
  • Praising curiosity – when we see people around us being inquisitive, asking good questions and identifying assumptions, draw attention to these positive behaviours.
  • Encourage work-shadowing – experience processes and challenges from another perspective and discover unknown unknowns!
  • Using the 6 Thinking Hats – to encourage different perspectives to be taken
  • Experimenting defining and testing assumptions and hypotheses, using pilot programmes and adopting a proof-of-concept approach.
  • Role modelling curiosity – demonstrate it is OK not to know, and that if you don’t know, it’s OK to ask!

 

Simply talking more about the expectation of curiosity creates the permission and reminder that some people need. There can be no improvement and certainly no innovation without curiosity.

Conclusion

Curiosity is closely linked to a growth mindset, reminding us that there is always more to learn. As individuals and as business analysts, we are never finished products. Our capacity for curiosity isn’t fixed; it’s a skill we can nurture through deliberate practice. There are many ways to encourage and enable curiosity within our teams. By embedding curiosity into the workplace culture, we can create an environment where information is freely shared, knowledge is continually generated, and innovation is actually achievable.

 

Further reading

Curiosity in old age: a possible key to achieving adaptive aging,  Yagi, A. and Murayama, K. (2018)

Leveraging do Bonos Six Thinking Hats, BA Times (2011)

 

Active Listening

What is active listening? (it’s not just nodding)

Most people know the phrase ‘active listening’, but if you ask them to define it, we get a range of vague descriptions, often involving adopting a concerned expression and nodding occasionally. What is the ‘active’ element that makes us a participant rather than a passive recipient?

What is Active Listening?

 It means listening for total meaning, providing unwavering attention and being a positive participant in the interaction.

“Active listening is more than ‘hearing’ someone’s words. It means fully attuning to the feelings and views of the speaker.

(Nelson-Jones, 2014)

“Active listening is a technique that aids effective communication and is a skill that business analysts need to possess.”

(Paul and Lovelock, 2019)

Active Listening Behaviours

OK – so there might be some nodding, but that is not the extent of genuine active listening behaviours! We need to be conscious of our facial expressions. For example, do we need to be encouraging and get people to provide more details? Do we need to be appreciative that they have made time to speak with us? Think about the emotional response the speaker needs or expects from you, and it will be much easier to find the matching facial expression. Note this may change during the conversation, so it is important to stay attuned to the speakers’ changes in tone and expression as well as the words they use. Slanting our heads is often interpreted as a sign of empathy and willingness to learn more. Online engagement means we have more opportunities to notice and learn from our own facial expressions and the impact they have on the speaker.

 

The difference between speaking to someone you feel is genuinely listening to you and someone who is multi-tasking is immense. The absolutely critical element of active listening is to give the other person your full attention. There is sometimes a decision to make about note-taking and active listening. Some people feel that if they are giving their time and knowledge, the other person should be making notes. This is particularly relevant for stakeholder interviews, for example. There may be other ways to take notes without splitting your attention from the speaker, such as having someone else take notes, using transcription, noting down keywords only or making notes after the session. Multi-tasking while listening can prevent us from making the appropriate level of eye contact. Continuous eye contact can be difficult to maintain and disconcerting, but a complete lack of eye contact can leave the speaker feeling unheard.

 

The role of the active listener is not to be silent, and we have a number of ways we can contribute to a better interaction through the use of these active listening behaviours:

  • Question – ask thoughtful, open questions
  • Probe – ask follow-up questions designed to elicit more detail
  • Clarify – check your understanding, clarify particular aspects
  • Paraphrase – play the information back using your own words
  • Summarise – relate the highlights of what you have heard, and ask if you have missed anything key.

Listening Modes

There are multiple listening modes that we can adopt, and many of us have a default mode.

  • Task-orientated listener – key focus on getting to actions and focusing on the most ‘important’ information.
  • Analytical listener – trying to understand and simultaneously analyse the content of the conversation.
  • Relational listener – focused on building connection and understanding emotions.
  • Critical listener – focused on making judgments about the content of the conversation and the speaker.

Being aware of our natural style or mode can help us be more aware of our behaviours and the impact on others.

Remember – those who are curious and analytical can often spot many ways something can be improved. If we voice all of these, it can come across as overly negative!

Avoiding Judgment

 If we are busy with our own thought processes trying to evaluate what the other person is saying, we are not giving our full attention to listening and understanding. Judgment can take up a great deal of brain space and mental energy. In many conversations, it is better to suspend or defer judgment to keep us in the moment so we can reflect and evaluate what the person has said later.

 Avoid Deflection Back to Self

 To really understand and listen to the other person, we want to keep the focus on them and what they are saying. This means avoiding bringing the focus of the interaction back to our own experiences and knowledge. It is very tempting to tell a ‘related story’ or share a ‘similar experience’ when what the other person has said brings it to mind. We have to be restrained and decide if it is in the best interest of the interaction to switch the focus to ourselves or keep the focus on them and draw out more details of their experiences.

Benefits of Active Listening

 Giving someone the time and space to really listen to them in our busy world is a rarity. Investing this time and effort can help to build trust and rapport, increase our depth of understanding, and increase the amount of information we will actually retain from the interaction. This can help to save time, as it avoids assumptions being made and revisiting the same areas.

Conclusion

Active listening can be extremely valuable for business analysts in a variety of situations. Consciously deciding to keep the focus on the other person helps to build a sense of connection and deepens our understanding of the information given to us. Active listening is a key skill for high-performing teams and individuals and is an area we can all improve by investing a little more effort.

Further reading

The Myth of Multi-Tasking, C Lovelock, (BA Times, 2024)

Delivering Business Analysis: The BA Service Handbook, Paul and Lovelock (BCS, 2019)

What is Active Listening A Gallo (HBR, 2024)

 

 

BATimes_Oct03_2024

The Hidden Cost of Side Quests: How BAs Can Protect Their Time

Back in the late 2000s, I started a new job, having worked for my previous employer for a long time. It was a really weird feeling—I can still remember entering the building, being assigned a desk, logging in and there being virtually no email for me.

I was already assigned to a project, and I was introduced to a key stakeholder. It was a fairly small project, albeit with some hidden complexity. Working with the project team, we got it done, and the analysis work was done pretty quickly.

Partly, this was because I was new and keen to make an impression. But, on reflection, another reason I was able to get the analysis done quickly was (as a new team member) I didn’t yet have the overhead of a whole number of ‘side quests’ that tend to accumulate over time.

 

What Type of “Side Quests” might a BA be drawn into?

I don’t know about you, but I’ve been drawn into a whole range of other activities. Often there are good reasons for this, but sometimes I can’t help but think that what I’m really doing is filling a gap in the organizational structure.

Examples might include:

  • Providing production support to production systems: (“You wrote the requirements, you know how it works…”). This might be genuinely useful and necessary in a transition period, but I suspect a few people reading this are still supporting some elements of a system they worked with years ago, and that sounds like gap filling!
  • Quality assurance: BAs absolutely can feed into testing. Yet, as much as I’ll give some (very limited) testing a go, I know that I am not a professional QA engineer, I have a different skill set. In fact, I love working with QA colleagues, as they will often help me sharpen my game by reminding me that quality assurance is about a lot more than testing, and they can provide useful peer reviews on requirements artifacts too.
  • Messy workarounds: If there’s a ‘temporary’ workaround, it might make sense for a BA to help operationalize it. Yet, issues occur when the organization decides that workaround isn’t ‘temporary’, and three years later somehow you’re still lumbered with the task of deciphering operational data via an unmanageable spreadsheet with macros…and everyone is shouting that they need it ‘today!’

 

In all of these cases, it can be valid for BAs to be involved for a limited amount of time. Context is everything. Yet, being drawn in for too long, or finding that it becomes a permanent part of your repertoire could be damaging.

Put differently: If a BA ends up providing perpetual informal production support for every system or process they are involved with changing or deploying, then they have less capacity to do business analysis after every project. There will come a time when their role is more support than analysis.

 

Advertisement

 

Saying “No” by giving options

The challenge, though, is that these ‘side quests’ often are important to someone, and might be crucial to the organization, which makes them hard to say no to. A key question here is around prioritization: are they as important as the project work. Or put differently: should the project work be delayed, to create space for the side quest.  If a project is the priority, then this might mean saying no to a side quest or two… but that can be hard.

So what approaches are there for saying “no” constructively?

 

I live in the UK, and if you’re not familiar with our culture, it’s somewhat indirect.  In fact, when I say “somewhat indirect”, what I actually mean is “completely indirect to the point I literally don’t know how non-native English speakers decode what we are trying to say most of the time”.  So, as you can imagine, a curt “no” can be tricky. What follows is written through the lens of a UK citizen, things might be different where you are.

With regards to saying “no”, I once had a fantastic manager who gave the following advice which has always stuck with me:

“Try not to say ‘no’ outright, unless you really need to. Instead, find a way of saying ‘yes’ by giving implications and options”

 

This might sound like:

“Yes, I could absolutely take a look at that production support issue. That’ll likely take around half a day, which will delay a core project deliverable. Shall we go and speak to the project manager to ensure that’s OK? If it isn’t, perhaps I could ping you over some documents that might help, and I’ll be on hand for any quick queries?”

“Yes, I can certainly continue to help with the manual workaround. However, I’m likely to be a bit of a bottleneck, due to project work, which is always going to take priority as it’s my core role. I wouldn’t want to delay you. How about I train one of your team? I could also make a quick video of the process, so they have something to refer to. Then you’re in complete control”

 

Sometimes It’s a Hard “no”

While the approach described above will work in many situations, there will be times when a hard ‘no’ is necessary. In those cases, in my experience, it’s best to be direct (however uncomfortable that is). I have been amazed that often when I say no, and give the reasons, people are actually extremely understanding. Even if they aren’t, it’ll be some short-term discomfort while the issue is discussed, instead of long term pain (if you’ve ever taken on too much work, you’ll know how painful that feeling of overwhelm can be!).

Ultimately, whether to say ‘no’, and how to say it varies depending on context. You have to do what’s right for you. I hope this blog has given you some food for thought!

BATimes_Sep18_2024

Transition Requirements – The Key To Adoption

The key to adoption. Don’t forget the obvious.

 

As a Business Analyst at heart, requirements play a part in my everyday life. Much to the annoyance of those closest to me, I’m wired to think of everyday activities in terms of requirements 😊

However, transition requirements are sometimes elusive, even to those of us with a couple of decades of experience. But – they are the key to adoption!

A quick little story time…

When my daughter went to her first school, we spent weeks preparing; we got her a backpack and matching lunchbox, new school clothes, new shoes, and a sleeping mat, and we even planned a lunch and snack menu! I even read the school handbook, multiple times! At 3.5 years old; she’s spent her entire life with just the three of us. She never went to a daycare, so this was her first school-like experience, and we were ALL excited! Nevertheless, in all that preparation, we neglected a key piece of information – WE would not stay with her at school.

As we unbuckled her, with excitement beaming from her eyes, she stated “Mommy, we are all going to have so much fun today!”. At that moment, I knew I missed a key piece of information that was going to completely change how the rest of the day went. Oops! And it did…she was distraught! Then I was too!

In all my functional preparation, I neglected to operationalize her new school experience. I completely missed considering my key stakeholder’s transition!

Even with over 18 years of requirements management experience, I forgot the obvious. This is your call to action – don’t forget the obvious!

 

What are transition requirements?

Transition Requirements (or Transitional Requirements) are like NFRs (Non-Functional Requirements), in that they are often missed in the design and development processes.

As the name suggests, these are the requirements that will ensure a successful transition from the current to the future state.

 

Why are they important?

Without a plan to transition from the current state to the future state, adoption will surely slow if not stop entirely. You as the Product/Project Manager may be excited about this change, but excitement alone doesn’t cross the finish line!

A transition (or migration) will likely impact other business units and processes. For example, a customer may need to upgrade a current licensing agreement to transition to a new solution. Do you wait to transition them? What is the impact of waiting? Are there legal implications? Is additional training required?

Additionally, on the softer side of a transition, is understanding the change curve. Especially when it comes to process or culture-related changes, transitions can be very difficult. People are creatures of comfort – i.e., creatures of familiarity. And change is unfamiliar….it is uncomfortable. Having a good understanding of change management can help ensure there aren’t gaps in the transition plan and requirements.

 

How does that tie into overall value?

Value is realized when the solution is adopted. A single transition requirement alone does not generally provide quantitative value. However, the overall plan and requirements’ existence provides a qualitative value by ensuring a successful transition can happen – leading to better adoption and ultimate solution value realization.

 

Advertisement

 

Technique for gathering Transition Requirements?

Transition requirements should only be defined once the final solution is known. It doesn’t need to be fully implemented, but it must be known.

Unlike functional (or stakeholder) requirements, these are typically not willingly disclosed or stated by the business or users. Because of this, my favorite technique to start with is questions; to elicit information to then derive the transition requirements from that information. It is important to have a listing of questions to start with, but also being present in the discussion will help uncover additional questions to minimize gaps and assumptions.

Some sample questions and follow-up questions are noted below:

  • Are there any user skill gaps that need to be filled to operationalize the new solution?
    • Is this a training we can provide, or do we need outside help?
    • What is the cost of this effort?
    • What type of internal messaging is required?
  • Is there any data that needs to be migrated from the current to the future system?
    • If so, how can that be done?
    • Migrate all data? Only some data?
    • Does data need to be transformed?
    • How long to prep? Migrate? Validate?
    • Are there any regulatory requirements for transmitting the data?
    • What are the ideal timelines?
  • What is required to retire the current solution?
    • Can it just be turned off/eliminated?
      • Do user accounts need to be deactivated?
    • Is there a cost associated with terminating (or ending early)?
    • Will data need to be deleted? Can it (contractually) be deleted?
  • What processes need to change to implement the new solution?
    • How/when will this process change happen?
    • How/when will it be communicated?

 

Additionally, think about the differences between the two solutions/states. Then identify some questions, even if they seem silly, to help elicit information. Listed below are a couple of sample projects with a few starting questions:

 

Set your launch up for success by not forgetting the obvious – Transition Requirements.