Skip to main content

Upskilling Your BA Team

Written by Virginie Terry on . Posted in Articles.

Upskilling Your BA Team

AUTHOR: Virginie Terry

1. This is the way we’ve always done it…

One of the most common barriers to adopting new ways of working is a belief from the long-standing BAs that their delivery or operating models are different from the norm, or that their business stakeholders are unusual, and therefore different BA skills or standards apply. This is particularly true with BAs who have learned their skills on the job: internally and without any formal training. Typically, they will have moved from a different part of the business, and they know the ins and outs of specific departments, including the quirks of their systems. This can manifest itself as skills gaps (e. g. made up notation to model business processes); undertaking tasks which should legitimately sit in other areas (e. g. writing test scripts); or not being effective in their role because they don’t challenge their business stakeholders to work differently when defining to be processes.

These individuals need to understand internal expectations as well as the BA industry standards, and in particular the skills that as a manager you are looking for in new joiners. They need to appreciate that refusing to upskill could put them at a disadvantage in terms of the projects they work on or future career opportunities.

2. I’m looking to retire in a few years, why should I bother?

Not everyone thrives on learning something new and getting out of their comfort zone when they are counting the days until they retire.

As a manager, it’s only worth pushing if there is still time for these individuals to apply new skills before they retire. These BAs need to understand how this will improve or expedite some of the great work that they already do. For example, if you’re looking to get a BA trained on use case diagrams, you can easily demonstrate how much more engaging they are to project stakeholders than Jira tickets or an Excel spreadsheet when it comes to reviewing the outputs of a discovery workshop.

3. My project can’t afford to release me for any training, sorry!

A misconception which comes up time and again is the belief that project teams can’t afford to release their BA(s). The truth is that there is rarely a time in any project when a project or programme manager feels that they can afford not to have their BA(s) around, regardless of the stage of the delivery.

A tough one to win if project teams don’t have enough time to plan it. Give the BAs and project teams plenty of notice – ideally several months, so that the BAs can block the time in their calendars, and the project teams can plan for it. It’s important to show some flexibility and collaborate with programme and project managers, for example by staggering the training dates if multiple BAs work together on the same programme or project, rather than taking them all away on the same day(s)

4. I am too old to learn something new

Not quite the same as the BA who’s retiring soon, in this case we’re looking at BAs who may doubt their ability to learn and apply new techniques, or even have some anxiety about sitting exams because they are out of practice. You may also have a BA who’s just not very academic and really struggles with formal learning and assessment / exam situations.

Getting back into a classroom (albeit a virtual classroom) can be daunting. It is the manager’s responsibility to provide support and minimise stressors where possible. You should be able to negotiate revision sessions with your training provider in the run up to any assessment, and if not there is always internal support available from BAs who have already completed the training. Reminders about exam techniques and dealing with exam nerves are useful – as well as being honest with your team and sharing your own story. It is very powerful for team members to be aware that their manager may have gone through the same thing, and how they have overcome their own demons.

5. Celebrating success in the right way

It is necessary to find the right balance between celebrating the team’s successes, which is entirely legitimate and appropriate, and not inadvertently making people feel any pressure or “less than” if they haven’t taken the exams yet or they have failed.

Ultimately, as with so many situations, the key to success is for BAs to realise what’s in it for them. And in the vast majority of cases, once get a few people over the line – once they are, they become your strongest advocates and allies for change.

The Incredible Expanding Requirement

Written by Karl Wiegers on . Posted in Articles.

The Incredible Expanding Requirement

A simple requirement statement might conceal much detail that eventually must be discovered and addressed.

Image by kjpargeter on Freepik

Some requirements are like icebergs: The portion that you see initially is only a small fraction of the whole thing. Whether it’s represented as text—such as a single functional or nonfunctional requirement statement, a feature summary description, or a user story—or visually in the form of an analysis model, there could be far more to it than first appears. Requirements analysis involves digging below the surface of a presented requirement to understand its full scope, complexity, and implications.

Let’s consider a simple, common nonfunctional requirement: “Only authorized users may access system services.” That security requirement could have originated from a company policy, government regulation, or other business rule. Can you just hand that requirement to a developer, or maybe write it in the form of a user story and add it to the product backlog? I don’t think so. Peeling away the layers shows that that one requirement statement can expand enormously, raising many questions and spawning many child requirements along the way.

