Template IDK-02, version 1.0. Phase: Initiate Project.

How to use this template

Write it during Initiate Project, in parallel with the Project Management Plan (IDK-01). The plan says how the project is run. This document says what it delivers.
The supplier project manager drafts it from the contract and the sales-phase material. The customer project manager and the process owners correct it until they recognise their business in it.
Replace every [bracketed field]. Delete rows marked Example: once you have your own.
It is done when the steering group has signed it and every in-scope line has an acceptance criterion and an accepting role. A scope line without an acceptance criterion is an argument waiting to happen.
It is confirmed a second time at the Solution Confirmed gate, after the prototype. Changes in between go through change control (IDK-07).

Template metadata
Field	Value
Template ID	IDK-02
Phase	Initiate Project
Owner	Supplier project manager (with customer project manager support)
Approver	Steering group
Qualification gate	Project Initiated
Version	1.0

Document control

Version	Date	Author	Change	Approved by
0.1	[YYYY-MM-DD]	[name, role]	First draft from contract and statement of work
1.0	[YYYY-MM-DD]	[name, role]	Baseline for gate Project Initiated	[steering group chair]
[n.n]	[YYYY-MM-DD]	[name, role]	Confirmed after prototype, gate Solution Confirmed	[steering group chair]

1. Purpose and background

Item	Content
Why the business runs this project	[two or three sentences in business language, not system language]
What triggered it now	[for example: legacy system end of support, acquisition, growth constraint]
Link to corporate goals	[which goal, and how this project serves it]
Contract or statement of work	[reference, date]
What this document supersedes	[sales presentations, proposal appendices, earlier scope lists]

2. Objectives and measurable benefits

Each benefit has one owner in the business, a measure, and a date by which it is expected. The executive sponsor is accountable for benefit realisation. Progress is reviewed at each steering group meeting.

ID	Objective	Benefit and how it is measured	Baseline today	Target	Expected by	Benefit owner
Example: B-01	One purchasing process across all sites	Share of purchase order lines raised from an approved requisition, read from a lobby element on purchase order data	[measure today]	[agree in project]	[YYYY-MM-DD]	Head of procurement
Example: B-02	Trustworthy stock records	Count accuracy by location, from counting results in the system	[measure today]	[agree in project]	[YYYY-MM-DD]	Warehouse manager
[ID]	[objective]	[benefit and measure]	[baseline]	[target]	[YYYY-MM-DD]	[role, name]

Objectives that are not measurable are listed here as intentions, with no owner commitment:

[intention]

3. Software scope

Item	In scope
Product and release	IFS Cloud, release [release] at project start
Deployment option	[hosted by IFS / remote deployment at customer]
Components and modules licensed	[list from contract]
Components licensed but not implemented in this project	[list, with reason]
User types and counts	[from contract; do not restate figures here, reference the contract clause]
Languages	Application: [languages]. Documentation and handover: English plus [language].
Localisations and country extensions	[list]
Mobile and device use	[for example: warehouse handhelds, maintenance mobile app]
Third-party products in the solution	[product, purpose, who contracts it]
Update approach	Service updates and release updates: [cadence agreed in project]; first update after go-live planned for [period]

4. Solution scope by process area

The process model in [IFS Scope Tool or agreed repository] holds the detail. This table is the signed summary. One row per end-to-end process.

Process area	End-to-end process	Sites and companies	Process owner (customer)	Standard functionality expected	Known CRIM need
Example: Procurement	Purchase requisition to supplier invoice match	[sites]	Head of procurement	Yes. Authorisation rules configured per company.	One integration: order data to transport planning through a standard projection
Example: Inventory	Receipt, putaway, movement, counting, adjustment	[sites]	Warehouse manager	Yes	One configuration: custom field for internal hazard class on the part record, visible in receipt
Example: Security	Roles and permission sets for all in-scope processes	All	Customer IT lead with process owners	Yes. Functional roles built from end-user permission sets, segregation of duties reviewed by finance.	None
[area]	[process]	[sites]	[role, name]	[yes / partly / no, with note]	[CRIM reference or none]

4.1 Data scope

Data set	Source	In scope	History migrated	Method	Customer owner
Example: Suppliers and supplier addresses	Legacy ERP	Active suppliers only; definition of active: [agree in project]	None	Data Migration Manager	Procurement data steward
Example: Inventory balances	Legacy ERP, final count	All in-scope sites	Opening balance only	Data Migration Manager	Warehouse manager
[data set]	[source]	[rule]	[depth, agree in project]	[migration tool / copy and paste / manual entry]	[role]

4.2 Interface scope

Every legacy and new interface is listed, including the ones that will be retired. The full interface register is built before the build starts.

ID	From	To	Data flowing	Direction	Status in the new solution
Example: INT-03	IFS Cloud	Transport planning system	Confirmed purchase order lines, delivery address, wanted receipt date	Outbound	New, replaces file export from legacy
[ID]	[system]	[system]	[data]	[in/out/both]	[new / kept / retired]

5. Out of scope

Writing down what is excluded prevents more disputes than writing down what is included. Each line states the reason and where the need goes instead.

