Value and quality perceptions by lower level stakeholders are very problematic. New systems means 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.

In my experience there are only two effective mechanism for alignment: Strong top down enforcement (people don’t complain when it doesn’t work) and increasing the clarity with which the lower level stakeholders can see the value they are contributing to the larger enterprise (people want to know their job matters and respond positively when it does). I’ve seem people practically come across the table with excitement because they “finally understand my job” with a system that might fairly be characterized as taking away their freedom of action and putting them under a management microscope.

Yet another up front BA alignment job to make it work though.

While this is true, it’s also at a different level of granularity. EA analysis of customer value is going to define value attributes and/or characteristics that the project, as defined by the customer, could/should/would bring to the organization if the potential solution is implemented.

At the project level though, 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.

This is ever more important without EA or an immature EA being in place.

It that is a valid distinction, then the ‘in the future’ clause as part of the goal of a software organization makes it a best practice. It may or may not be a customer value proposition. Like any other best practice it is subject to alignment with the customer value.

In rereading the thread, I realize that I’m looking at the topic from a BA perspective of liason between separate IT and business organizations. In this case the tension between internal best practices that aren’t aligned with customer value (over engineering by building too much adaptability or missing the core value entirely) is, in my experience, too common.

From the perspective of an IT organization that has strategic responsibility for business success, e.g. office of the CIO, establishing the ‘in the future’ clause with its implication of adaptability, interchangeability, and scalability is an establishment of a [ed. Excellent!] business value requirement to be implemented by aligned development best practices.

To, finally, get to the question of particular practice, test, or meeting that helps deliver value: Lets assert that it is possible to find IT development organizations competently executing best practices.

The need is to understand the customer value better. This implies a better understanding of the whole customer system to assess the collateral impact. Note that the business may not be able articulate the key issues up front. Quick example:
* service provider who commissioned a survey management system when the entire value was a tick mark on their client’s capability questionnaire. (weren’t at a maturity level to do process improvement based on surveys)

It’s too easy to say this is just something the BA should do. Customer value analysis falls into the EA knowledge area of the BABOK which is still evolving so the best practice and techniques may not be in place.

Doug, I think you are right on for a line of questioning that unearths how your business perceives both the value and the quality attributes of any given project. I’d be interested to hear what people have to say on this and how they have approached this in their software development organization.