As other answers have stated, Management has every right to get a high level estimate upfront of a project. They are not unreasonable for trying to determine ROI.
One of the approaches that I like about Agile however is that the scope of a project is not fixed. It can be initially sized out at the Feature and Epic level, then business can determine ROI based on what are the most important features. Maybe the fancy UI with bells and whistles has low business value, but the workflow engine for handling claims has a high ROI.
When you lump the whole project together then it harder to meet ROI than if you focus on the critical business functionality that is desired.
Here is a way that I have done this:
Take your WBS milestones and turn each of these into a deliverable feature
This allows you to categorize your project into mini subprojects that have varying business value. Each of these should stand on their own in terms of business value.
T-Shirt Size the Effort on Features
This is a very easy way to get a rough idea about how big or involved a particular feature might be. Perhaps low value features still have a great ROI if they look like easy wins.
Break Down a Feature into Stories
Go through the exercise to find a small feature that is well understood and break it down into stories initially. Estimate these stories by points. Now you have a basis where
Small -> 40 points
This will be a basis of comparison to other features
Associate story point effort to all Features
Compare your Small Feature to other features. For example,
Medium Feature Y feels like it is twice the size and effort of Small Feature X of 40 story points.
Medium Feature Y is probably 80 story points. Continue this until you have story points estimated at a high level for all features.
Estimate your Team Velocity
Looking at your development team, try to determine how many story points could this team effectively deliver in a given sprint. If you have previous Agile projects as an example with this team that is a great place to start. If you do not have such history behind the team then go through a mock Sprint Planning with your team where you start looking at your Small feature that you have detailed out. What kinds of hourly estimates are people giving for their tasks on these stories?
Based on how much work the team thinks they can deliver in 2 weeks, use that total story point number as the average potential velocity of your team!
Find your Projected Completion Date
If your team in mock sprint planning feels comfortable delivering 25 story points in a sprint, and your total backlog looks like 300 story points for the gold Cadillac version of your project, then it looks like your team would ideally take 12 sprints or 24 weeks to complete everything.
Now it is trivial to turn cost of resources on your team into dollars per week to arrive at a cost for ROI vs. Business Value. The negotiation can continue on what the most important features are and then your project management becomes basically a Knapsack Problem.