Change Request and Change Control Procedure Template (IDK-07)

Template IDK-07, version 1.0. Phase: All phases.

How to use this template

Part A (the procedure) is agreed once, during Initiate Project, and referenced from the Project Management Plan (IDK-01 section 6.4). Remind the whole team of it at the kick-off and at the start of every phase.
Part B (the form) is copied for each change. The person who wants the change fills in sections B1 to B3. The project managers complete B4 and B5. The deciding body completes B6.
Part C (the log) is kept by the project managers for the life of the project.
Replace every [bracketed field]. Delete content marked Example: once you have your own.
A change request is done when it carries a decision, a date and a name, and when the affected baselines, the Book of Rules and the plan have been updated. Until then, no work on the change is performed.

Template metadata
Field	Value
Template ID	IDK-07
Phase	All phases
Owner	Customer project manager and supplier project manager (joint)
Approver	Steering group
Qualification gate	Project Initiated (procedure approved); applied until Go Live Complete
Version	1.0

Document control

Version	Date	Author	Change	Approved by
0.1	[YYYY-MM-DD]	[name, role]	Procedure drafted
1.0	[YYYY-MM-DD]	[name, role]	Procedure approved for gate Project Initiated	[steering group chair]

A1. What counts as a change

A change is anything that alters an approved baseline: solution scope, project scope, schedule or cost. In practice:

Counts as a change	Does not count as a change
A new process, site, company, data set or interface	Choosing between standard configuration options inside an in-scope process
Any new or altered CRIM object: configuration, report, integration, modification	Correcting a defect against an approved specification
More migrated history, or more load cycles, than agreed	Re-sequencing tasks inside a phase with no milestone affected
A document the supplier was not contracted to write	Clarifying wording in a document without changing its meaning
Moving a gate or the go-live date
Removing something from scope

If the two project managers disagree on whether something is a change, it is treated as one and written down. The written form usually settles the question.

Design principle applied to every request: can the need be met with standard functionality, or by changing how the business works? Only when that has been examined and recorded does a CRIM object become an option. Each tailored object adds work at every service update and release update.

A2. The five-step ladder

A request climbs only as far as it needs to. Each step either resolves it, rejects it, or passes it up with a written recommendation.

Step	Who	What they do	Output	Target turnaround
1	Functional team	Describes the problem, lists the alternatives with advantages and disadvantages, proposes a solution	Form sections B1 to B3	[agree in project]
2	Solution architect and technical solution manager	Review the alternatives for fit with the whole solution and for update impact; may propose a standard way and close the request	Architect's review in B4	[agree in project]
3	Both project managers	Assess impact on scope, schedule, cost and quality; obtain estimate and commercial terms; approve within their authority or recommend upward	Completed B4 and B5	[agree in project]
4	Executive sponsor	Agrees that the request is worth the steering group's time, or sends it back	Sponsor's agreement in B6	[agree in project]
5	Steering group	Authorises or rejects	Decision record B6, minuted	Next meeting, or written procedure if urgent

A3. Decision authority

Type of change	Decided by
No effect on any baseline (clarification)	Both PMs, recorded in the log
Configuration or report within the CRIM allowance, no milestone moved	[Customer PM / both PMs, agree in project]
Any integration or modification	Steering group
Any change to go-live date, gate dates, budget, or solution scope	Steering group
Use of contingency	Executive sponsor

Thresholds for cost and schedule effect: [agree in project].

A4. Rules

No work starts on a change before its decision is recorded. This includes "quick" configurations made during a workshop.
A scope change that needs extra supplier work is confirmed as a written change to the statement of work before the work continues.
For integrations and modifications, a functional specification approved by the customer and a commercial agreement both precede development. For configurations and reports, a specification approved by the customer PM precedes build.
The effort to assess a large request is itself agreed beforehand: [who pays for estimation, agree in project].
Rejected and withdrawn requests stay in the log with the reason. They will be asked again.
After approval, the PMs update the baselines, the plan, the Book of Rules and the process model, and tell the people affected.
Open change requests are a standing item in the weekly project team meeting and in the steering group pack.

CR ID: CR-[nnn] Title: [short title] Date raised: [YYYY-MM-DD] Phase: [phase] Raised by: [name, role] Functional team / workstream: [team] Process owner: [name] Priority: [must have before go-live / wanted before go-live / can wait until after go-live]

B1. Description

Item	Content
What is requested	Example: A custom field "internal hazard class" on the part record, shown on the receipt page and included in the putaway report
Process area and process	Example: Inventory; receipt and putaway
Sites, companies, users affected	[list]
Baseline item it changes	[scope statement section, CRIM ID, milestone, document list entry]

B2. Reason

Item	Content
Business problem, in business terms	Example: Warehouse staff must segregate certain chemicals at putaway; the classification used today exists only in the legacy system
What happens if the change is not made	[consequence, who is affected, how often]
Legal, safety or audit requirement	[yes/no, reference]
Link to a project benefit (IDK-02)	[benefit ID or none]
Why this was not in the original scope	[reason; useful for the lessons learned]

B3. Alternatives considered

