When I first started managing projects, the role of the business analyst was badly understood and seriously underappreciated. The BA was viewed as little more than a scribe, capturing the customer’s requirements without adding much value.
The sad part of that perspective is that it was the fault of just about everyone but the business analyst. Customers assumed they knew exactly what they wanted, sponsors and project managers allowed the customer’s perspective to become the approved requirements without questioning them, etc. Of course, everyone then complained that the customer didn’t know what they were doing while dealing with a significant number of change requests—and complaints from that same customer that the project wasn’t giving them what they needed!
Slowly, things changed with the evolution of a use case-based model that focused less on what the requirements were and more on what the customer was planning to do with solution that was being built. That approach survives today in both traditional project delivery and as (the similar) user stories in agile. Use cases allowed the business analyst to not just document the customer’s requirements in terms of how the system would be used, but also to translate that into features and functionality that could actually be built.
However, even with use cases there was still a
Please log in or sign up below to read the rest of the article.