I believe it's now 10 years since Spider Project started computing critical path drag in CPM schedules and 5 years since it introduced the computation functionality on its resource critical path schedules.
It's also approaching 3 years since Asta Powerproject started computing CPM drag.
So why does Primavera still not compute this literally critical metric which tells planners how much time each activity or constraint on the critical path is adding to the project duration? And how are Primavera planners expected to do an adequate job of compressing schedules without the metric? I mean, it's possible to compute it "manually", but it's quite time-consuming. And every change requires new computations. Is it possible that Primavera planners are simply not bothering to compress/recover schedules and so are getting worse results than users of Spider and Powerproject?
In case some Primavera users still aren't aware of drag, here are a couple of articles that explain what it is, why it's so valuable, and suggest the reason for such a simple and obvious metric being omitted from scheduling theory for so many decades:
The Drag Efficient: The Missing Quantification of Time on the Critical Path [1]
2016: The Year of the Drag [2]
I feel sure Primavera planners are as conscientious as users of other software. They should push Oracle to modernize the software, or switch to a software package that does comprehensive critical path analysis.
Fraternally in project management,
Steve the Bajan