Always include a standard-functionality alternative and a change-the-process alternative.

#	Alternative	Advantages	Disadvantages	Type (standard / C / R / I / M / process change)
Example: 1	Use a standard classification available on the part record (to be confirmed by the application consultant), mapped from the legacy classes	No tailoring; carried through updates without extra work	Legacy classes do not map one to one; data cleansing needed	Standard
Example: 2	Custom field on the part record, display only	Quick to build in the web client; familiar values for users	Not used by system logic; one more object to check at each update; duplicate of a standard concept	C
Example: 3	Keep the classification on a printed list at the receipt dock	No system work	Manual, error prone, not auditable	Process change
[n]	[alternative]	[pros]	[cons]	[type]

Proposed solution (functional team): [alternative number and reasoning]

B4. Impact assessment

Completed by the project managers with the solution architect and technical solution manager. "None" is a valid answer; an empty cell is not.

Area	Impact	Assessed by
Solution scope	[processes added, changed, removed]	Solution architect
Project scope	[work packages, documents, responsibilities affected]	Both PMs
Schedule	[tasks added, milestones or gates affected, new forecast dates]	Both PMs
Cost	[supplier services, customer time, licences, third parties; one-off and recurring]	Both PMs
Quality and risk	[new risks, effect on acceptance criteria, risk register reference]	Both PMs
CRIM	[new or changed objects by type; specification needed; effect on service updates and release updates; who maintains it after go-live]	Technical solution manager
Data	[new fields to migrate, cleansing, mapping, extra load cycle]	Data migration lead
Integrations	[interface register entries affected; third parties to involve]	Technical analyst, integrations
Security	[roles and permission sets to change; segregation of duties]	Technical analyst, security
Training	[courses, step-by-step guides and material to change; users to retrain]	Training lead
Testing	[scripts to add or change; cycles to repeat; regression scope]	Test lead
Cutover and support	[cutover tasks, handover documentation]	Both PMs

Architect's review: [fit with overall solution; standard alternative confirmed as examined: yes/no; comment]

B5. Estimate and commercial terms

Item	Value
Supplier effort and price	[estimate, basis, validity]
Customer effort	[estimate, who]
Funding source	[CRIM allowance / contingency / additional budget]
Statement of work amendment needed	[yes/no, reference]
PM recommendation	[approve / reject / defer until after go-live], with reason

PM	Name	Date	Signature
Customer project manager	[name]	[YYYY-MM-DD]	______________________
Supplier project manager	[name]	[YYYY-MM-DD]	______________________

B6. Decision record

Item	Content
Sponsor agrees to table at steering group	[yes/no], [name], [YYYY-MM-DD]
Decision	[approved / approved with conditions / rejected / deferred to after go-live / withdrawn]
Alternative approved	[number from B3]
Conditions	[conditions with owner and date]
Reason, in one or two sentences	[reason; written for someone reading the log a year from now]
Decided by	[body or role], [meeting no. or written procedure], [YYYY-MM-DD]
Communicated to	[who was told, by whom, when]

Follow-up after approval:

Update	Done	By	Date
Schedule, cost, scope baselines re-versioned	[yes/no]	[name]	[YYYY-MM-DD]
Master implementation plan and workshop plan	[yes/no]	[name]	[YYYY-MM-DD]
Book of Rules and process model	[yes/no]	[name]	[YYYY-MM-DD]
CRIM log and interface register	[yes/no]	[name]	[YYYY-MM-DD]
Test scripts, training material, step-by-step guides	[yes/no]	[name]	[YYYY-MM-DD]
Risk register	[yes/no]	[name]	[YYYY-MM-DD]

CR ID	Title	Raised	Raised by	Type	Step reached (1 to 5)	Status	Decision date	Cost effect	Schedule effect	Baseline version after change	Owner of implementation
Example: CR-012	Internal hazard class at receipt	[YYYY-MM-DD]	Functional team lead, inventory	Standard (alternative 1 chosen)	2	Closed at architect review, no baseline change	[YYYY-MM-DD]	None	None	Unchanged	Data migration lead (mapping)
Example: CR-015	Outbound order status messages to transport planning system	[YYYY-MM-DD]	Technical analyst, integrations	I	5	Approved with conditions	[YYYY-MM-DD]	[amount]	[effect]	[n.n]	Technical solution manager
[ID]	[title]	[YYYY-MM-DD]	[name]	[type]	[step]	[status]	[YYYY-MM-DD]	[effect]	[effect]	[version]	[name]

Summary for the steering group pack:

Status	Count	Cumulative cost effect	Cumulative schedule effect
Open	[n]
Approved	[n]	[amount]	[effect]
Rejected or withdrawn	[n]
Deferred to after go-live	[n]

Approval

Procedure (Part A):

Name	Role	Date	Signature
[name]	Executive sponsor (customer)	[YYYY-MM-DD]	______________________
[name]	Sponsor (supplier)	[YYYY-MM-DD]	______________________
[name]	Customer project manager	[YYYY-MM-DD]	______________________
[name]	Supplier project manager	[YYYY-MM-DD]	______________________

Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

Marketplace