#030 - The rabbit hole of requirements
Welcome to Issue #030 of The Forcing Function - your guide to delivering the right outcomes for your projects and your users.
✍️ Insights: How the road to requirements hell is paved with good intentions.
🤔 Made me think: Mistaken mandates.
👨💻 Worth checking out: Why new things make us sad.
✍️ Insights
How the road to requirements hell is paved with good intentions.
In last week’s issue (#029), I ended with some thoughts on how I’m getting out of my photography rut by getting back out there to make landscape photographs.
A common affliction amongst us photography enthusiasts is “gear acquisition syndrome”. It’s an irrational urge to buy more or better lenses, camera bodies, and accessories - regardless if we need them (or not). All because we think that by getting that £3000 telephoto zoom lens will make us more creative, become a better photographer, and therefore, be more happy.
As the running joke goes: we pay to shoot rather than get paid for our shots like the professionals.
One of the consequences of getting more photo gear is that you inevitably need even more gear to fit around or support it. Especially bags to suit all kinds of use cases: from discreet and light slings for street photography all the way to sizeable and heavily-padded backpacks when travelling on a plane. At one point, I had more bags than my wife which was not a good position to be in!
This past week, I invested in a set of filters for my camera. They are analogous to the digital filter effects you use on Instagram but these filters are physically mounted in front of your lens to get you the look you need in-camera. And, because they are essentially mounted plates of glass, they add bulk and take up space when carrying them around.
No prizes on what happened next.
I upgraded my backpack from 20 litres to 30 to fit it all in. Then, to hold and protect the filters, I needed a specially designed bag for that. After which, I needed a way of accessing that filter bag so I didn't have to take my backpack off whilst shooting to access the next filter …
Each requirement had a sound rationale based on a practical outcome. Yet this still spiralled and I wouldn’t have been surprised if I led me to replacing my entire camera system. Something smaller and lighter to compensate. Scarily enough, I’ve done that in the past - not my finest moment and an expensive one at that.
Paraphrasing a popular saying: “the road to requirements hell is paved with good intentions”. And, as I wrote about in a previous issue (#019), good intentions aren’t good enough.
Going down the rabbit hole of requirements
There’s been more than once in my 20+ year career as a business analyst that my role is about picking up the “rocks” that no-one wants to and seeing what’s lurking underneath.
On one client, I made it my personal mission to get a team off their Excel workbook and onto a Salesforce app. You’ve seen those workbooks before: kept together by digital duct tape and prayer; no-one really knowing how it worked or why it worked the way it did, and so many hacked formula cells for the myriad of one-off exceptions. It was so fragile that the workbook owner was doing the job of 2 people just to keep it alive.
But, it was critical to their process so they endured the pain and frustration of fighting with it to get the output they needed.
From doing the initial analysis, I discovered that they had an overly complicated process which needed to be rationalised. That highlighted key knowledge gaps about how things were meant to work which needed to be closed. And it didn’t stop there.
With the new process established, that in turn, revealed serious data quality issues which needed to be fixed and fully reconciled. Not only that, we also needed additional requirements to ensure that the data was always synced to its source systems. Even when that was all done, the genuine edge cases surfaced which needed a more complex Salesforce solution to support those complexities.
This was quite the rabbit hole.
Can you see the parallels with “gear acquisition syndrome”? One requirement leading to another, then another, and so on. Each requirement seeming sound and rational.
If you’re not mindful of this, you could end up staunchly believing that the right thing to do in delivering an outcome is to do everything. As an ex-manager of mine constantly reminded me: “don’t try and boil the ocean”. Attempting to do everything without heeding your constraints is a sure route to failure.
That’s all easier said than done if you’re a perfectionist like me.
Diminishing returns
There is a subtle difference between doing the right thing for your client versus doing the right thing for right now.
In making system changes, you should take advantage of the opportunities that arise. To catch up or surpass your competition, to close a capability gap, or simply to fix those small annoying things that should’ve been done a long time ago. However, does everything need to be done and to such a high level?
That’s the £1 million question: where do you draw that line and go no further?
As every situation is different, there's not a single answer to this. However, I use these simple questions with my client to understand when diminishing returns start to kick in significantly. For me, that’s where I draw the line.
How important is attaining that last X% of performance, of quality, of usability?
In reaching that %, how likely will the majority of your users consistently benefit from it?
Is the trade-off for striving to that % worth the additional costs, complexity, and time it’ll incur?
Continuing with my real-life example, it ended up being a twin-track approach. Firstly, the client realised that this was a much needed opportunity and window to overhaul their situation so they highly prioritised the work and accepted the trade-offs. Secondly, they also cut the fat (such as not customising Salesforce to completely mimic Excel) to make the delivery more feasible.
Don’t get me wrong - it was still months of hard graft. But when they went fully live, their process just worked. No drama, no hacking to force the right result, and no errors.
As business analysts, we are hard-wired to do the right thing for our end-users. We love digging into the as-is situation, to lift up those rocks, and to deal with what we find - even if it’s unpleasant. If it needs to be fixed, then we help get it fixed.
But we don’t work in a vacuum where we can pursue perfection with abandon. In going into the rabbit hole of requirements, we also need to know when is far enough and when it’s time to get out. Otherwise, you’ll be in a never-ending cycle of finding more and more things that need to be done before you can be happy.
Which rabbit hole are you in now and is it time for you get out?
“Perfectionism rarely begets perfection, or satisfaction - only disappointment.”
Ryan Holiday | The Daily Stoic host
🤔 Made me think
Mistaken mandates.
One of the dangerous ways to get even more lost in the rabbit hole is when you take an off-hand remark as something sacrosanct.
Always validate the requirement and assess how truly important this requirement is in the context of the rest of your requirements.
Even asking something as simple as Cap Watkins’ “sliding scale of giving a f**k” (see Issue #002).
🧑💻Worth checking out
🔗 Why new things make us sad | BBC Reel
I’m not sure if I’m more relieved than surprised that “gear acquisition syndrome” was a thing back in 1769.
Coined “The Diderot Effect” by anthropologist Grant McCracken, it highlights the spiralling need for consumers to buy new things to fit in with the new things they’ve recently purchased - all to support their idea of self-identity.
So, if you’re not careful, as Tyler Durden from the 1999 film “Fight Club” put it: “The things you own end up owning you.”
You can find out more on BBC Reel.
🖖Until next Thursday ...
If you enjoyed this newsletter, let me know with the ♥️ button or add your thoughts and questions in the comments. I read every message.
And, if your friends or colleagues might like this newsletter, do consider forwarding it to them.
For now, thank you so much for reading this week's issue of The Forcing Function and I hope that you have a great day.
PS: Thanks to P for reading drafts for me.
Those are great questions to ask to assess diminishing returns.
There's also another way of looking at tasks in front of you.
For example, rather than asking, "is X worth doing?" My software development team likes to ask, "what is the next task that adds the most value to customers with the least cost?"
One problem with the former question is it pits egos against egos on a team. *Somebody* thinks it's worth doing, while another doesn't. No matter who has the final say, someone's going to be disappointed for sure.
The latter question reframes everything such that it's not that X isn't worth doing, but maybe it's worth doing later, when other deliverables are done that are more valuable to the *customer*. And in that situation, the customer becomes the decision maker rather than someone on the team, so internal politics shouldn't play a role in the decision making process.