Tag: Stakeholder

Transition Requirements – The Key To Adoption

Written by Tiffany Wiley on September 18, 2024. Posted in Articles.

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.

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.

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

Written by Lee Templeton on August 21, 2024. Posted in Articles.

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

Rapport Building

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

Empathy

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

Enthusiasm

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

Active listening

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

Creativity

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

Adaptability

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

Communication

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

Patience

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

Improvisation

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

Conflict Resolution

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

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

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

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

Decoding Stakeholder Signals: Beyond Formal Feedback in Business Analysis

Written by Adrian Reed on July 31, 2024. Posted in Articles.

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

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

Feedback as a Signal

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

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

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

Example: The Absent Stakeholder

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

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

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

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

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

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

Interpretation Is Hard

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

Priming: A Powerful Tool for Business Analysts

Written by Olam Osah on June 26, 2024. Posted in Articles.

“Big doors swing on little hinges.” – W. Clement Stone

Imagine walking into a store and hearing your favorite song playing in the background. Instinctively, you feel more at ease, more inclined to browse, and perhaps even to buy something. This subtle influence on your behavior is no accident—it is an example of priming at work. Now, picture leveraging this same psychological phenomenon to enhance the effectiveness of business analysis. Welcome to the world of priming, where a well-placed word or image can shape perceptions, drive engagement, and ultimately lead to more successful projects.

Historical Context of Priming

Priming, a concept rooted in psychology, began to gain traction in the 1970s. Researchers like David Meyer and Roger Schvaneveldt conducted seminal experiments demonstrating how exposure to certain stimuli could influence subsequent responses. For instance, people could respond faster to related words (like “doctor” and “nurse”) than to unrelated ones (like “doctor” and “bread”). This discovery highlighted the subconscious ways in which our minds process information, laying the groundwork for priming’s application across various fields, including business analysis. The foundational studies revealed that our brains are wired to create associative networks, meaning that exposure to a particular concept can automatically activate related concepts. This insight has been pivotal in understanding how to strategically use priming in business contexts to shape decision-making, improve stakeholder engagement, and enhance communication strategies.

Real-Life Examples of Priming

Priming has been effectively used in many real-world scenarios. For instance, in retail, stores often play specific types of music to influence customer behavior. A study by North, Hargreaves, and McKendrick (1999) found that playing French music in a wine store increased the sales of French wines, while playing German music boosted the sales of German wines. This subtle priming technique tapped into customers’ associations between the music and the product.

In another example, Priming is a powerful tool in political campaigns, frequently used to shape public opinion by consistently emphasizing particular themes or issues. Barack Obama’s “Yes We Can” and “Change We Can Believe In” slogans serve as prime examples of this strategy in action. These slogans were not just catchy phrases; they were meticulously crafted to prime voters to embrace a sense of collective empowerment and the possibility of positive change.

During Obama’s campaign, the repetitive use of these slogans created a cognitive framework that associated his candidacy with optimism, hope, and unity. Every time voters heard “Yes We Can,” they were subtly reminded of the potential for change and progress, fostering a sense of personal involvement and collective action. This emotional resonance was further reinforced through speeches, advertisements, and campaign events that consistently highlighted these themes.

The effectiveness of this priming was evident in the overwhelming support Obama received, particularly from younger voters and minority groups who felt directly addressed and included in his vision. The campaign’s ability to prime these voters to associate Obama’s candidacy with positive change and empowerment played a crucial role in his electoral success.

Personal Anecdote: Priming in Action

In my experience as a business analyst, I have found priming to be an invaluable tool in guiding stakeholders towards beneficial decisions. One notable instance was during a project aimed at selecting a software solution for case and document management.

Having previously worked with a highly effective software that streamlined operations and significantly reduced processing times, I was confident it would be the ideal choice for our current project. However, I knew that simply presenting this software as the best option might not be enough to gain stakeholder buy-in.

