We know that the business stakeholders whose needs we elicit and capture as requirements are our customers. We know that the sponsor who foots the bill for our work is our customer. Often, product end-users are considered customers. We don’t typically think of designers, developers and QA analysts – our delivery team counterparts – as customers, but maybe we should.

I’ll explain.

I’m convinced that one of the surest ways to be successful as a business analyst is to think of and, to a degree, treat the consumers of our deliverables as we would other customers in the sense that we are anxious to provide them a quality product and interested in ensuring that their needs are met.

I know there are some who take an assembly line view and would say that the people down the line that use our materials to produce an end product aren’t our customers any more than the folks who paint the automobile are the customers of those who built the frame. And in some ways they’re right. Some aspects of the provider/customer relationship won’t apply. Others will say that if you bend over backward to please your colleagues in such a way, they’ll take advantage of your goodwill or push you beyond the bounds of what you should be doing. Sure, that’s a risk.

But consider this: whose needs do business analysts most directly meet? Who is most dependent upon the quality, accuracy, and communicative value of the BA’s output?

I think we also have to recognize that requirements and other analysis deliverables do not, of themselves, satisfy business needs or solve business problems. Unimplemented requirements haven’t provided any real business value, and they can’t until they’re incorporated into a solution and released for use.

While a significant part of a Business Analyst’s stewardship consists of identifying stakeholder need, equally important is our role in putting those that will build and test based on our input in a position to succeed. In the grand scheme, solution delivery is a team sport. As such, it becomes very hard to decouple a business analyst’s success from that of the solutions his/her team delivers.

If our success as analysts is dependent upon the success (customer satisfaction?) of those who use our “product”, and it clearly does, it becomes us to seek out feedback on how to better please these “customers”.

I’ve found that seeking periodic feedback from my development and QA counterparts on how well my deliverables are meeting their needs has helped me improve as much as a business analyst as anything else I’ve done.

If you haven’t done it lately, ask a developer or a QA analyst how easy it is for them to take and use your deliverables. Ask them what you could do to make it easier for them to understand what the business needs. Ask them what they’d like to see added or removed from the product you’re delivering them. Work to discover as many ways as you can to deliver them a better product.

As you do these things, I think you’ll find that your working relationships will improve. The constructive feedback you provide will be more carefully considered, and the team’s overall effectiveness at delivering quality solutions will increase.

So, what do you think about the notion of treating the users of our work product as customers? Agree? Disagree? Ever tried it? I’ll be interested to hear your thoughts!