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’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!
I totally agree with this premise. I often refer to solution developers and QA analysts as “consumers” of my output, which easily translates to “customers.”
Wow, I just had this conversation two weeks ago with a BA I was mentoring! So I wholeheartedly agree!!! If the Requirements don’t help them actually build it, and test it, then it’s only fair to question what value the BA is actually adding. Nicely said.
Thanks for the comments Joe and Kate! I wondered how many out there take a similar view!
100% in concurrence with post JB. I always treat Devs, architects and QAs as my customer and sometimes most critical and useful comments are recieved from them. They have a different perspective at looking at BA deliverables and a lot of imporvements are often done based on their feedback.
Thanks for post!
Thanks for commenting, Ranjan. Great to “see” you again.
hm… 100% agree :),
It’s funny that you have written this article as I have always felt this is how I get my feedback and improve my work, and thought it was common practice.
While I do receive feedback from clients it’s the developers, UX and testing teams I work with that have to ‘use’ my documentation. I have always relied on these people to provide feedback on the information they need, and clarity around how I write certain sections. They are my greatest critics 🙂
I have always told BA’s I mentor/manage that you need feedback from the people who use your outputs as sometimes clients read your work at a high level and assume you know it all because you have just spent the last few months talking to them about it.
As we all know we are a facilitator between business and IT so if we don’t take feedback from both sides how do we fully mature.
So I also 100% agree.
Thanks for the comment and welcome to Practical Analyst!
What I was driving at with this post was somewhat more than the standard seeking out of feedback from dev and QA, say, in the context of a document review session. Although part of it touches on the spirit in which any constructive feedback is received.
I’m most interested in candid feedback on how I’m going about my business as an analyst in general. I’m not just looking to get my document right, but trying to learn how to best engage the people that are going to use my output so I can make it as easy to understand and use as possible.
Soliciting feedback from delivery team members regarding deliverables is a good thing. I do it myself. But, I would not refer to delivery team as customers. I am one who “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.”
Thanks for the feedback. I’m copying my Linkedin response over here because it gives me a chance to develop my line of thought a little better on my “home base”.
I’ve found that there are lots of really smart people who come down on either side of the fence when I present the idea. In the end, as long as we’re making sure our delivery folks’ needs are met and their understanding is correct, it doesn’t matter whether we consider them as customers or the next stop on the assembly line.
Ideally, we’d all work in a team environment where the type of collaboration around requirements that makes projects successful happens naturally, but, to my knowledge, there are still many places where that’s not the reality.
So my point is that it is important for analysts to understand that there is a lot of value in going beyond just getting feedback on what’s wrong or missing from the requirements for project x. I consider that type of feedback to be a good starting point, but in most cases there is a lot more that can be done improve the quality of communication around requirements.
For me, there is value in posing questions which are similar to those I might ask a customer whose business I wanted to keep and that I was very interested in keeping satisfied.
I’d ask questions like, how am I doing? Looking at how we do things today, what is working for you? What isn’t? What could I do to make the requirements/business processes/etc. easier for you to understand and use? What would you change about how the process around requirements works today?
It’s really just about adopting a mindset that nudges us to go a little further than we might otherwise for our teammates to make sure that we’ve put them in a position to succeed.
Jonathan, amen to, “…it doesn’t matter whether we consider them as customers or the next stop on the assembly line.”
I define “customer” as one who would benefit by the value provided by the solution. The delivery team, typically, does not benefit by that value. However, the delivery team is certainly a consumer of processes in place that facilitate, secure and/or enforce the value to be added by the project.
I am an analyst for a higher learning institute and here it is not yet required to look at the developers as a customer but it is a mindset I am trying to remedy. If the people who are creating the project solution aren’t clearly informed of what they are trying to do the whole process falls apart. That is why after our projects are concluded i have instituted a “Lessons Learned” information gathering that includes both the end user the project was for a developers to see how we could improve the process next time. I know it’s not new but it was new to this place, and it has been a great help already.