Helping Stakeholders to See the Wood for the Trees

Trees in front of evergreensOne of the real challenges associated with business analysis is drilling down to the real business need and requirements.  Often stakeholders will come to us with a preconceived idea of what the solution might be, and through a range of elicitation and questioning techniques we help crystallize an understanding of what they really need.

Ironically, this challenge can be even more prevalent when speaking to the most experienced end-users.  Often, large organizations benefit from having extremely skilled and knowledgeable staff who have worked in their roles for decades.  They can provide a mine of information and can really help us to understand the context of the organization and the role they undertake.  Often, these stakeholders know a huge amount about what customers really think about the organization and where the organization’s processes aren’t working as efficiently as they could.

However, in some cases they may struggle to “see the wood for the trees”.  Since they work so closely with the systems and processes in scope of the project, they might find it difficult to imagine how things could be any different.  This won’t be true of all users of course—there are often some that are very proactive and innovative—but some might find it difficult to see beyond the existing system and process.

This can make eliciting requirements really challenging.  Imagine you are re-engineering a process and an experienced user tells you there is a critical step to “obtain the customer’s signature on form XYZ” before proceeding further and that this often causes delays.  This might lead you to think about ways to optimize the process to get the process quicker; perhaps you could send a form earlier in the process.  However, it’s also important to ask why that signature is necessary in the first place.  Perhaps the process step could be fundamentally changed, or perhaps it isn’t necessary at all.  It’s important that we explore these angles tactfully with our stakeholders.

For example, if the signature is being obtained in order to authorize something – then a more logical activity name would be “obtain the customer’s authorization to proceed”.  This subtle semantic shift opens up new ways of thinking about the process.  Perhaps a signature isn’t required – maybe an e-mail would suffice, or maybe a quick phone call to the customer.  Only by abstracting away the current physical attributes of the process can we start to see this.  Clearly, we’ll also need to consider any other general, non-functional or regulatory requirements which might constrain us, and there would need to be a wider discussion about how the solution is designed.

Henry Ford is often cited as having said, “If I’d asked my customers what they wanted, they’d have said a faster horse”.  Sometimes our stakeholders need help in understanding what they really need, and as business analysts, we have the skills to help them!

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.