[Part 2 of a 5-part series of posts about ways of being while being a Business Analyst]
Something I see with junior BAs a lot is an ego attachment to the requirements they produce. When the requirements change, they get upset. They are disturbed when the beauty of their creation is unwound by one missing stakeholder who turns up with their pile of messy ideas to add to the mix. They have an anger response to revisiting approved requirements.
As a business analyst, you facilitate the expression of others’ ideas to feed the work of even more people. Diplomat, translator, liaison, messenger, advocate, shepherd. That’s what we do. It’s not about us as business analysts, it’s about representing your customers’ or users’ ideas to the best of our abilities.
It takes conscious effort to recognize how you are reacting to change, and making a different choice in response. I try to frame requirements changes as a gift. I’m grateful to my colleagues and clients for helping refine the requirements and making them as accurate and relevant as possible. The cost of change skyrockets once the functionality leaves the requirements phase, so it’s a cost-saving move to change requirements early on.
I like to joke that managing requirements is like taking care of other people’s kids. We’re responsible for their care and conduct when they are under our supervision, but the qualities of the requirements were never ours… they belong to the parents/clients.
Other posts in this series: