---
title: "Project Scope Statement Template (IDK-02)"
date: 2026-09-21
description: "Ready-to-use template IDK-02: Project Scope Statement for IFS Cloud implementation projects, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Project Scope Statement Template (IDK-02)

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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan)). 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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)).

 | 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 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and background](#1-purpose-and-background)
- [2. Objectives and measurable benefits](#2-objectives-and-measurable-benefits)
- [3. Software scope](#3-software-scope)
- [4. Solution scope by process area](#4-solution-scope-by-process-area)
- [5. Out of scope](#5-out-of-scope)
- [6. Acceptance criteria](#6-acceptance-criteria)
- [7. Work breakdown and responsibilities](#7-work-breakdown-and-responsibilities)
- [8. Milestones](#8-milestones)
- [9. Constraints and dependencies](#9-constraints-and-dependencies)
- [Approval](#approval)

 ## 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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/08-qualification-gate-checklists)) | Steering group |
| 2 | Agreed supplier documents delivered | Document list in [IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) 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](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) 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.

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