Business Analysts
(BA's) live in a world of requirements.
And while never the 'owner' of a
project, they often bear the burden of requirements responsibility.
Two interesting
things I got to see in the fascinating world of business analysis this last
week made me think about how exactly I would recommend approaching these
scenarios (one shared here, the second in the next post).
Business analysts
assist in make sure things not only go smoothly, but also in ensuring the RIGHT things continue on track. So a BA received feedback on a report. The person addressing the BA told them to put the report in a certain
format. Now a more junior BA, he listened
intently and described what he had done.
He asked what was wrong with his method and the response was basically
it wasn't in the format as she was describing.
This went back and forth for a few minutes with nothing more decided than someone feeling that the report should be in the new format and a very unsure junior BA.
In talking through this
situation with the junior BA, two very good questions came up:
- Why? What's the purpose of the report?
- What question(s) is the data answering?
Two very simple
thoughts, but something I'm not sure all us BA's really stop and ask ourselves,
ask our stakeholders. We put SO much
effort in all our documentation, but do we stop and validate ourselves? Do we double check the information we're
providing is solving the need and ONLY solving the need (no sugar
coating)? I think these are two great
things we should work on asking up front and more often on every single piece
of documentation we work hard to create.
But these are only
two good questions - many more are there!
What questions always help you ensure you're only doing activities that
will help your initiatives and ONLY those initiatives?
