Skip to content

The importance of stakeholder input and elicitation.

Lee, Morgan

In some organizations, a Business Analyst (BA) will sit down with a project sponsor and collect their requirements.  The BA will go back to their cubicle and write a fantastic Business Requirements Document (BRD). The BA will review the document with the sponsor, get approval and sign-off, and hand the document over to the developers.

What is wrong with you might ask? Sometimes nothing, sometimes a lot.

The project sponsor may think they know exactly what they want and how to do it. From my experience, this has been a rare situation. By not consulting with other stakeholders in the initial requirements phase, you may experience many problems down the road. Developers often have a different way to handle a feature implementation, testers may know a better way to test, users may or may not want certain features included or omitted, but you will never know unless you ask or spend the money to develop the product and find out the hard (and expensive) way that things should have been done differently.

A BA should not just gather requirements. They should elicit requirements. This means drawing out the real requirements rather than just documenting what one person may think they want. Elicitation should include as many people as possible in the time and resources given. Discussion with the developers, testers, and end users (people that use the product) can often help shape requirements.  It is important to get the right stakeholder information as early in the process as possible.  Why develop a product that the client does not want?

Posted in Business Analyst, Requirements, Techniques.

Tagged with , , .