I'm sorry, I don't think you quite understood the point of my statement.  It wasn't to force the business into receiving something they don't need anymore.  Let's say we've got a project with 22 different business groups working with a central system (this is based on a current example of what I'm doing).  Everyone has agreed, in writing, to a certain spec.  Suddenly, 1 of these groups demands that additional functionality be added/changed/removed in order to accomodate their 'changing business practices' (read: they are trying to get something in they wanted from the start, but did not get enough support from the entire community to have it included).  This change will have a major impact on the entire solution, and cause other partners to have their change their technology and business processes. Now, repeat this situation with at least a dozen of the 22 groups.  Without a good change management process, these types of little 'requests' can quickly derail a complicated project. 

Working in a multiple, independent stakeholder environment means that change must occur more slowly than in a situation where a single business is in control of the entire environment.  Without a way to ensure that changes are rigorously debated, refined, and eventually agreed upon (for inclusion or exclusion), such a project will go absolutely nowhere.  This may not satisfy your condition of providing the right value to some of the customers, but in my mind for such a large project you have to try and satisfy the vast majority.  If you end up building something that no one is happy with, then you've failed.  But if you are able to deliver something that most, if not all of them, agree satisfies a certain need, then you've done well.  Usually the key is to focus on providing some broad value to many initially, since there is usually a small piece that everyone can agree on, but will disagree on the rest since they all do things differently.  Then, once you've delivered something, you can look at doing more with those who have similarities between their processes (or are willing to change them), and continue to iterate...

The way I learned BA is that our primary tasks are to first simplify and then integrate and automate.   I also learned that probabaly the biggest payoff was in simplifying.    Is there any focus in Agil  on simplifying the as-is, before moving on to the to-be?

Tony

Larimar:

I guess you could call it business process re-engineering, although it does not necessarily need to be always enterprise wide.  If the scope of the effort is relatively narrow, one might call it a mini-reengineering or something.    Is'nt such "reengineering" within the scope of what a BA does?   Shouldn't it, in fact, be the major thing that a BA does?     After all, it is called "Business" analysis.  

And if BA's are charged with doing such reengineering, shouldn't they be most focused on as-is modeling, instead of jumping right into to-be modeling, as is typically the case with Use Cases?

Tony