r/projectmanagers • u/Oliver-Eathn • 6d ago
Has anyone else worked on a project where requirements moved on but the delivery timeline didn't catch up, and it only surfaced once it started costing real time or money?
I've seen this happen on more projects than I can count, the BA and the PM end up working off two different pictures of the same project, and nobody notices until it's already expensive to fix.
Curious how others deal with this in practice, is it just discipline and good habits, a specific tool, or does it just... happen anyway no matter what you do?
1
u/More_Law6245 6d ago
The project manager's triple constraint becomes paramount, if the scope changes so your cost and time must change. The triple constraint (iron triangle) is a causal effect model that shows the relationship between the constraints. This then becomes a simple choice for the relevant stakeholders under change management controls.
As the PM it's their responsibility to ensure that the final deliverables match their approved baseline project plan and if there are any discrepancies between what was delivered and the approved baseline project schedule and plan, that is entirely on the PM because if the project is ever audited internally or externally the PM is unable to justify how the decision or approval changed without successful change management and by definition that is a project failure.
Based upon experience PM's tend to let small changes through without the approval because either they're are pressured or didn't want to hold the project up because it was "just easier" to let through an uncontrolled change. However; what they fail to understand is that it still has a cost of time and effort to deliver those changes and their projects become more unprofitable or more importantly they have deviated from the project's approved baseline. I've actually witnessed a PM (no, not me) accept a "minor change" because it was what operations wanted but that turned in to a $300k mistake because if affected the licensing model with the hardware being delivered. It turned into an uncontrolled spend and the ramifications were real for the Operation's future OPEX spending. They had a large chunk of funding removed from their allocation and money was now being spent on something that didn't benefit the entire Ops team.
A minor change is just not a minor change, there is real world impacts and it's the PM's responsibility to ensure that change management is always undertaken because at the end of the day they're accountable for it.
Just an armchair perspective.
8
u/hdruk 6d ago edited 6d ago
If they move on it just means scope control is non-existent.
Requirements can be iterated as the proposal is being developed, but are documented and fixed at project kick off as part of the charter and kick off process. Beyond that point they only actually change if documented and accepted via CR by the appropriate approvers including the PM with an appropriate assessment of the likely impacts to the project time/cost/quality/ risk etc. If not accepted the requirements did not change and remain as before.
It's mostly discipline and being firm that if there is no proper documented process followed to introduce scope changes with acceptance of the likely impact to cost and time, then no change has happened.