Delivery Approach Guide
Knowledge Guides /How do you freeze a project baseline and track the impact of requirement changes?
Last updated: · New Horizon Digital Outsourcing Team
Freezing a baseline establishes mutually agreed inputs and artifacts at a given time; it does not prohibit further changes. Subsequent changes should explain their reasons, affected items, and acceptance implications before forming a new version, so parties do not discuss the same issue using different files.
A baseline includes more than code
- Record requirements, models, data, interfaces, deployment configurations, and tool versions. Preserve explicit references and access conditions for external dependencies that cannot be archived. A filename containing final does not replace version management or establish that its contents have been confirmed.
What should a change request explain?
- List the original content, proposed content, reason, and desired timing. Check impacts on interfaces, performance, licensing, and completed evidence. Small edits may trigger extensive retesting, so effort cannot be estimated solely from the number of lines changed.
Review before implementation
- An authorized decision-maker should accept, defer, or reject the change and record corresponding scope and plan adjustments. After implementation, link modified artifacts to verification results. Do not make temporary fixes in the demonstration environment and forget to update the delivery baseline.
Check consistency during acceptance
- Ensure the demonstration, packaged files, source code, and documentation belong to the same baseline. Randomly trace a change from request to verification. Retain the accepted version after delivery; new development must not overwrite it and make earlier results irreproducible.