Making Friends with Ambiguity

Ambiguity is a good thing.

That may first sound counter-intuitive to everything you’ve learnt about Business Analysis to date. And it will be a mess if you don’t get the timing right. But with the right controls in place, a little ambiguity in your requirements can lead to more creative solutions, as well as empowering team members to truly make a difference.

Often we don’t realise that trying to “do the right thing” and providing as much detail as possible up front actually limits ongoing creativity. This applies to situations as simple as telling a developer to use a drop-down box based UI instead of telling them you want users to be able to access various functions all from the one screen; and as complicated as advising that a business implement Sharepoint instead of advising that they need to develop a collaboration and knowledge management strategy.

Courtesy of http://funnyfunks.com/wp-content/uploads/2013/11/funny-creativity-comics.jpg

The secret to being successfully ambiguous? Don’t substitute detail in place of clarity.

Less solution detail does not mean less solution clarity, if you centre conversations around VALUE, not just OUTPUT. You can facilitate everyone in imagining what value looks like – whether that be using tabs or accordion based UI in the simple example, or a wiki/Google Hangouts for the complicated scenario – and from there come up with solutions you didn’t even know were possible. And at the end of the day, you’re still going to get VALUE, just that the output itself may be a little different than what you were expecting.

(Side note: I feel like the BABOK here is a little bit ambiguous itself on the definition of solution requirements and indeed functional requirements, and not in a helpful way. I believe that behaviour and information the solution will manage is correct at a high level – but this should be separate from the lowest level of requirements – let’s call them technical requirements.)

This does NOT mean you can be lazy with collecting, writing and managing requirements. The responsibility for requirements still lies with you, as the business analyst – however it just means giving up a little bit more control over the solution in the early stages. After you’ve had the robust discussions about how to achieve value, then your next level of requirements breakdown should contain more detail and be less ambiguous. Then break it down again for the next level of detail, right all the way down to low-level testing. Make the decision to converge on detailed requirements only at the last responsible (or necessary) moment.

Courtesy of http://www.vmi.edu.vn/

This won’t work for every situation – you won’t be looking for as much creativity or empowerment in a Six Sigma environment, nor if you have strict regulatory requirements to follow.

If you find you’re getting push back on team members not actually giving input, just sitting around waiting to be told what to do – well, you might enjoy that if you love being a command and control type – but if you want a true shared outcome, set the context, roles and responsibilities clearly up front. Facilitating a kick-off session to discuss and investigate the environment in which the problem the team is trying to solve helps provide greater context and hopefully a greater sense of purpose rather than “we’re here just to do what they want”. RACIs are just one of the tools you may find helpful in that session.

Also, if you find you’re not getting the ongoing quality or speed that you desire, set shorter review cycle times. Set the tone that this freedom has to be balanced out – everyone has to back up their interpretation of the requirement with an MVP – whether that be a wireframe, working software, or good old pen and paper. But keep that balance between divergence and convergence.

So despite all the negative press, ambiguity is a powerful and useful thing to embrace. As long as you are disciplined with your focus on value, the tension ambiguity provides is a small step on the way to becoming more adaptive, a way to imagine more creative solutions and allow everyone to add their individual touch.

And that’s why ambiguity is a good thing. And a beautiful thing. Or an awesome thing.

Don’t forget to leave your comments below.