Whose perception of value do we care about?

As business analysts we often deal with business stakeholders at multiple levels of the organization. Someone has to help multiple people align around a common understanding of a project concept and then create a plan of action to implement the best possible solution and it’s a natural place for the BA to be, even if their focus is within the IT organization. If we accept that as an IT organization we are responsible for delivering value for the business, the question arises of whose perception of value we honor.

A few weeks back I posted about  delivering value and it’s relationship to quality and speed-to-market in a software development organization. In the comments an interesting dialog surfaced about whose perception of quality and value we care about anyway. It didn’t really get finished off, so I thought I’d take it on again and see if we can’t explore this a bit further.

Multiple business stakeholders, multiple perspectives

DougGtheBA started the train of thought with the following comment:

Where do customers find opportunities of the system. To an executive manager, the opportunity is to reduce cost. That provides quality to the business environment by controlling cost. To the middle manager, the opportunity is to enhance staff productivity, which provides quality in volume delivery to someone. To the end-user, the opportunity is to streamline necessary steps from the daily grind and the quality of that person’s work life is enhanced while meeting the needs of the management.

So yes, as business analysts, we deal with stakeholders at multiple levels of the organization. They all have different perceptions of value generated by the same project given the scope of their accountabilities within the organization.

And multiple perspectives means diverse input

Nathan Caswell picks up on this idea and questions whether aligning competing perceptions of value falls to the business analyst:

The need is to understand the customer value better. This implies a better understanding of the whole customer system to assess the collateral impact of a project. Note that the business may not be able articulate the key issues up front.

And then later, Doug writes:

At the project level, there must be some sort of trickle down to align customer expectations of quality and value just like aligning any other aspect of a project, e.g., business rule, process, etc. Lower level stakeholders may not have the same perception of value/quality as the sponsor. Hence, delivery of a solution that is perceived to reduce the quality of work-life, for example, while positively addressing whatever the sponsor views as higher quality, might be deemed as a failure.

We might be tempted to side-step this problem by saying the only perception that matters is that of our primary stakeholder. This perception can indeed solve the problem, if we are so lucky to have only one primary stakeholder. But even so, the perception of that one person might be limited. As Nathan Caswell later replies “The CEO isn’t going sit for an interview by every project.” And since we know this is the case, then is it our job as business analysts to elevate the concerns, questions, and ideas from other stakeholders so that the primary stakeholder can not just make a decision, but make the best possible decision about the direction of the project? And, as I think it is, how do we do that?

But are stakeholders always right?

And yet, we can’t necessarily take everyone’s perceptions at face value. As Nathan continues:

Value and quality perceptions by lower level stakeholders are very problematic. New systems mean change, which is fuel for push back and dissatisfaction. And some sponsors can have very selective memories of what they asked for when faced with restive troops.

So yes, there is a tension here not just in managing stakeholders but collecting their input into a cohesive view of the problem to be solved. We hear a lot about the difference between the terms “requirements gathering” and “requirements elicitation“, but these dialogs focus on how you obtain the voice of a single stakeholder to come up with their requirements. What we are talking about here is getting inside the multiple perspectives of the project, sifting the input through the larger objectives to be fulfilled by the project (or the goals of the organization as a whole), elevating the most appropriate input to the primary stakeholder in a way that they will be open to hearing it and acting on it, and then traversing the scale back again, selling the new concept “down” the organization, and soliciting the input appropriate to the revised concept, taking care to keep watch for any new details that might need to be resurfaced back through the process.

Is it no wonder our heads don’t explode?

At any rate, I’d love to hear your thoughts and ideas about this problem of creating a cohesive view of stakeholder input and how you address it. Do you let your stakeholders battle it out? Does one group trump the other? Does the primary stakeholder just get his or her say? If so, what opportunities might your organization be missing?

Related posts:

1. Do you have the key business stakeholders involved in your project?
2. Taking care with your digital footprint
3. Help a BA! How do I prevent overlooked issues and project mishaps?