Item	Reason	Where it is handled instead
Example: Migration of closed purchase orders	No operational use after go-live; legal retention met by legacy archive	Read-only legacy archive owned by customer IT
Example: Organisational change management activities	Customer responsibility	Customer change lead, plan reference [reference]
Example: Sites [site list]	Later roll-out	Separate project, not budgeted here
[item]	[reason]	[owner or follow-on project]

6. Acceptance criteria

6.1 Acceptance of the product delivery

The product is what the customer will operate: configured IFS Cloud, CRIM objects, migrated data, roles and permission sets.

#	Criterion	How it is proven	Accepting role
1	Every in-scope process meets the agreed requirement	Solution Acceptance Test scripts passed, results logged in the test tracker	Process owners
2	The solution works with the physical operation	Test steps executed in the real warehouse, shop floor or office setting, with devices and printers	Process owners
3	The built solution, including CRIM, is complete and has no operation-critical error	Defect list with classification; none open that block deployment	Customer PM
4	Migrated data is fit for purpose	Functional validation sign-off per data set after the final load iteration	Data owners
5	Roles match business roles	Test executed with end-user logins and their permission sets, not with administrator access	Customer IT lead and process owners
6	Step-by-step guides are accurate	Guides followed during acceptance test without consultant correction	Functional leads
[n]	[criterion]	[proof]	[role]

Defect classes that block acceptance: [definition agreed in project]. Defects that may close after the phase: agreed individually and listed with owner and date.

6.2 Acceptance of the project delivery

The project delivery is the work: phases completed, deliverables handed over, people enabled.

#	Criterion	How it is proven	Accepting role
1	Each qualification gate passed	Gate decision record signed by the steering group (IDK-08)	Steering group
2	Agreed supplier documents delivered	Document list in IDK-01 section 10 ticked, latest versions in the repository	Customer PM
3	Core team and expert users can operate and support the solution	Operational Readiness Test completed by expert users, with the core team only advising	Executive sponsor
4	Handover to support executed	Handover document complete, CRIM specifications and test specifications in latest version, handover meeting held and recorded	Both PMs and support lead
5	Residual issues owned	Closure document lists each residual issue with owner and date	Steering group
[n]	[criterion]	[proof]	[role]

7. Work breakdown and responsibilities

One row per work package. R is the party doing the work, S the party supporting it.

Work package	Phase	Main deliverable	Customer	Supplier
Project initiation and planning	Initiate Project	Approved plan, scope statement, controls	S	R
Operating model workshops	Confirm Prototype	Book of Rules documents approved by customer	R (decisions and content)	R (facilitation and documentation)
Prototype build and demonstration	Confirm Prototype	Approved prototype on customer sample data	S	R
Data cleansing	From Confirm Prototype	Cleansed source data per data set	R	S
Data mapping and load iterations	Establish Solution	Validated migration jobs	R (extract, validate)	R (mapping, load support)
Solution workshops and configuration	Establish Solution	Configured processes, revised Book of Rules	R (decisions, testing)	R (configuration)
Roles and permission sets	Establish Solution	Functional roles built and tested	R	S
CRIM specification and build	Establish Solution	Approved specifications, delivered and tested objects	R (approve, test)	R (specify, build, unit test)
Step-by-step guides and training material	Establish Solution	Final guides and course material	R	S
Solution Acceptance Test	Establish Solution	Documented and approved test result	R	S
Expert user and end-user training	Implement Solution	Trained users attached to roles	R	S
Operational Readiness Test	Implement Solution	Documented and approved test result	R	S
Cutover planning and rehearsal	Implement Solution	Tested cutover plan, checklist and rollback plan	R (business tasks)	R (technical tasks, plan ownership: [agree in project])
Cutover and go-live support	Go Live	Solution in operation	R	R
Handover to support and closure	Go Live	Handover document, project evaluation, closure document	S	R
[work package]	[phase]	[deliverable]	[R/S]	[R/S]

8. Milestones

Dates are held in the schedule baseline (IDK-01 section 3). Listed here so that scope and milestones are signed together.

Milestone	Phase	Baseline date
Gate: Project Initiated	Initiate Project	[YYYY-MM-DD]
Kick-off held	Confirm Prototype	[YYYY-MM-DD]
Prototype approved. Gate: Solution Confirmed	Confirm Prototype	[YYYY-MM-DD]
Solution Acceptance Test approved. Gate: Solution Established	Establish Solution	[YYYY-MM-DD]
Cutover rehearsal completed	Implement Solution	[YYYY-MM-DD]
Operational Readiness Test approved. Gate: Go Live Authorised	Implement Solution	[YYYY-MM-DD]
Go-live	Go Live	[YYYY-MM-DD]
Gate: Go Live Complete	Go Live	[YYYY-MM-DD]

9. Constraints and dependencies

Type	Description	Owner
Example: Dependency	Transport planning system supplier must deliver its side of INT-03 before integration testing	Customer IT lead
Example: Constraint	Go-live must fall on a financial period boundary and outside the seasonal peak	Finance director
[type]	[description]	[role]

Approval

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]	______________________
[name]	Process owner, [area]	[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

Project Scope Statement Template (IDK-02)