Don't be constrained by your tools. If your tool doesn't do what you want, refactor the information you plan to display.
Define Audience Expectations
In order to deliver the right view, you have to decide what's important. Adjust the presented information accordingly.
For example, for an executive meeting, I might choose to provide only major project milestones or estimated shipping dates. The executives won't care that the Foo() class needs to be embiggened in order to meet the milestone; they generally just want to know when "stuff" will be shippable to customers.
For a meeting within the project team, the full work breakdown structure might be more important, and I might even be tempted to leave shipping dates out of the presentation since they are usually management (rather than team) driven.
MS Project vs. Paper and Pencil
I would assume MS Project can filter views, and can print them as either PDFs (which can't be changed) or that you (as the presenter) can direct the conversation towards the level of detail that you want.
On the other hand, as an agile practitioner, I prefer using different artifacts to present different levels of detail. For example:
- For an executive view, I'd use the Product Backlog, theme/epic cards, or a project burn-down chart to represent the information.
- For a team view, I'd use the Sprint Backlog, a snapshot or two of the Kanban board, user stories small enough to fit in a single sprint, and a sprint burn-down chart.
Again, your mileage may vary widely on this. The important thing is to present the right data rather than allow your tools to constrain the data you're able to present.