Tag: Best Practices

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

Written by Adrian Reed on October 3, 2024. Posted in Articles.

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.

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!

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.

User Stories Without Users: The Pitfalls of Assumption-Driven Design

Written by Adrian Reed on September 12, 2024. Posted in Articles.

Where I live, every year residents receive two water bills. One is for the fresh (tap) water supply, the other is for wastewater and maintenance of sewers. The wastewater bill is a standard tariff, and I guess most people have automatic monthly payment set up. It’s the kind of thing you “set and forget about”. I mean, it’s hard to get too excited about wastewater, right?

Recently, I’ve been receiving letters from the water company trying to get me to sign up for their online portal (or app) so that I can get my bills electronically. I can almost imagine the initial user story that was written:

“As a user, I want to access my annual statement online, so that I know how much I’ll be charged”

Yet, for me at least, this is an illusion. I really don’t need another app, I really don’t need another portal account and password. For something I receive once a year there is a good chance I will have forgotten my password by the time I need to use it, and if I’m completely honest I look at about 10% of the statement anyway (I glance at the monthly payment amount then file the statement).

These days I’m a digital native, but having to access this information via an online portal would be less convenient for me. I suspect I’m not the only consumer that thinks this…

Digitalization with Purpose

I’m not saying that portals and apps aren’t useful, they absolutely are in the right context. I use online banking apps and portals all the time, and these save me time. However, I wonder how many customers the wastewater company spoke to before building their app/portal. I wonder whether they determined whether customers actually wanted it or not?

Another possibility is that this wasn’t a customer-driven initiative at all. Perhaps the director of customer service was given a target of reducing cost. One way of doing this is to reduce the amount of letters and statements that are printed. Every statement costs money: the paper, printing, envelope, postage cost plus the cost of handling it too.

But when the change is purely driven from an internal cost-saving perspective, with little or zero customer interaction, isn’t it a little disingenuous to write a “user” story from the perspective of the customer? A customer who hasn’t been consulted? There’s the danger we jump straight to a solution, and with no customer interaction this might be a solution that has very low adoption.

Understand the Real Drivers

So, if the driver is cost reduction say so. Rather than jumping straight to a user story or set of requirements, a more useful starting point will be to understand the specific outcomes that are being sought. In this case, it might be:

“A reduction in cost of sending and handling outgoing correspondence of X%”

Then, it’s useful to understand any constraints. There is likely to be a regulatory requirement to issue an annual ‘statement’ (although what a ‘statement’ is may or may not be prescribed in the regulations). With these things in mind, existing practices can be challenged.

Then, having understood why a change is necessary in the first place, we can start to work with the stakeholder team (including customers or customer representatives) to figure out ways that this can be achieved that will ideally benefit them too. Or, at least ways that they can live with.

This might create a very different set of solutions. Perhaps a solution is proposed where a customer receives a small discount for the first year when they opt in to having electronic statements. They’ll receive an SMS text message with the key details (payment amounts, dates) and an email reminding them that the statement information is there if they want it. This is just one option: it’s one that would work well for me, but I am a sample of one. It would be important to get a range of views from different stakeholder groups.

Understand Variety

When thinking about changes like this, it’s also important to consider those who can’t engage with organizations digitally. There can be many reasons for this, so thinking about accessibility not just in terms of “how can we make the digital solution accessible” but also “what are our options for non-digital engagement” is important. Understanding the variety of people, their needs and preferences is important.

In conclusion, whatever final solution is agreed upon, starting by understanding the desired outcomes (and being transparent when the primary goal is cost saving) will lead to a broader conversation. It’s important to avoid rushing towards an early solution in absence of this!

Three Keys to Building a Strong Process Management Foundation

Written by Madison Lundquist on August 29, 2024. Posted in Articles.

Effective process management is not something that can be built overnight but is critical to the success of process management programs. Recent research by APQC indicates that only 52% of organizations feel their process management programs are somewhat effective, and only 11% feel they are very effective. However, the survey findings also point out three opportunities for growth:

Align process programs with organizational strategy
Measure process performance
Ensure a strong focus on process governance

Organizations looking to leverage opportunities for growth and to build their process program on a strong foundation should consider the points outlined in this article.

First, the structure.

Organizations can structure their process team in a variety of ways; and most often, the same way won’t work best for every organization. According to APQC’s research, most organizations (44%) have centralized process teams, 29% have federated teams, 14% have decentralized teams, and 13% follow an ad hoc approach.

While organizations will favor the structure that works best with their organization’s overall structure; there are pros and cons to consider with each structure.

Next, align to strategy.

Process work has traditionally involved teams driving efficiencies in cost, cycle time, and throughput. However, over the last few years, process teams are shifting these tactical objectives under broader organizational drivers.

While some organizations are not aligning to strategy as well as they should, 49% of organizations do align their process efforts to organizational strategy.

Strategy and process management activities should intertwine and inform each other. The following best practices lead to greater alignment of strategy with the work of the rest of the organization:

Planning – Do not limit strategic planning processes to the corporate level, and make sure that the planning process is constantly evolving with business needs and forecasts. Continuous improvement is a best-practice mantra.
Measurement – Use qualitative data in addition to carefully selected quantitative data points to set strategic plans but remember that financial numbers only tell part of the story. Qualitative information can provide the context needed to make valid decisions.
Organizational structure, communication, and culture – Strategic plans should include processes for communicating strategy. The organization will never be aligned if strategy is not clearly and consistently communicated and discussed. Embed strategic planning into people’s roles, driving employees to feel motivated to contribute and feel that their time is valued.
Process design – Integrate the strategic planning process with quality processes. Be sure that quality and strategy inform each other and enable enterprise success.

Lastly, measure process performance.

