Change Impact Analyzer

What the analyzer measures

A change is rarely just the work of building it. Accepting one reopens work already finished, obliges the team to re-prove things that were working, pulls in other teams and systems, and costs time in re-planning and agreement. The analyzer takes the one estimate you can give confidently, the effort to implement the change, and adds each of those consequences explicitly so the total is visible rather than discovered later.

The inputs, and what each one is for

Five answers produce the complete delivery assessment. Everything else is optional and adds a section rather than changing the core arithmetic.

• Current project effort: the total delivery effort the project is planned at today. The change is measured against this, which is what makes scope growth meaningful.
• Current project stage: where delivery has reached. This decides how much completed work the change reopens.
• Core effort for the change: building it, and nothing else. Do not add testing, coordination or contingency here; the analyzer adds them.
• Regression and testing breadth: how much of what already works has to be re-proved.
• Dependency impact: how far the change reaches into other teams, integrations and external systems.
• Capacity available for this change: effective hours a week. Without it the analysis returns effort and scope but no schedule impact, because there is no honest way to turn hours into days.
• Current target date, optional: supply one and the analysis returns an adjusted forecast date.

How incremental effort is built

Each factor is applied to the core change effort, never to a running total, so no adjustment silently compounds another. Coordination is then charged on the work being coordinated, and contingency on the whole pre-contingency impact.

• Lifecycle rework = core change effort multiplied by the rework factor for the current stage.
• Regression and testing = core change effort multiplied by the factor for the selected breadth.
• Dependencies = core change effort multiplied by the factor for the selected dependency impact.
• Coordination = the change, rework, regression and dependency effort together, multiplied by the coordination overhead.
• Contingency = the pre-contingency incremental effort multiplied by the contingency percentage.
• Total incremental effort = all of the above, added once.

Why the stage matters so much

A change accepted while requirements are still being agreed reopens almost nothing, because little downstream of the requirement exists yet. The same change accepted during release preparation reopens the design, the build, the tests and the release evidence behind it. That is why the rework factor climbs with the lifecycle rather than staying flat, and it is usually the single largest reason a late change costs more than the team expected.

Scope growth and schedule impact

Scope growth is the total incremental effort against the current project baseline, expressed as a percentage. Schedule impact divides that effort by the capacity genuinely available each week and expresses the result in working days, rounded up, because a part day still moves a date. Where a target date is supplied, the adjusted date is produced by adding working days, not calendar days.

The working calendar

Working days are Monday to Friday. Public holidays are not applied, so a date falling in a holiday period will move further than the analysis shows. This is stated rather than defaulted to one country's calendar, because inventing somebody else's public holidays would be inventing a fact about their project.

Commercial impact, when you ask for it

Commercial analysis is optional and adds sections rather than changing the delivery answer. The incremental effort is priced at a blended delivery cost per hour, either the rate you state or one derived from your own forecast cost and project effort. Gross margin is always against revenue and never a markup on cost.

• Fixed price, absorbed: revenue is held flat and the incremental cost lands on margin. The analysis reports margin before and after, and the erosion in percentage points.
• Formal change request: the analysis calculates the additional revenue that would hold your target gross margin, as incremental cost divided by one minus that margin, and separately the value that would preserve the margin the project already makes.
• Time and materials, billable: the change is priced at your bill rate and the analysis reports the revenue, gross profit and gross margin on the change itself.

How the impact level is decided

Scope growth sets the band, because it is the one measure that means the same thing on every project: below 5% is Low, 5% to 10% is Moderate, 10% to 20% is High, and 20% or more is Material. Schedule and margin impact then escalate that band and can never lower it: a schedule impact of 10 working days or more, or margin erosion of 5 percentage points or more, each raise the band by one step. A change that is small in percentage but costs two weeks and five points of margin is not a small change.

The suggested review level

Each band maps to one suggested review: standard team review, formal change review, sponsor or management review, or formal governance and change control. It exists so two changes of the same size on the same project are routed the same way rather than by instinct. It is a suggestion produced by this model and nothing more.

Adjusting the model

Every factor is visible beside the result and adjustable under Advanced assumptions. The shipped percentages are KnownShift's starting position, not measured constants and not industry standards. If you know how your own delivery behaves, set them; the whole analysis recalculates and the report records that the model was adjusted.

Reproducibility, and what produces the answer

The analyzer is a deterministic model. No generative model, no language model and no external service is involved at any point: the same inputs and the same model version always produce the same result, on any machine, at any time. That is what makes it safe to attach the report to a change request, because anybody who has the analysis can reproduce the figures and challenge the assumptions that produced them. Every analysis records the model version it was assessed under, so a result saved months ago can still be read against the model that actually applied to it.

How to read and interpret the result responsibly

Treat the total as a structured estimate whose assumptions are on the table, not as a number to defend. The most useful thing the analyzer tells you is usually the split: how much of the impact is building the change, and how much is everything the change drags with it. That split is the argument to have with whoever asked for it.