“On a scale of one to ten, how resilient would you say you are?”, I was once asked in an interview.
I responded: “ooh – a seven – maybe an eight”
“Really? Why not a ten?” came the reply.
“Because, whilst I’m an optimistic person and will always bounce back after a setback, I’m also a born analyst. That means I see things at many different levels of abstraction, and as such I’m sensitive to things others perhaps aren’t, which means I’ll always see more threats. And actually, for precisely this reason, I think a BA always needs to harbour a healthy element of self-doubt in order to be effective”.
It impressed my potential suitors, and is, I think, what clinched the role for me.
But within that answer – and even the question itself – is a fundamentally important point:
Change is risky, and risk undermines confidence. Therefore successful change is ultimately about generating and maintaining confidence.
Confidence is that reason why, in a waterfall environment, the requirements need to be documented and approved before the design starts. It’s the reason why we plan projects, test solutions, RAG-status updates, and gain approvals to proceed. When we manage the change, we need to give our stakeholders confidence in the to-be state – not only that it will be better, but that nothing will break in the process.
It’s why, as analysts, we draw diagrams to allow stakeholders who are otherwise ‘in’ the change to be able to work ‘on’ the change. It’s why our documentation needs to be manicured – all the ‘i’s dotted and the ‘t’s crossed, the grammar correct – because nothing exacerbates the nervousness associated with change quite like a mistake in the document describing it.
“If you can’t even get that right, what are you going to do to my business area?!”
So in a waterfall environment, promoting confidence means taking extra care (and often extra time) to make sure everything is correct before it goes public.
This is a real challenge for BAs – because Agile and product management have turned this dynamic on its head.
In a fast-moving, ever-changing digital environment, the very concept of waterfall has been invalidated: by the time you’ve dotted the ‘i’s and crossed the ‘t’s, the ‘i’s have become ‘j’s and the ‘t’s have become ‘u’s! It’s quite literally impossible to project out what future needs will be from a static point in time.
Notice how I just used the word ‘project’ as a verb rather than a noun? Actually the noun comes from the verb – not only is the waterfall methodology inadequate for today’s change environment – the same applies to projects (literally named that way because they ‘project’ out a future state). The logic is now fatally flawed.
Hence, Agile and product management: we won’t know exactly what we need, so let’s start with something quickly and see how well it works in reality; then use that feedback either to decide to pivot onto something else, or evolve it to make it better. We build confidence, not by thinking of everything up-front, but by doing something and using the facts it generates to react accordingly. Generating facts from real users is far and away the most effective requirement elicitation technique.
It’s much more effective because in a digital world, often customers don’t know what they will want, because they don’t necessarily know what they can want. Consider current affairs – have you ever noticed how everyone’s a critic, but nobody seems to be able to imagine and articulate a better system for running the country? It’s human nature – we’re extremely bad at ‘projecting’ out what we will want in the abstract, and much better at deciding whether we want something when we see it. Basically, we’re better with buffets than we are with menus!
Again, this is about confidence.