Let me share one of my more humbling experiences as a business analyst. To be perfectly blunt, the developers did not like my requirements specifications. It was hard to realize that I had failed to communicate requirements in a way that was meaningful to them. But the hard truth was sitting right there in front of me.
I could cite many reasons for why this happened. There were some legitimate challenges, one of which is we are all in separate locations, so we relied primarily on phone and email for communication. But the hard truth is that I forgot to simply ask the developers what would help them most.
I got started quickly and got lost in my own assumptions about what would be good requirements spec and where my role would fit into the development process. I relied more on my prior experiences of what has worked in the past than on what would work in this situation. I mistakenly assumed that because my way of doing things had worked before, it would work now.
I realized that no matter how similar a situation seems to a prior experience, there is one variable that is different: the people. And the people count big time. Because as people we do unexpected things and have unexpected perspectives and expectations.
What do you do when your development team tells you (directly or indirectly) that the way you specified the requirements is not working for them? How do you respond? What do you say?
I think you have to start by taking 27 steps back and setting aside all assumptions, frustrations, and, most importantly, your ego. As Cecilie Hoffman told me in a recent interview “check your ego at the door.” Or, maybe, you need to put your ego in a locker and give the key to a trusted friend who has a heart of steel. You are going to feel pretty battered as they tell you exactly why the requirements you pulled together won’t work for them. Embrace the feedback. Remain open, non-confrontational, and non-defensive.
Take the time to figure out exactly what it is that will make them successful. And then go about figuring out how you can make that happen. Just like code, requirements can be refactored to make them more usable and extensible for your situation. It will take much less time to do this than you think.
And on your next project remember: Ask the developers first, write the requirements specifications second. Because at the end of the day, if your developers won’t or can’t build the solution to your requirements, you’re not going to be successful as a business analyst.