The city of Denver set out in 1988 to build a new airport to replace the existing one, Stapleton Airport. Costs would be reduced, pollution and air-traffic delays would be eliminated, and growth would be assured. The new Denver International Airport (DIA) was scheduled to open on October 31, 1993. Finally, it was partially opened in 1995. What happened?

On the due date, every other part of the vast airport complex was ready to go. But the software was not ready, so the airport could not open. Specifically, what was not ready on time was the Automated Baggage Handling System (ABHS). The entire cost of delay—more than $500 million in extra financing—was attributable to the lateness of that one key element.

Denver citizens, the most important project stakeholders, were not happy with the project performance. During the year 1994 they used the acronym DIA not as Denver International Airport, but as “Delayed International Airport”.

Nowadays, we see DIA project as a failure case, but before October 1993, all reports showed the project was on track. Those project status reports were deceptive, but no auditor could verify the truth back then.

Asking for evidence in the form of deliverables or static documents is maybe sufficient at operations, but projects are dynamic by nature. No project can be properly judged with one static report of one point in time. This is even more imprecise for agile projects, where performance depends greatly on the changing perceptions of stakeholders. Using an analogy with visual arts, a single photograph could tell if an operation is healthy, but we would need many photographs, or even better, the complete movie, to have a good project heath check.

Project reports produced on demand—or to find guilty people when the project fails—are useless to control and monitor the project. They do not add any value when produced. They are just waste.

Most PPM tools provide project reports reusing features taken from ERP or Business Intelligence tools. Top managers have a feeling of control just by watching dashboards. Suddenly, bad news is noticed from other sources—not the tool—and the project manager is forced to unveil the sad truth. The project was green and the next minute is red everywhere, but it is too late to get it back on track. Just the same case than Denver Airport project.

Automatic reports do not necessary tell the specific truth on project performance, neither. The key information of project performance lives in the mind of the project manager, but they don’t have time to waste, so they tend to report by exception: only when bad things happen.

Project reporting should be routine, not drama.

If status reports are complex and costly to produce, project managers will report seldom, to avoid the pain. That means each report is bigger and therefore, even harder. This is a vicious cycle. On the other hand, if reporting is easy, project managers would report often, meaning that each report is smaller and therefore, easier. PPM tools should help project managers produce small and frequent project status reports.

In project management, however, the habit of producing project status reports is more important than reading them. If the project status is written down regularly, knowing that stakeholders will read them, then the project manager would report real issues and risks, but also preventive and corrective actions. If project managers are aware there are many vigilant eyes, then they are likely to manage better:

  • Project stakeholders should easily access any project status report for a given review date. They should be able to download reports and keep them. Project managers need stakeholders to be engaged and respond timely feedback on project performance.
  • Project managers should easily produce these reports, getting them to the point. In question of minutes, they should write why the project in general, or some specific work package is “green” regarding schedule, but “red” regarding cost, for instance. They should also say what actions are taken to get back on track. Some actions should be taken in response of comments or changes requested by stakeholders.

Small and frequent project status reports should be a source of interaction with project stakeholders. Imagine a series of small and frequent project status reports in the Denver Airport project. Chances are some important risks would have been mitigated. If the project is finally a failure, no one should be surprised.

PMPeople provides real time reports on timesheets and expenses, resource capacity, dashboards for business units, programs, portfolios, resource pools, etc. Many users can access these reports in a self-service way.

Health Check summary on each work package:

Funding performance summary for the project:

Schedule performance summary for the project:

Cost performance summary for the project:

Project Team performance summary:

PMPeople enhances project reporting, making quite easy for project managers to produce project status reports, and for stakeholders to consume them.

PMPeople is the tool for the project economy. It is aimed to unify professional project management by these differential points:

  • Designed by and for professional project managers, following professional project management standards.
  • Online productivity –less meetings, less documents, less workflows– through distributed collaboration among 12 specialized roles: Organization Owner, 6 roles on demand management and 5 roles on supply management.
  • Freemium product –unlimited time, unlimited users, only managers have to pay– usable via web and mobile application.

Start using PMPeople for free, for unlimited time and for any number of users. In premium organizations, only managers have to pay. Several roles –stakeholders, team members, sponsors and resource managers– are always free. You can increase or decrease your premium seats according to the organization actual needs. Premium organizations have access to our interactive support through Slack. Our servers are located in EU. This software can also be hosted on customer premises.