4

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.

We are trying to do retrospectives and look at our projects to see why they got delayed. 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.

Here is the issue:

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.

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. pushed back just because of the 1 week delay in project #1.

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.

We can change our system so I am curious how other tools deal with this type of metrics.

Improve this question

3 Answers 3

Reset to default
1

Was an integrated master schedule used for all of the projects? Since they were dependant upon each other, did the schedule have predecessor/successor logic both inter- and intra-projects? If so, you should be able to do your retrospective analyzing the effects of schedule delays through the critical path within the master schedule. If not, then create the schedule network diagram now using actual schedule results from the baseline schedules for each specific project and logical sequencing of packages and milestones between projects. With a bit of analysis, you should be able to calculate your finish variances without double counting. Some late tasks and packages of a predecessor project will not always affect successor packages if not on the critical path. So double counting should not occur if you focus on the critical path and ignore unfavorable finish variances on non critical path packages and milestones.

Improve this answer
2
  • thanks for your feedback. my issue is less about critical path. lets assume for simplicity that everything is on the critical path so a delay in project 1 for 1 week does push EVERY other project back a week. My issue is, looking at total slippage after the fact for every project, that i dont want to say collectively that we have had 10 weeks of delays (just because there were 10 projects). i am trying to seperate a real delays from a "dependant" delays (hopefully that makes sense)
    – leora
    Apr 28, 2011 at 12:21
  • Ok. I would still develop a single network diagram using all the packages from each of the projects and sequence them together based on both soft and hard logic. Then, I would examine both the starts and finishes of each package to try to identify when a successor package started late BECAUSE of a late finish. I cannot see another way at the moment.
    – David Espina
    Apr 28, 2011 at 12:45
1

you are being penalized for just having multiple other projects in your pipeline.

It's not "just having multiple other projects". You're penalized because one failure caused a number of subsequent failures. And someone has to be accountable for this. At least the company should know that there are 10 failures, not just one.

I would suggest to leave everything "as is" now, and continue "failing" every project individually.

Improve this answer
0

Since your are coordinating multiple projects, it sounds like you may be crossing the lines into program management. Here is a quote from Wikipedia Article on Program Management:

The other view[3] is that a program is nothing more than either a large project or a set (or portfolio) of projects. On this second view, the point of having a program is to exploit economies of scale and to reduce coordination costs and risks. The project manager's job is to ensure that their project succeeds. The program manager, on the other hand, may not care about individual projects, but is concerned with the aggregate result or end-state.

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. 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.

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. 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.