To prime the stakeholders, I began by sharing a series of success stories and case studies from other organizations that had successfully implemented this software. In pre-meeting materials, I included testimonials from satisfied users and highlighted measurable improvements in efficiency and accuracy. During our discussions, I subtly referenced these examples, framing our needs in a way that aligned with the strengths of the software.

As a result, when it came time to evaluate potential solutions, the stakeholders were already positively inclined towards the software I had in mind. The decision-making process was smoother, and the eventual adoption of the software led to significant improvements in our case and document management processes.

Applications of Priming in Business Analysis

Having seen how priming can effectively influence stakeholders in a real-world project, we can now explore how this technique can be systematically applied in the realm of business analysis.

The application of priming in business analysis provides a strategic advantage in enhancing stakeholder engagement, improving requirements elicitation, facilitating change management, and ensuring clear communication. By understanding how subtle cues can influence perceptions and decisions, business analysts can effectively guide project outcomes. However, the true power of priming lies in its implementation. To harness this potential, it is essential to employ specific techniques that ensure priming is both subtle and impactful, driving the desired results while maintaining ethical standards.

Implementing Priming Techniques

Now that we understand the applications of priming in business analysis, let us delve into practical strategies for effectively implementing these priming techniques in your projects. To effectively implement priming techniques, business analysts should consider the following steps:

Conclusion

Priming is a subtle yet powerful tool that business analysts can use to enhance their effectiveness in various aspects of their role. By understanding and strategically applying priming techniques, analysts can improve stakeholder engagement, facilitate better requirements elicitation, support change management, and enhance communication. As with any tool, the key to successful priming lies in its thoughtful and ethical application, ensuring that it serves the best interests of the project and its stakeholders. Drawing on historical insights, real-world examples, and personal experiences, business analysts can harness the power of priming to drive project success and foster positive outcomes, ultimately shaping the landscape of business analysis for the better.

Work like a Surgeon

Written by Nurani Easwaran on December 7, 2023. Posted in Articles.

There is an old joke about a surgeon and a mechanic that goes like this:.

A mechanic was removing an engine part from the motor of a car when he spotted a world-famous heart surgeon in his shop. The heart surgeon was waiting for the service manager to come take a look at his car. The mechanic shouted across the garage, “Hey Doc, can I ask you a question?” The famous surgeon, a bit surprised, walked over to the mechanic working on the car.

The mechanic straightened up, wiped his hands on a rag, and asked, “So, Doc, look at this engine. I can also open it up, take the valves out, fix them, and put in new parts, and when I finish, this will work just like a new one. So how come I get a pittance and you get the big money when you and I are doing basically the same work?” The surgeon paused, smiled, leaned over, and whispered to the mechanic, “Try doing it while it’s running.”

The world in which a business analyst operates is quite like the surgical world, in the sense that a BA works with a live or running organisation and needs to make the necessary changes or improvements to the company without shutting down the currently running processes, delivering the required change while reducing impact to the minimum.

We will extend this analogy a little further from the beginning of the process (the patient comes in for consultation) until its logical conclusion (the patient goes home with the issue fixed) and see what observations we can gain from the medical world. We will also use this journey to look at the toolset available to a business analyst and determine which tool would work the best for which stage of the process.

Let us follow the example of a hypothetical heart surgeon. A patient complaining of chest pain is referred to him by a local GP. The surgeon reviews the medical exam tests conducted by the GP, forms some initial conclusions about the issue, and validates the same through further diagnosis of the patient. Based on the diagnosis and the testing, the surgeon determines that the heart is not in a good condition and that there is a high chance of heart failure. The surgeon advises that heart surgery is required to resolve his condition.

This carries some risk; however, avoidance of the surgery carries a greater risk and is more likely to result in cardiac arrest. He directs the patient to the hospital admin team to get an idea of the costs involved. The hospital admin team provides the patient with all the details, including the overall cost, including the pre-operation treatment, cost of operation, cost of recovery procedures, and timelines of each stage, so that the patient has a good idea of when the operation procedure will start, how long the entire process will take from end to end, and how much it will cost.

The patient agrees with the cost and the timelines and makes the arrangement to pay the funds to the hospital by the agreed date. The surgeon proceeds with the operation. The operation is successfully completed on time, and the patient is discharged with regular follow-ups scheduled.

Now, let us consider a parallel example in the software sector, i.e., a medium-sized software company. The company has noticed a steady decrease in profits along with an increase in customer complaints and wants to fix this issue. The company engages a reputed consultancy for this.

The BA from the consulting team arrives at the company and conducts a detailed study of the current state and the reported complaints. Through a series of discussions with the company members and interviews, the BA identifies all the key parties involved in the processes and complaints. The BA organises a series of workshops with the company representatives and uses several problem-solving techniques, such as the 5 Whys, root cause analysis, the fishbone diagram, and flowcharting of the current process, to get to the bottom of the issue.

The BA ensures that all the relevant parties understand the question by providing them with clear objectives for the workshops and what is expected of them. During the workshop, the BA also ensures that all the members get an opportunity to express their views, so that the findings are as unbiased as possible.

After this process, the BA gets a good understanding of the current state and the main causes of the issues that the company is facing. It appears that the existing software used by the company is quite old. not in line with the current needs, resulting in inefficient and time-consuming processing. There are also a few legacy processes being carried out, with some steps that are no longer relevant but are still being carried out as the staff have always worked that way.

This is resulting in a poor customer experience, with a corresponding decrease in sales and an increase in customer complaints.

These series of workshops have helped the BA and the senior management of the company get a clear understanding of the current state and the main causes of the issues being faced by the company. To take the next steps, the BA also needs to get a good understanding of the future state, i.e., what the company aims to achieve as part of its short- and long-term objectives. To do this, the BA requests that the company provide its vision, goals, and the approach or strategy decided to achieve these goals. Some of this may be readily available in the company documents but may require further discussion with senior stakeholders to clearly flesh it out so that there is no misunderstanding.

For example, the company may have planned, say, a 20 percent increase in market share, but may not have thought through or clearly spelled out all the associated elements, say, an increasing rate of production, the addition of new machinery or employees, the setup of further logistics, getting additional funding, etc. The BA helps the company work through all the dependencies and impacts and create a comprehensive future state model.

The company now has a good understanding of the as-is, or current state, and the to-be, or future state. The BA now organises another set of workshops involving all the key participants to get a clear understanding of what needs to be done to move from the current state to the future state; in other words, the BA is gathering and eliciting the requirements. During this process, the BA ensures that all the identified problems and issues and the vision of the future state are clearly understood by all the participants. This helps to ensure that the requirements are in line with the needs of the company.

Based on the feedback received from the various members of the company and their understanding of what is available in the market, the BA recommends a set of options, including some quick wins through process changes and long-term solutions such as upgrading the software or replacing it with a more efficient one. The BA clearly highlights to the senior management of the company the risks associated with staying as is and the costs, benefits, and risks of the proposed solution options. The BA also supports the company with the change impact analysis process, i.e., how the changes would impact each of the company staff involved in the current process and what can be done to ensure a smoother transition.

Once the BA gets agreement from the key stakeholders on which solution or solutions they would like to progress, the larger team, including the project managers, system architects, IT consultants, testers, and other change management personnel, is brought together along with the key members of the company, and the project is initiated. The BA carefully monitors the requirements through the various stages of the development process using a requirement traceability matrix to ensure that there is no dropping of key requirements or addition of wants based on the personal desires of some stakeholders.

The BA also ensures that the company representatives are kept well informed about the progress of the project and that there is proper end-to-end, two-way communication. This ensures that the project is successfully delivered with minimal post-project impacts.