Email Us Today

Knocking the Stupid out of Status Reporting

Published October 17th, 2016 by Devteam

This is a draft. If you wish to review drafts like this one and more detailed information, please email This message will be removed for final version.
Status Reports: Time Sinks that Don't Work

Do you feel like way too much of your time and your staff time is taken up compiling, endlessly updating, and delivering status reports? Do you have repetitive, long, vague, probing status conversations anyway? There are several ways to improve the entire process of status reporting. Key status topics including how to implement a reasonable status process:

A&I™ Irritating Research™ Surprising what people actually do.
Symptoms. Problems, & Opportunities.
What Doesn't Work & Why.
What Can Work & How!
Data. Status must simply be a subset or summary of data, not opinions, whitewashing, or vague blocks of text...
Documents. Status must pull from and link to your project documents.
Methodology Choices. and If you Want Help Implementing?

A&I™ Irritating Research™

On two software development projects (over US $15m each) we studied how people actually use status reports. Not what they asked for, but the decisions they make based on status report data. What we found turns conventional wisdom on its ear, so we proceed with Knocking the Stupid out of... Status Reporting! What best practices can we apply to improve the mix?

[To implement, you need to understand the five basic project dimensions and that they need to be listed in terms of their overall flexibility on each project. See future blog on "Knocking the Stupid out of... Project Dimensions: Flexibility". Scope, Time, Cost, Quality, Resources (People and other). The least flexible should drive most metrics and status. The most flexible make up most of the domain for your Corrective Actions.]

Symptoms, Problems, & Opportunities.

You want to reduce time spent compiling and discussing project status.
You want to increase performance of your projects and your people.
Your current status process does not feel efficient or effective.
Your project teams complain about status data that does not reflect true project status.
Your status reports do not suggest what should be done: corrective actions.
Your status reports are not reasonable across different and different types of projects.

What Doesn't Work & Why.

One mandatory format for all project status. It just does not work...
No mandatory process or template for status. Projects will report babel.
Missing or inconsistent application of status best practices.
Random questions from many people, all trying to come at the project from a different point of view and a 'filter' of one important project dimension.

What Can Work & How!

Use just data or extrapolations of data with Recommended Corrective Actions.
The only interesting data is that which supports specific types of project decisions.
Provide links back to base data, use footnotes and comments to foster trust.


Schedule views with milestones, to show baseline estimate, actual, estimate to complete:
Time & Scope Milestone Tracking Gantt.
Cost Money spent and planned table.
Resources Hours worked and planned table.
Quality varies by type of project, defects, rework, survey results, or other.
Project Logs to show other interesting information.
Issues Log for blocking, new, solved, and aging issues.
Risk Register for new, occuring, and expiring, risks.
Decision Log for new decisions made (can also hold pending decisions).
Defect Log (or other quality document) for quality problems.

Specific Best Practices choices to implement, we recommend one at a time...:

Format your status report into four sections:
VARIANCES in Time, Scope, Cost, Resources, Quality with a Recommendation:
Requested for more than project authority or politically sensitive.
Taken for within project authority and not overly sensitive.
DATA from your project documents above, including one or two graphics:
Schedule Tracking Gantt view if Time or Scope is less flexible.
Schedule Budget view if Cost is less flexible.
Defect Graph (or other quality data) with extrapolations.
NEW list of line items from your project documents: Deliverables, Issues, Risks.
DONE list of line items from your project documents: Deliverables, Issues, Risks.
Ask your Stakeholders what decisions they make from status reports and meetings.
Ask them what data they need to support their most important and likely decisions.
Adjust your Project Management Documents and Processes to obtain that data.
Work with your Stakeholders one on one to get their buy-in.

Methodology Choices.

Onsite PM experts take control of your Status Reporting (Fastest, most Political).
Onsite PM experts mentor your management and staff implementing best practices.
Onsite review, then periodic visits to jumpstart and mentor one at a time changes.
Onsite review then remote participation to jumpstart and mentor one at a time changes.

If you Want Help Implementing?

Contact us for help or just to talk over your situation. We are in-process with one client on updating their status best practices and have completed other similar engagements with status best practice implementations, some with focus on:

Program Status normalization to reduce redundant effort on many status reports.
Collaboration around status live in meetings using views instead of static reports.
Business Analysis, BA COE (Center of Excellence), BA Processes inclusion in status.
Agile Project Management, Business Analysis, & Software Development Status.

We would be happy to talk these topics over with you anytime!

"...teaching you to be honest and to speak the truth, so that you bring back truthful reports

to those you serve?" Proverbs 22-21 NIV.

‹ Back