What happens when an IT project changes during delivery?
When an IT project changes during delivery, the proposed change is assessed for its effect on scope, cost, timescales, resources, dependencies and risk before work is authorised. The project plan and documentation are then updated, responsibilities confirmed and the relevant stakeholders informed so delivery can continue against an agreed baseline.
An IT project change during delivery is a controlled alteration to the agreed solution, method or deliverables after implementation work has begun. It may be necessary because of a newly identified technical constraint, a change in business priorities, updated compliance requirements, supplier limitations or information discovered during testing. The change should be handled through a defined decision process rather than introduced informally.
Changes are first recorded and clarified. A request should describe what is being proposed, why it is needed, who has raised it and what problem it is intended to solve. Vague requests such as “make the system more flexible” are difficult to evaluate. A useful request explains the required capability, the users affected and the point in the project at which the change has become necessary.
The project manager or nominated change owner then checks whether the request is genuinely within the existing project. Some requests are clarifications of agreed requirements and can be addressed without formal change control. Others add functionality, alter a technical design or introduce new work. Treating every adjustment as an informal instruction creates uncertainty about what the project is expected to deliver and makes later disputes more likely.
Changes are commonly grouped by their significance. A minor change may be managed within the existing delivery arrangements if it does not alter the approved objectives or require additional authority. A material change may need review by a project sponsor, steering group or other designated decision-maker. A change that affects the fundamental business case may be better treated as a separate project or a new phase rather than added to the work already under way.
Before a decision is made, the request should be examined from several practical perspectives:
- Business need: whether the change addresses a genuine operational requirement or simply reflects a preference that emerged after work started.
- Technical design: whether existing architecture, integrations, security controls or data structures can support it.
- Operational effect: whether processes, user roles, training, support arrangements or governance need to change.
- Delivery capacity: whether the required skills, equipment, licences, supplier input or internal decisions are available.
- Quality and security: whether the revised solution introduces new testing requirements, access concerns, vulnerabilities or compliance implications.
- Commercial terms: whether contracts, statements of work, purchase orders or supplier responsibilities need to be amended.
The outcome of this review should be documented in a change record. This normally includes the request, analysis, recommendation, decision, approval authority and any conditions attached to acceptance. Keeping a clear record matters even when a request is declined or postponed. It provides an audit trail and prevents the same issue from being reconsidered repeatedly without the relevant information.
A decision should be made against agreed criteria. The authorised decision-maker may approve the change, reject it, defer it, or request further investigation. Approval should not mean that the delivery team simply starts work. It should confirm what has changed, which previous assumptions no longer apply and what the team is now expected to deliver. If the change is deferred, it should be assigned an owner and a point at which it will be reviewed.
Once a change is approved, the delivery team updates the relevant project controls. This may include the requirements specification, solution design, implementation plan, work breakdown, test plan, acceptance criteria, budget record, risk and issue logs, supplier instructions and operational documentation. Version control is important: team members need to know which documents represent the current approved position.
Dependencies deserve particular attention. A change to an identity system, for example, may affect user provisioning, application access, security testing and support procedures. A change to a network design may alter equipment requirements, configuration work and implementation sequencing. Mapping these relationships helps the team identify work that must happen before the amended element can be completed.
Communication should be proportionate but specific. People affected by the change need to understand what is different, why the decision was made, what action is required from them and whether any previous guidance is superseded. This can include internal users, technical teams, suppliers, senior sponsors and operational support staff. A project meeting alone may not be sufficient if the change affects formal procedures or contractual responsibilities.
The revised work should then pass through the appropriate assurance activities. Depending on the nature of the change, this may include design review, security assessment, configuration review, user acceptance testing, data validation or a controlled pilot. Acceptance criteria should be updated so that the project is assessed against the revised requirements rather than an obsolete version of the solution.
If the change cannot be delivered safely within the project’s constraints, the correct response may be to pause a work package, remove another requirement, create a separate phase or stop the project for a formal review. Continuing with an unapproved compromise can leave an organisation with an incomplete solution, undocumented technical debt or an implementation that users cannot support effectively.
After implementation, the project should record whether the change achieved its intended purpose and whether it created any follow-on actions. This information can inform the handover, support model and lessons learned. A well-managed change therefore becomes part of the project’s controlled evolution, while an undocumented change becomes a source of uncertainty that can continue into live operation.
For a small or medium-sized organisation without a dedicated project office, an IT project management consultant can provide the structure for recording requests, involving the right decision-makers and maintaining a reliable record of the approved solution. S2 Technology Group supports businesses around Stourbridge and neighbouring areas with IT project planning and technology guidance where changing requirements need to be managed in a controlled way.
When an IT project changes during delivery, progress should be reported against both the approved baseline and the revised forecast. The baseline shows what was originally agreed, while the forecast shows the likely outcome after an authorised change. Keeping these views separate makes it clear whether a difference is an approved adjustment or an uncontrolled departure from the plan.
Project reporting should identify the change reference, its approval status, the affected deliverables and any revised completion assumptions. This is particularly useful when several workstreams depend on one another, because stakeholders can see which dates and outputs remain valid and which have moved. It also gives sponsors a reliable basis for deciding whether further changes can be accommodated without weakening the project’s intended outcome.