This raises the question of how much detail to document for an unrefined requirement versus leaving it in the hands of the developer to process as they see fit. In other words, who do you want to make all the decisions associated with a complex requirement, and when? Considering that question will help you manage the transition from requirements to design.

If you want an initial high-level requirement implemented in a specific way, the business analyst should elaborate it into the appropriate level of detail and precision. That elaboration could impose design constraints on the developer, albeit for good and thoughtful reasons. On the other hand, if you’re okay with the developer having the final say on the functionality and user experience details (preferably with feedback from others on design documentation, prototypes, or screen sketches), then just pass the higher-level requirement along for implementation.

Looking Below the Surface

Consider some of the questions you’d have to answer if you were the developer asked to implement our one-sentence security requirement. It’s unlikely that you’d have all the answers yourself. As you study the requirement, you’d have to make up those answers, research policy standards, or consult with others to agree on how to resolve each issue. That’s what business analysis is all about. Let’s see how quickly an exploration of this single requirement statement expands into many detailed requirements.

First, we’ll need a clear definition of exactly what an “authorized user” is and just what system services cannot be accessed unless a user is authorized. Do different parts of the system require different privilege levels or access credentials?

How should each user be uniquely identified? With a login name, an email address, using a third-party account (like Google, Apple, Facebook, or X), or something else? Will the user ID be assigned by a sys admin or user-selected? What are the rules for the user ID: minimum and maximum length, allowed characters, and case sensitivity? What happens if the user selects a user ID that’s already in use?

Next, what is the primary user authentication mechanism? We have numerous choices, including password, passkey, PIN, and biometrics of various kinds. Let’s just think about the venerable password for now. Here are some questions that come to mind regarding passwords:

  • What are the rules for the password: minimum and maximum number of characters; allowed, prohibited, and required; characters, case sensitivity; pattern restrictions (such as no more than two instances of the same character in sequence); required patterns (such as at least one each of upper- and lowercase letters, numbers, and symbols)?
  • Must the user re-enter the same password in a separate field during creation to verify it? If so, what happens if the two entered passwords don’t match?
  • Can the user toggle the visibility of the entered password on and off, either during creation or during logins?
  • How is the password masked in the entry field? With asterisks or dots? One symbol per entered character or a random number of symbols to conceal the password length from an onlooker?
  • What feedback will the system provide if a login attempt fails?
  • Is the user blocked after too many unsuccessful login attempts? If so, how many tries do they get?
  • If the user’s account is locked after too many failed login attempts, how long does the account remain locked? How can the user unlock it?
  • What happens if the user forgets their login ID or password? What recovery method is used? I can’t get into my original YouTube account because I’ve long since forgotten the password, and the phone number on the account cannot receive texts. Google offers me no other identity verification options.
  • Must the user change their password periodically? If so, how often? Are there restrictions on what the new password can be, such as not reusing any of the previous N passwords?
  • Can the user define a personal identification number (PIN) as a shortcut for the password, as on a Windows PC? If so, what are the allowable characters and the minimum and maximum length of the PIN?

These are some of the issues associated with specifying a security requirement for just a simple password mechanism. You can see how the answers to those questions lead to more and more functional requirements to satisfy the nonfunctional security requirement. But the expansion can get much worse.

The Many Modes of MFA

If your project’s decision makers want better security than a password provides, you’ll explore multifactor authentication (MFA) options. You’ll need to choose from numerous options for both MFA techniques and their implementation details. Start by deciding what types of MFA the system should enable to provide the desired security level. Options include:

  • Sending a one-time code that the user must enter to verify their identity
  • Sending an email containing a one-time login link
  • Biometrics, such as fingerprint, facial recognition, voice ID, and iris or retinal scan
  • A physical security token
  • Using an authenticator app, perhaps on a second device

Here are a few more general questions:

  • How many of these MFA options should you make available to the user?
  • If more than one, can the user select their default preference to use initially for each login attempt? Can they change that default?
  • How will the user enable and disable MFA on their account?
  • If for some reason the user can’t employ their initial method (such as not having access to the device with the authenticator app), can they select another method for that session?
  • Will there be some other backup action, such as contacting customer support, in case none of these MFA methods work for the user?

