Tuesday, March 3, 2009

Getting Quick Answers by Giving Them

Our business analyst was having a difficult time getting responses from one of our users. I think it's partly because of the way that he's asking the question.

I can't go into detail about what he's asking, but it requires a detailed response. The development team can make a pretty good guess at what our business partners will want, but we can't say for certain.

Asking for the detailed response yielded nothing for weeks. It became clear that the business partner wasn't going to respond on his own.

To accommodate for this I suggested that we reframe the request with an example of how we think that they might want it. We'd essentially be answering our own question or at the very least be leading the witness. After we presented the reworded request the business partner requested a small change and approved the requirement. Like that, it was done and we could work that feature.

The irony of this requirement is it wasn't anything that was all that important to anyone. It was a necessary piece of our project. It just wasn't important enough to our business partner to prompt him to specify what he wanted into a detailed document. It wasn't important enough to the development team to write up a suggestion. It just sat out there and both sides of the team deferred specifying the requirement, and some people became frustrated with the lack of progress on this issue.

It's ironic that we could have escalated this issue into a blamestorm when all it really took was for a developer to sit down with the business analyst and write up a short document outlining a proposal. That's all it took for the business to sign on.

There are some people who feel that the individual should have done what was asked of him. That really isn't my concern, I am not his manager. My concern is getting our project done. If it takes a little extra effort on our side, I take no issue with that.

No comments: