I've encountered a number of projects where people didn't know the context of their work. As developers, they were working on the thing they had to develop or fix today. They might remember what they had done yesterday, but there was no sense that they knew what they needed to do tomorrow, or that they were working on something that's part of a whole. (I wrote an article about this years ago, Of Crazy Numbers and Release Criteria) I'm at a client now doing an assessment and I saw some data yesterday that made me realize people assessing projects need trend numbers, to see the data over time, not just snapshots of data.
When I do assessments, I always ask for trend data (about velocity, requirements, defects during the project and defect escape rates, sometimes code). For many of my clients, the data doesn't exist, and it's hard to obtain.
Trend data shows you the context of your progress, whether it's fast or slow. Velocity charts show you how much work you're accomplishing over time and how much change is in your project. Defect trend charts show you how well you're dealing with defects (are they overwhelming you or are you keeping pace). Trend data allows you to see the context of a project. Are 15 (or 150 or 1500) open defects good or bad? It's hard to know without trends. PMs can't make decisions about how to guide the work until they know the context, not individual pieces of data.
If you're managing project work, take a look at your project. Do you have trend data or daily (or weekly or monthly) snapshots? What would you have to do start gathering trend data? And what would the trend data show you?