Let’s take a closer look at just the technique of sending the user a one-time code. Contemplate these questions:

  • What options will you provide for sending the code: text message, e-mail, or phone call? Will the user have more than one option available?
  • If text message or phone call, can the user save more than one phone number in their application’s profile? Can they specify the default and select the number to use for each session? Can they change or delete a saved number or change which is the default?
  • How many characters are in the one-time code and what are the valid characters?
  • How long is the one-time code good for? If it’s limited, should the application display a countdown timer? Can the user request to have the code re-sent? If so, is the same code sent again or a new code? What happens if the user enters the one-time code after the time-out period?
  • What happens if this secondary authentication attempt fails? Is the entire login session terminated, or can they try the MFA again? How many tries does the user get at the MFA action? If it’s limited, do attempts using different methods all count toward the limit?
  • Can the user opt to have their authenticated device and login recognized for some period of time so they won’t have to re-authenticate for each session? If so, how long is that period? Where should that information be stored? I use some apps that recognize my device even if I restart my browser, while others lose my remember-me setting whenever I clear the browser cookies.

I’m sure there’s even more to it than this, but you get the picture. Drilling into the particulars of an initial, concise requirement statement often opens a sizeable can of worms. The answers to the resultant questions lead to an explosion into more and more requirements. This fact is true whether the exploration is performed by a business analyst during requirements specification or by a developer who’s been tasked to write the user authentication code. The original requirement isn’t actually growing, so this process isn’t changing the project’s scope. It’s merely revealing the true scope.

The good news is that if you can craft a well-thought-out set of requirements for a complex function like user authentication, you can likely reuse them in multiple applications. At the least, they should provide an excellent starting point.

Beware the Blast

I’ve used a common nonfunctional requirement to illustrate how much complexity can hide beneath the tip of that requirement iceberg. The same can apply to functional requirements and product features, of course.

One of my consulting clients held a large workshop to gather requirement ideas for a new flagship product. One of the requirements stated, “The product shall respond to editing directives entered by voice.” This was at a time before speech recognition capabilities were built into all of our devices. That one simple requirement statement looked to be no bigger or smaller than all of the many others in the set. However, you can guess how large the requirements explosion would be when someone looked into everything involved with the details of that speech recognition feature.

Understanding the true scope of a requirement so your team can estimate and plan for its design and implementation often requires a fair amount of exploration. During that exploration, you can set the priorities of the various child requirements, perhaps deferring some functionality to later development iterations and maybe never implementing others. That thinking process is less painful than encountering one additional, unexpected need after another and continually revising the product.

======

Karl Wiegers is the author of Software Requirements Essentials (with Candase Hokanson), Software Requirements (with Joy Beatty), Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and numerous other books.

 

Workshop to crack every nut

Written by Christina Lovelock on . Posted in Articles.

Are you using a workshop to crack every nut?

As the saying goes – if all you have is a hammer, everything looks like a nail. Are business analysts falling into this trap by using a workshop for every situation?

Benefits of workshops

Getting all of the right people in the right place at the same time can move projects and initiatives forward at an accelerated rate. We have different perspectives represented, we can fact-check and enable constructive challenge. We can build on great ideas and identify clear problems with others. Workshops that are well facilitated can be motivating, build trust in the product/ project and deepen working relationships. We can co-create outputs using collaborative approaches and get real buy-in from all attendees. So, it’s easy to see why workshops are an attractive choice.

But if we ONLY use workshops…

They become stale, people stop coming, they are no longer motivating, and we can end up wasting time. Some people do not make their best contribution ‘on the spot’ or in a large group, so we also need to consider whose perspective and input we might be missing by relying only on this approach. Some teams cannot release people for long periods, and may become systemically unrepresented in discussions and decisions. We end up with the group of people who have the time or inclination to attend workshops, not the group we actually need.

Bias towards workshops

Workshops can too easily become the default action. From the perspective of the stakeholder, it can be very difficult to suggest alternatives to a proposed workshop. As an invited workshop attendee, it can feel that if you are not in the room, you will lose the ability to influence. This creates a situation where no one can propose a suitable alternative to workshops, and people only attend due to FOMO!

High visibility

Workshops are very visible. They often exist as a big chunk of time booked in lots of people’s diaries, often weeks or months in advance. During the workshop, business analysis becomes very visible, in the central role of the facilitator and the choice of analytical and collaborative techniques.

Perhaps we have a bias towards workshops precisely because they are so visible. It’s a way to remind stakeholders who we are and why we are useful. The outputs are often very visual, flip charts, post-it notes and colourful virtual whiteboards. Many days or weeks of effort of business analysis sometimes has very little to ‘show’ for it… but workshops scream: here we are! We did this! We have agreed stuff!

