The Hidden Cost of Side Quests: How BAs Can Protect Their Time
Back in the late 2000s, I started a new job, having worked for my previous employer for a long time. It was a really weird feeling—I can still remember entering the building, being assigned a desk, logging in and there being virtually no email for me.
I was already assigned to a project, and I was introduced to a key stakeholder. It was a fairly small project, albeit with some hidden complexity. Working with the project team, we got it done, and the analysis work was done pretty quickly.
Partly, this was because I was new and keen to make an impression. But, on reflection, another reason I was able to get the analysis done quickly was (as a new team member) I didn’t yet have the overhead of a whole number of ‘side quests’ that tend to accumulate over time.
What Type of “Side Quests” might a BA be drawn into?
I don’t know about you, but I’ve been drawn into a whole range of other activities. Often there are good reasons for this, but sometimes I can’t help but think that what I’m really doing is filling a gap in the organizational structure.
Examples might include:
- Providing production support to production systems: (“You wrote the requirements, you know how it works…”). This might be genuinely useful and necessary in a transition period, but I suspect a few people reading this are still supporting some elements of a system they worked with years ago, and that sounds like gap filling!
- Quality assurance: BAs absolutely can feed into testing. Yet, as much as I’ll give some (very limited) testing a go, I know that I am not a professional QA engineer, I have a different skill set. In fact, I love working with QA colleagues, as they will often help me sharpen my game by reminding me that quality assurance is about a lot more than testing, and they can provide useful peer reviews on requirements artifacts too.
- Messy workarounds: If there’s a ‘temporary’ workaround, it might make sense for a BA to help operationalize it. Yet, issues occur when the organization decides that workaround isn’t ‘temporary’, and three years later somehow you’re still lumbered with the task of deciphering operational data via an unmanageable spreadsheet with macros…and everyone is shouting that they need it ‘today!’
In all of these cases, it can be valid for BAs to be involved for a limited amount of time. Context is everything. Yet, being drawn in for too long, or finding that it becomes a permanent part of your repertoire could be damaging.
Put differently: If a BA ends up providing perpetual informal production support for every system or process they are involved with changing or deploying, then they have less capacity to do business analysis after every project. There will come a time when their role is more support than analysis.
Advertisement
Saying “No” by giving options
The challenge, though, is that these ‘side quests’ often are important to someone, and might be crucial to the organization, which makes them hard to say no to. A key question here is around prioritization: are they as important as the project work. Or put differently: should the project work be delayed, to create space for the side quest. If a project is the priority, then this might mean saying no to a side quest or two… but that can be hard.
So what approaches are there for saying “no” constructively?
I live in the UK, and if you’re not familiar with our culture, it’s somewhat indirect. In fact, when I say “somewhat indirect”, what I actually mean is “completely indirect to the point I literally don’t know how non-native English speakers decode what we are trying to say most of the time”. So, as you can imagine, a curt “no” can be tricky. What follows is written through the lens of a UK citizen, things might be different where you are.
With regards to saying “no”, I once had a fantastic manager who gave the following advice which has always stuck with me:
“Try not to say ‘no’ outright, unless you really need to. Instead, find a way of saying ‘yes’ by giving implications and options”
This might sound like:
“Yes, I could absolutely take a look at that production support issue. That’ll likely take around half a day, which will delay a core project deliverable. Shall we go and speak to the project manager to ensure that’s OK? If it isn’t, perhaps I could ping you over some documents that might help, and I’ll be on hand for any quick queries?”
“Yes, I can certainly continue to help with the manual workaround. However, I’m likely to be a bit of a bottleneck, due to project work, which is always going to take priority as it’s my core role. I wouldn’t want to delay you. How about I train one of your team? I could also make a quick video of the process, so they have something to refer to. Then you’re in complete control”
Sometimes It’s a Hard “no”
While the approach described above will work in many situations, there will be times when a hard ‘no’ is necessary. In those cases, in my experience, it’s best to be direct (however uncomfortable that is). I have been amazed that often when I say no, and give the reasons, people are actually extremely understanding. Even if they aren’t, it’ll be some short-term discomfort while the issue is discussed, instead of long term pain (if you’ve ever taken on too much work, you’ll know how painful that feeling of overwhelm can be!).
Ultimately, whether to say ‘no’, and how to say it varies depending on context. You have to do what’s right for you. I hope this blog has given you some food for thought!
