TFS Cross-Project Reporting

We are migrating towards TFS and have decided based on online commentary to structure TFS as one Project per team, with each "real project" being an Area (and each release an Iteration).

This means our TFS structure is somewhat like:

Apps Team
  - WinForms Project
  - WPF Project
  - Embedded Project
  - WPF Project 2

Web Team
  - Admin Site
  - Client Site
  - Client Site 2

DB Team
  - General Scripts
  - DB 1
  - DB 2

However, from a management perspective it is tedious to review each team's reports individually.

I am wondering for those with experience using this structure, which of these options (or other option) have you successfully used?

1) Move all teams to the same Project

Pro: No report changes
Pro: Cross-team awareness
Con: Clutter
Con: Perhaps security

2) Change all reports to be cross-team

Pro: Teams can still have own Projects
Con: Have to change and synchronise all reports across all Projects
Con: Reports become less useful to individual teams (can still customise copies)
Con: Teams should share the same process template (a non-issue for me)

3) Setup a TFS Project just for Management containing cross-team reports

Pro: Only have to change one TFS Project
Pro: Maintain current team-focused reports
Pro: Reduced risk of management breaking Work Items in team projects.
Con: All teams should use the same process template (a non-issue for me).

Solution

I have set up projects as you've defined above. And I've configured TFS reporting for both #2 and #3. The thought of forcing teams to re-org so the reports work out makes option #1 too severe for me. #3 is appealing, but in a similar way to number 1, limits individual teams to sharing same work item types and process templates. Invariably I end up in the 2 state. Particularly if the teams evolve their processes independently. I've been able to mitigate the "reports become less useful" problem by investing in customizing reports (non-trivial I know).