The time cost of workshops

It is easy to convince ourselves that workshops are the most efficient way of engaging with a group. And often workshops do ‘save time’ in the long run, but let’s look in detail at the question “How long does a workshop take?”

Let’s say we have allocated 3 hours for a workshop (W = 3).

A good rule for facilitators is that the workshop will take 5 times the length of the workshop to prepare PER facilitator (Prep = 5W x F). This is everything from identifying attendees, sending invites, logistics, planning purpose, designing exercises, creating slides etc.

And actions after the workshop will require 2 times the length of the workshop, again per facilitator (After = 2W x F). This will range from tiding a room, to creating outputs and doing follow up actions.

It might seem like all attendees have to do is show up, but they may have to do some thinking/ reading/ speaking to others. They may also have to share information about the workshop, or carry out follow-up actions. Their multiplying factor is 1.5 times the length of the workshop per attendee.

(If travel time is also required, this is likely an underestimate).

So we have

Prep for facilitators: 5W x F

Plus the actual workshop time for facilitators: W x F

Plus the workshop time for attendees: 1.5W x A

Plus the follow up after for facilitators: 2W x F

Total = W x(8F +1.5A)

Where W is workshop length, F is number of facilitators and A is number of attendees.

So a 3 hour workshop with 2 facilitators, and 20 attendees requires a total of

3 hrs x (8 x 2   +   1.5 x 20)  = 90 hrs

A workshop may still be the best way to move forward, but at least we are not kidding ourselves that “it’s only 3 hrs”!

Types of workshop

It’s useful to consider there are 3 main types of workshop.

Strategic – vision, alignment, big picture, new ideas, changing direction, transformation

Operational – how does this work? What do you need? efficiency, consistency, continuous improvement

Educational – a learning opportunity. This could be two-way, with both participants and facilitators learning something, or primarily one-way, it is mostly a learning opportunity for participants.

The type of workshop will significantly impact the time needed AND understanding the type will help to answer whether a workshop is the right approach to the situation at hand.

Other approaches BAs should be considering

Before we start arranging the inevitable workshop, we need to really consider if this is the best approach, and what else could be achieved given the same amount of time and effort.

We should consider:

  • One to one interviews
  • Small group discussions
  • Attending existing meetings
  • Surveys
  • Pro-Formas
  • Observation
  • Work shadowing
  • Focus groups
  • Prototyping
  • Document analysis
  • Competitor analysis

We may want to use one or more of these methods to supplement workshops, and perhaps doing so will allow us to reduce the duration of the workshop or the number of attendees.

Conclusion

Workshops can be great – but they are not the only tool in your BA toolkit. If we over-rely on workshops, people can start to disengage and loose trust. Workshops take a lot of time and can lead to the idea that the only way to get anything done or agreed is via a workshop. Don’t organise a workshop as the default option. Consider all possible approaches and select the most appropriate for the situation.

 

Further reading

Planning workshops using the 7Ps technique, BA Times (2021)

Business Analysis Techniques: 123 essential tools for success Cadle, Paul et al (2021)

How Business Analysts Can Drive Cybersecurity Strategies

Written by Rianat Abbas on . Posted in Articles.

Author:
Rianat Abbas – Product Analyst

Are you wondering how the business analyst profession and cybersecurity relate to one another? What is BA’s role in cybersecurity? The role of the Business Analyst (BA) has expanded in recent years to encompass responsibilities traditionally associated with cybersecurity professionals. BAs play a critical role in supporting cybersecurity efforts in organizations by acting as liaisons between security teams, IT, business units, and project management. They contribute to the development and implementation of policies, tools, and procedures specifically designed to mitigate cybercrime risks.

With the growing rate of cybercrime threats to businesses, the demand for skilled BAs with cybersecurity expertise has risen significantly. This evolution shows the importance of BAs as integral contributors to security strategies, bridging both technical and business perspectives as well as safeguarding operations.

In today’s technology system, the frequency and sophistication of cyber threats are increasing rapidly. In 2021, a ransomware attack occurred every 11 seconds, which is anticipated to increase to every two seconds by 2031. BAs contribute a distinct skill set that bridges the gap between technical teams and business stakeholders, ensuring that cybersecurity measures are consistent with organizational goals and regulatory requirements.

The Basic Cybersecurity Concepts

Three security basic concepts guide the information security domain, which every Business Analyst should know:

Confidentiality: Maintain access control and disclosure limits on information. Ensure that no one will violate the norms of personal privacy and proprietary information.

Integrity: prevent improper (unauthorized) information modification or deletion. This section includes measures to ensure non-repudiation and information veracity.

Availability: The information must be accessible and used at all times and with consistent reliability. Certainly, it must be true for those with the right to access.

When these principles are broken, it is characterized as the level of damage that they can have on corporate information, assets, or individuals. Generally, the influence is described as:

Low: produce a modest harmful effect.

Moderate: cause a serious or critical unfavorable effect.

High: cause a significant or catastrophic bad consequence.

Cybersecurity is business-critical.

Cybersecurity is a key component of any business, and as a Business Analyst (BA), you must understand and contribute to managing cybersecurity risks. A Business Analyst may not be directly responsible for adopting cybersecurity measures but should be aware of potential threats and contribute to maintaining the organization’s security posture. Cybersecurity helps to protect the critical components of the projects you work on in organizations, including data, systems, and sensitive information. For far too long, it has been considered primarily as a technical obligation limited to the IT and security departments. In reality, cross-functional collaboration across the enterprise is necessary, with the business analysis community playing an important role.

Companies that demonstrate a strong commitment to protecting customer data and operating in a secure manner are more likely to obtain customer trust and market share. Business analysts can help change the notion of cybersecurity as a technological afterthought to a business enabler.

The following are important cybersecurity rules for business analysts.

Fundamental Concepts of Cybersecurity: As a Business Analyst, to perform effectively, you must have a comprehensive understanding of fundamental cybersecurity principles, including prevalent threats, vulnerabilities, and risk mitigation measures. Understanding this fundamental enables Business Analysts to recognize challenges and coordinate the deployment of effective security solutions.

Risk Identification and Mitigation: In identifying potential cybersecurity vulnerabilities early in a project’s lifecycle, Business Analysts are essential in assessing risks in system architectures and processes; they assist enterprises in circumventing expensive security issues. Motivating stakeholders to contemplate security consequences from the outset guarantees that these issues are addressed preemptively.

Documenting Security requirements: In order to have effective cybersecurity initiatives, a detailed comprehension of cybersecurity needs is vital. Business Analysts work with teams to collect business and technical requirements, converting them into implementable security specifications. Collaborating with Security architects, they strive to implement suitable safeguards, prioritizing “security by design” as a fundamental premise.

Enhancing Security Protocols: Cybersecurity encompasses not only technology but also carefully organized processes. One of the key roles of a business analyst is designing and implementing process improvement, which can be integrated into security best practices. Business Analysts lead and support in evaluating current business operations, pinpointing areas to enhance security while ensuring regulatory compliance. By optimizing these procedures, they can establish an environment in which security and efficiency will coexist.

Effective Communication and Awareness Training: For security initiatives to succeed, all stakeholders must comprehend their obligations. Business Analysts connect technical and non-technical teams, facilitating effective communication about policies and best practices. They contribute to the creation of training programs that enhance employee understanding of cyber threats, promoting a culture of accountability.

Ensuring Regulatory Compliance: Organizations must remain cautious to evade penalties or reputational damage due to escalating regulatory expectations. Business Analysts conduct gap studies to pinpoint noncompliance areas, recommend repair solutions, and assist audit processes by supplying pertinent paperwork and proof.

Security Incidents Response: In the event of a cybersecurity incident, Business Analysts facilitate the organization’s response coordination. They collaborate with technical teams to examine the issue, ascertain the main cause, and execute preventative actions. Informing stakeholders guarantees a transparent and cooperative settlement process.

Incorporating Security Throughout the Development Process: Secure Software Development Lifecycle (SDLC) in recent times has become widely adopted by most companies, and Business Analysts are important in integrating security at every phase of development. This method facilitates the early identification of vulnerabilities, which diminishes the probability of subsequent breaches and safeguards the integrity of the final product.

Conclusion

Cybersecurity is more than just ethical hackers coping with malicious ransomware attacks. BA professionals are also working on comparable concerns, using their analytical talents to foresee potential dangers. They inform stakeholders and other relevant people about potential hazards. The demand for Business Analysts in cyber security has grown due to a rise in cybercrime and the critical requirement to forecast any danger. BA is making significant contributions to cyber security through the use of artificial intelligence and advanced analytical techniques.

Who Moved My Cheese and Stakeholders?

Written by Amanda Zurn on . Posted in Articles.

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?