Once organizations have selected their team structure and defined their strategy, it’s time to consider how they will measure the performance of their process efforts. When organizations were asked how they use measures in managing process performance, 30% of organizations only use ad hoc measures, and 16% have no process measures at all.

Measurement enables decision making at all levels in the organization. Without measuring, leaders manage and make changes in the dark, without a clear view of which changes need to be made and where.

Determining which measures align with strategic goals is the first step. Once the organization selects the initial sets of measures for the different audiences (e.g., executives, business units, departments, managers, frontline workers), those measures can be tracked over time and tweaked as necessary. When an organization can look at its performance on a granular level and see how those pieces roll up into high-level metrics, it can begin to adjust in the places where they will make the biggest difference.

Don’t forget about process governance.

Organizations can have the best process program strategies, linked to organizational objectives and with smart measures in place; however, if the right governance is not in place, those plans can fail.

Governance encompasses all the structural elements that help process management function and often dictates the efficiency and speed at which an organization implements and embeds process management into its practices. Appropriate governance ensures that the right changes are made to processes and that policies surrounding process design and management are clear and relevant to the entire enterprise.

According to APQC’s survey, 75% of organizations have process owners present in their organization and 57% have process improvement specialists. Only 38% of organizations have champions or steering committees, which vitally provide oversight and governance for process work, help to prioritize opportunities, and align processes and process work with organizational strategy and objectives. Thankfully, the number of process sponsors and champions at organizations has improved since the last time this survey was conducted in 2020, showing the increased importance organizations have placed on these more strategic process roles.

Process management programs are not built overnight, and they all follow a different path. Starting with the key topics outlined in this article can help organizations get off on the right foot.

Navigating Multiple ‘Right’ Answers in Business Analysis

Written by Adrian Reed on August 28, 2024. Posted in Articles.

We’ve probably all experienced situations where there are multiple ‘right’ answers to a question. This is particularly true with questions that appear straightforward, but actually hide significant nuance. Let’s take a seemingly simple question;

“Who released the song ‘The Boys of Summer’?”

If you know the answer, you might instinctively reply “Don Henly”. However, if you said The Ataris, or DJ Sammy, you’d also be correct, all of these bands/artists have released the song. Depending on when you were born and the type of music you listen to, you might be familiar with one, many or none of those tracks. You might even know of other versions!

Equally, you might have interpreted the question ‘who released this song’ as relating to the record label or promoter. So you equally might have responded “Geffen” or “Universal Music Group”, and you’d have been correct…

If it’s hard to get a single ‘right’ answer to a seemingly simple question like the one mentioned above, what hope do we have when undertaking requirements elicitation? We might be seeking to understand how a particular process works today, how things could be improved, or perhaps we’re wanting to understand potential requirements for an IT system. People are naturally going to have different opinions and experiences.

Yet if different people have different ways of undertaking the work, or if there are different views on what ‘good’ would look like, what do we do? How do we avoid missing (or misunderstanding) crucial information?

Avoiding Elicitation Woes

There’s no silver bullet, but three key considerations are specificity, multi-sourcing and modeling.

Firstly, it’s worth thinking about the specificity of any elicitation activity. By this I mean what level of granularity are we seeking. If we are at the very beginning of an initiative, we might be seeking answers to very big, macro-level questions. These will help us determine what direction we should take and where we should follow up. By their nature, these questions are big and fluffy, and there can be a tolerance for error in the answers. “Do you think the claims process works well?” is a big, broad, question. If the answer is “no” then it gives us something to follow up on.

Equally, as we get closer to granular requirements, we ought to be seeking very specific information. It’s crucial to actively seek to understand key terminology and probe into specific areas. We might probe into particular areas where improvements are necessary, and this is likely to require uncovering more and more detail. Feeling empowered to ask “what do you mean by that?” is a must.

Specifying contextual information such as the timeframe or situation is key. “In 2003, which band released ‘The boys of summer’ from their album ‘So Long, Astoria’” is a more specific question than the one mentioned at the beginning of this article. Equally “once a potential insurance claim has been reported by a policyholder by phone, what determines what happens next? What rules or decision logic are applied, and how?” is a more specific question than simply asking “what happens with claims?”.

Embrace Multiple Sources

However much specificity we gain, rarely will one person (or team) have a full view of a situation or process. Seeking multiple sources of the ‘truth’ is important. How a procurement process works, and whether it is efficient or not, will depend on who you ask. A procurement team might think its processes are very efficient, but managers from other departments trying to procure services might disagree as they feel procuring a product or service takes too long. External service providers might have a different view, particularly if their invoices aren’t paid on time!

Understanding different stakeholders’ perspectives will help to gain a 360 degree view. This helps avoid situations where an improvement is implemented that works very well for one group, but makes life much harder for others.

Modeling for Validation

Elicitation and modeling are sometimes seen as separate activities, and I have never understood why. I’m sure I’m not the only person who has sat with a stakeholder and sketched out a process, then quickly shown my sketch and said “is that what you mean?”.

Creating informal models is a great way of ensuring that everyone is on the same page, and also a great way to spot gaps. It might identify that there are different teams undertaking a process in different ways—and one way of improving the situation might be to unify this.

Not only this, but having some kind of model to point at ensures that areas of agreement/disagreement can be clearly highlighted. Creating a shared model, whether that’s an ‘as is’ or a ‘to be’ model, ensures that people are on the same page. It helps avoid situations where everyone appears to agree, but different stakeholders have slightly different views on what should be done.

The Power of Perspectives

All of this highlights the power of perspectives. Typically different stakeholder groups each know a bit about a particular situation or process. The art is to get enough coverage, enough variety, sufficient perspectives, to see a feasible and desirable way forward.

Doing so will ensure that the end solution or product is one that the stakeholders actually want to use!