Independent IFS Cloud practice · Implementation
Design workshops that end in decisions: IFS Cloud fit to standard
IFS Cloud fit to standard is a way of running design workshops in which the team walks each business journey through the standard system first and classifies every departure from it on the spot. Decisions are taken once, in the room, with a named owner, so fewer gaps reach the build and the design phase stops repeating the same discussions.
Key takeaways
- "Fit to standard" is the name of my own practice, not an IFS methodology. The Implementation Docs Kit groups project work into the phases Initiate Project, Confirm Prototype, Establish Solution, Implement Solution and Go Live, and I run this workshop format in Confirm Prototype.
- The workshop starts from the system, not from a requirements list. A key user performs the journey in a demo environment and the team classifies each departure as configuration, extension, change to the core or change in ways of working.
- A workshop produces a gap list in which every line has a decision, an owner, a cost to build and keep, and a date. A line without those four items is an open issue, not a decision.
- Time per journey is limited, but a decision that cannot be taken on the day is parked with an owner and a date instead of being forced.
- Every gap closed by a change to the core is paid for again at each Release Update the company takes (IFS issues two per year), which is why the classification happens in the workshop and not in build.
A key user looks at a slide of the order-to-cash process and the consultant asks what is missing. Nobody touches the system, and after three hours the wish list is longer than it was at the start. This article describes how to prepare, run and close design workshops so that this does not happen: the preparation, the order of work in the room, the output that the build will actually use, and the ways the format fails. The scope of requirements and the vocabulary of "standard" are covered elsewhere, in Requirements before build and Standard: the false friend.
1.Why does the design phase of an IFS Cloud project drag on?
The design phase drags when workshops start from a blank page, because every departure from standard is then argued from zero and the people arguing have not yet seen the system. Key users describe how they work today, the consultant records it as a requirement, and the same topic returns two weeks later with a different owner. The decision has not been taken, only postponed to a phase where it costs more.
The Confirm Prototype phase exists to avoid this. A prototype on standard IFS Cloud is meant to be confirmed against the client's own processes, not built from nothing. The table compares the two ways of running the same workshop.
| Workshop | Starting point | Who drives | What is produced | What stays open |
|---|---|---|---|---|
| From requirements | A list of wishes per module or per department | The consultant asks, the room answers | A longer requirements list | Which items the standard already covers |
| From standard | One business journey, performed in the system with representative data | A key user at the keyboard, the consultant explains what the system does | A gap list with a classification, a decision, an owner and a cost per line | Only parked items, each with an owner and a date |
2.What has to be ready before the first workshop?
Five things have to exist before the first workshop, and a workshop held without them turns into a presentation.
- Scope by journey, not by module. The scope is a list of business journeys, such as order-to-cash or procure-to-pay, and not a list of modules. Each journey has one named person who owns the decisions for it, the whole way across the modules.
- A demo environment with representative data. Use the client's own data or a credible equivalent, so that the key user recognises customers, parts and prices. Data preparation is described in A data-first approach to IFS Cloud implementation.
- Key users who have seen the screens. A short walkthrough before the workshop means the workshop time goes on decisions and not on learning where the menu is.
- A named decision owner per journey. When the room disagrees, one person rules, and that person is known before the day.
- A parking rule. Any matter that cannot be settled on the day goes to a parking list, and a parked matter always receives an owner and a date.
3.How do you run the workshop itself?
Run the workshop by walking one journey through the standard system, with a key user performing the steps, and classify each departure when it appears. The classification uses the three doors from Requirements before build plus a change in ways of working: configuration, an upgrade-safe extension, a change to the core, or a change in how the business works. The workshop applies the definition of standard agreed in Standard: the false friend, it does not reopen it.
- Standard first. The system is shown before any change is requested. A departure is raised only after the team has seen what the standard does at that step.
- Classify on the spot. Each departure gets one of the four outcomes before the next step starts. If the outcome is a change to the core, the cost of building and keeping it is written next to it in the same session.
- A time limit per journey. The limit protects the agenda. It is not a reason to rush a decision, because an item that is not ready goes to the parking list.
- A fixed rule for disagreement. The decision owner of the journey rules, and the dissent is recorded in the gap list.
Two habits break the format. A demonstration without decisions teaches people the system and leaves the design exactly where it was. A discussion about the layout of screens consumes the time that the classification needs, and the layout can be changed later with the tools of the platform.
4.What should a workshop leave behind for the build?
A workshop leaves behind two lists that the build team will use directly: a gap list with decisions and a list of open issues with dates. A gap line is complete when it states the journey, the departure, its classification, the decision, the owner of that decision, and the cost to build it and to keep it.
The open-issue list holds everything that was parked, each with a person and a date by which it returns to the room. This article ends at the point where a decision is written down with an owner and a date. How a decision register is structured and kept alive after go-live is a separate topic. The Implementation Docs Kit holds templates for this phase, among them the Risk Register and Issue Log (IDK-04) and the CRIM Log (IDK-10).
5.Where does the shorter design phase come from, and how does the format fail?
The design phase gets shorter because three kinds of repeated work disappear, not because the workshops are rushed. Decisions are taken once and recorded, so topics stop returning. The gap list is smaller, because the standard was seen before a change was demanded. And every remaining gap arrives in the build with a classification and a cost, so nobody has to rediscover it. This article gives no percentage, because the length of a design phase depends on the scope and the organisation, and I have no source for such a figure that would withstand scrutiny.
The format fails in five recognisable ways:
- The workshop becomes a presentation. The consultant clicks, the room watches, and no departure is classified.
- The key users are absent. Their delegates cannot decide, so every journey ends with parked items and no decisions.
- The scope follows modules. The handovers between modules fall between two workshops and surface in testing.
- Gaps are listed but not priced. A gap without a cost to build and to keep reads as a must-have, and the discussion starts again in build.
- The parking list grows unattended. Parked items without an owner and a date are never decided, so the list lengthens from one workshop to the next.
6.Why does a change to the core cost more in IFS Cloud?
A change to the core of IFS Cloud costs more than it appears to in the workshop, because IFS issues two Release Updates per year and every modification reaching into the core has to be re-applied and re-tested at each one the company takes. A gap closed that way is a recurring cost for as long as it lives. The consequence is described in The IFS Cloud upgrade tax and priced in The true cost of customization in IFS Cloud.
For this reason the workshop should reach for the extension tools before it considers a change to the core: Page Designer, custom fields, custom events and the Extensibility Framework. Update-safe IFS Cloud extensions explains what each of them can and cannot do, so the workshop only needs to name which one fits a given gap.
7.How do you check your own workshop plan?
Check a workshop plan with three questions, and treat any plan that cannot answer them as not ready. First, does each session cover one business journey, and does that journey have a named decision owner? Second, will the key user perform the steps in a demo environment with representative data? Third, will every gap leave the room with a classification, a cost to build and keep, an owner and a date?
If you want an outside review of a workshop plan before the design phase starts, that is a task for a 30-minute technical call with the consultant who would carry it out.
Book a design-phase review Browse the Implementation Docs Kit
8.Frequently asked questions
What is a fit-to-standard workshop in IFS Cloud, and how is it different from a fit-gap session?
A fit-to-standard workshop is a design session in which a business journey is performed in the standard IFS Cloud system first and each departure from it is classified on the spot. A fit-gap session compares requirements with the system and lists the gaps. The difference is the starting point: the workshop begins from the system and decides on the day, while a fit-gap session begins from a requirements list. The name describes my own practice and is not an IFS methodology. I run it in the Confirm Prototype phase, one of the five phases used in the Implementation Docs Kit: Initiate Project, Confirm Prototype, Establish Solution, Implement Solution and Go Live.
Who has to be in the room, and who decides when the room disagrees?
The key user of the journey must be in the room and at the keyboard, together with the consultant and the person who owns decisions for that journey. When participants disagree, the named decision owner of the journey rules, and the dissenting view is recorded in the gap list. The decision owner is agreed before the workshop so that nobody negotiates authority during it.
How do I time-box a workshop without forcing rushed decisions?
Set a time limit per business journey and give the workshop a parking list for items that are not ready. When the time for a journey ends, every open item is either decided or parked with an owner and a date. The time limit protects the agenda, and the parking list removes the pressure to decide before the facts are available.
What do we do with a gap nobody can decide on the day?
A gap that cannot be decided on the day is moved to the open-issue list with a named owner and a date on which it returns to the room. It keeps its classification if one exists and its cost to build and keep if that can be estimated. A parked gap without an owner and a date is treated as undecided and reaches the build as a change request.
Does fit to standard mean no customization at all?
No. Fit to standard means the standard system is seen first, and any departure from it is a conscious decision with a price. Configuration and upgrade-safe extensions such as custom fields or the Extensibility Framework remain available. A change to the core is possible too, but it is decided with the cost of building and keeping it written down, because it has to be re-applied and re-tested at each Release Update the company takes (IFS issues two per year).
9.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS, today on IFS Cloud. IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. You talk to the consultant who builds it, not a sales layer.
Selected clients from my IFS work: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Design phase about to start and no plan for the workshops?
Bring your list of journeys and the workshop schedule. On a 30-minute technical call you will talk to the consultant who would run the review, and you will leave with a list of what to change before the first session.