I would suggest not drawing too much attention to the delay in the other project reports and instead to just mention it briefly as a footnote. You can, and should, produce a detailed report documenting the delay at the project level, but when it comes to the other projects being delayed, just briefly mention in those reports that the projects are delayed due to a delay at the program level. In this scenario, where you are working on N projects to support a common end-goal, the simple solution is to produce one report that focuses on the delay of the program as a whole. One possible solution to your problem is to focus this reporting on the entire program and not treat each individual project as its own separate entity. The program manager, on the other hand, may not care about individual projects, but is concerned with the aggregate result or end-state. The project manager's job is to ensure that their project succeeds. On this second view, the point of having a program is to exploit economies of scale and to reduce coordination costs and risks. The other view is that a program is nothing more than either a large project or a set (or portfolio) of projects. Here is a quote from Wikipedia Article on Program Management: Since your are coordinating multiple projects, it sounds like you may be crossing the lines into program management. We can change our system so I am curious how other tools deal with this type of metrics. What is the best way to highlight and accurately report project delays (considering we understand what went wrong) without having this multiplied counting issue where you are penalized for just having many projects queued in the pipeline. pushed back just because of the 1 week delay in project #1. When I review all the delays, I don't think it is correct to show 10 weeks of delay (if I add up delays in all projects) because I'd be adding the same week many times as all projects were delayed for the same reason, e.g. Before you start tracking your schedule, however, you need to set a baseline so that you can compare it with your up-to-date schedule later in the project. This is a critical part of tracking your project. If I have 10 projects that are all dependent on one another and project #1 gets delayed by 1 week, all 9 other projects would then have dates slipped by a week. A well-managed project often involves comparing a project to earlier version of it.

In our system, anytime someone pushes back a release date, we force them to document a reason so we have documented every delay and every reason. We are trying to do retrospectives and look at our projects to see why they got delayed. My question is really about right metrics to report when looking at a set of projects and functionality of project management tools which help in highlighting these metrics.

Showing delays in merlin project