You may define "useful" differently so it is important to be clear with yourself and others what makes information useful to you.

Teaching Others to Give You Useful Information
To get useful information I accept my responsibility to create the necessary feedback loops and quality checks--and to be vigilant about using them. I accept that I may have to teach others how to make information more useful to me. I do not expect people to learn this by reading my mind. Here are several ways to get more useful information that I find effective.

Age. Make sure all information is dated. Include creation date and revision date. Dating information this way also makes it possible to track how information has changed over time if it becomes necessary to do that.

Consistent format and language. Ask that information be put into a consistent format and language. If you get information from several different teams, provide them with a template for each type of information they give you. Each template can specify the layout of information, define terms, and provide examples. A reasonable goal is to make the information you receive more useful while not creating an oppressive burden on the people providing the information. Often this can be a matter of standardizing and clarifying terms, not necessarily requiring more information.

Vagueness. Avoid vague, sweeping, general statements without factual details. For example, a statement like "The team is working hard to finish on time" is a cliché. While the intent may be to reassure the reader, the statement is superficial and does not further anyone's understanding of the project's current situation, progress, or necessary course corrections. What does "working hard" mean? Would anyone say the team is not working hard? Which work was finished? What does "on time" mean? A more useful statement would be something like, "The team completed fourteen test scripts this week against a scheduled ten scripts. Four of the fourteen completed scripts had slipped in previous weeks. All test scripts scheduled to date have now been completed. Each team member worked four hours overtime this week to complete the fourteen test scripts."

Charts and diagrams. If you take information from planning charts and diagrams--Gantt, Programme Evaluation and Review Technique (PERT), Critical Path Analysis--insist that the charts contain a legend and a key. The legend should explain any symbols used on the chart. The key should explain any terms, acronyms, and abbreviations used on the chart. Each major milestone should have a corresponding deliverable. The resulting deliverable for each major milestone should be annotated on the chart. Let's say that a major milestone is "detailed designs complete," and the deliverable is "detailed design documents." If the chart shows this milestone is completed, you may want to randomly check some of the design documents to make sure they have the proper approval signatures and conform to any standards in use.

Work plans. Work plans that specify which work is to be accomplished are very useful. But, sometimes people read more into work plans than is actually written there. When this happens, misunderstanding is not far behind. Specify both which work is and is not going to be accomplished. This helps the boundaries of the work come into clearer view, so misunderstandings about boundaries will be less likely.

Authorized signatures. Insist on authorized signatures for key working documents such as work plans, staffing plans, test plans, designs, and requirements. Though not always, people usually read more carefully documents they sign. Unfortunately there is little protection from people who sign documents without knowing what they are signing, then later recant because they claim they did not know what they were signing.

Author contact information. Insist that all project documents contain author contact information: name, location, telephone, and email. You may want to contact the author of a project document to get more detail or to clarify something you read.

Activity vs. progress. Many project status reports contain statements of activity but no statements about progress toward project deliverables. Here are a two examples from real weekly status reports:

"I worked on that security bug we discovered Sunday morning."
"Programming and unit testing continues."

This kind of information can be made more useful by adding some indication of what has been accomplished that shows concrete progress toward a deliverable. That might look something like this:

"I worked on that security glitch we discovered Sunday morning. The vendor's technical support said a fix will be in the next release, due out in two weeks. He was able to provide a workaround until then. I am testing the workaround now and plan to put it into production this weekend. No customer data can be affected by the glitch. This will not hold up the production rehearsal milestone next week."

"Programming and unit testing continues. Our target this week was 393 work units coded, reviewed, unit tested, and approved. 375 are coded and reviewed. 316 are unit tested and approved. This shortfall can be attributed to a recurring test environment hardware issue (now resolved) and Zebra building LAN problems (see issues log). Hill-climbing chart is attached."

More on Getting Useful Information
You can read more about getting useful information in Chapter 12 of my book Powerful Project Leadership, published by Management Concepts, Inc. Chapter 12 includes categories of information, tips on making it safe for others to give information, questions to ask, ways of asking for information, and exercises to try. View other excerpts from the book on my website at http://www.striderandcline.com/book.shtml.