Use case · Change-impact analysis
A revised standard or specification does not announce what it invalidates. Change-impact analysis names every deliverable, finding and approval that now depends on a clause that has moved.
The problem
A client issues a revised standard. Everyone reads the change, agrees it is minor, and moves on. What nobody establishes is which of the four hundred deliverables already in the project relied on the clause that moved.
So the reach is estimated by whoever knows the project best. They are usually close, and the gap between close and complete is where the rework lives.
Tracing a clause to everything that depends on it means opening every document that might reference it. On a live project that is a week nobody has.
So it gets scoped by judgement, and the deliverables nobody thought of stay quiet until inspection.
Reach
Because every deliverable was checked against a named clause at a named revision, the dependency already exists as a record. Asking what a change touches becomes a question of reading it back.
Nothing here is a guess about the project. It is the link that was written when each finding was raised.
Owner materials standard, rev 4 → rev 5
Sour-service qualification clause amendedIllustrative. The two figures in magenta need a decision rather than a list.
The part people miss
Most change handling looks forward at what still has to be produced. The harder question points backwards, at work that is already signed.
Each one was judged against the clause in force at the time, by an engineer who read it properly and signed with good reason. Nothing about that was wrong.
The clause they were measured against no longer reads the same way. Some remain valid and some do not, and until someone establishes which is which, the project is carrying an unknown it has no record of.
Where this is today
Every finding already records the clause and the revision it was judged against. That record is what makes the question answerable later, and it accumulates from the first run.
Including which revision of the standard was in force at the time.
So a revision is an event on a known object rather than a new file.
Every approval carries who made it and on what basis.
Reading those links back to list what a revised clause now puts in question.
Related
The record that makes this answerable is built by the everyday work.
FAQ
It is the question of what a revision puts in question. When a standard or specification changes, it lists the deliverables, findings and approvals that were judged against the wording that has moved, so the reach of a change is established rather than estimated.
It is in development. The record it depends on is being written today, because every finding already stores the clause and the revision it was judged against.
Because the answer comes from links made at review time. A deliverable checked outside the platform has no recorded dependency, so a change cannot be traced to it.
Yes, and that is the part most processes leave out. An approval was given against a clause at a revision; if that clause moves, the approval is worth re-examining even though it was correct when it was made.
A standard held at workspace level is used by more than one project, so a revision to it is a question for all of them rather than only the project that noticed.
Run the reviews. Every finding raised from here on carries its clause and revision, and that accumulated record is exactly what the analysis reads back.
Next step
Change-impact analysis can only reach as far back as your review history goes, which makes the first run the most valuable one.