Development and Implementation in Ivalua
Ivalua projects follow their own rules. This article shows why pure Scrum logic and agile software development reach their limits here, what specific characteristics the platform brings with it, and how a hybrid project approach can still lead to rapid and sustainable results.
Characteristics of development in Ivalua
Not every project environment is equally suitable for purely agile frameworks—at least not without targeted adaptation. This becomes particularly evident when implementing platform solutions like Ivalua. Even though agile principles have their place and are used, project reality differs in several fundamental ways from that of a typical incrementally developed software product.
Short planning cycles (sprints) and iterative development are also commonly at the core of Ivalua projects. The overarching goal is to quickly, transparently, and adaptively generate value with close involvement of the relevant stakeholders. In some aspects, however, Ivalua projects require a special approach.
Agile or classic project management?
Configuration Instead of Development – The System-Inherent Framework
The key difference lies in the nature of the product. While agile software projects focus on greenfield development—with full control over architecture, code base, and releases—Ivalua projects operate within a highly standardized, predefined system architecture. Project work consists primarily of configuring existing functionalities, modeling workflows, and adjusting UI components using the platform’s built-in tools.
The focus is “Configure, not Code.” For example, the Page Design module allows forms, sections, and fields to be configured via drag & drop. Visibility, mandatory fields, and validations can be controlled through rule-based logic directly in the graphical user interface (GUI). No individual frontend coding is required. A visual workflow editor simplifies the configuration of approval and business processes through states, conditions, transitions, and tasks. Permissions such as field access, tab visibility, or action buttons are configured via profiles, roles, and visibility rules, all manageable without coding. In short: A comprehensive SaaS product is configured and parameterized—but not developed.
This constraint is not necessarily negative—it enables scalability, governance, and security-by-design. However, it brings methodological challenges: Many requirements can only be implemented within narrow technical boundaries. Traditional development paths—such as extending the system through individual microservices—are generally unavailable or require significant effort.
Functional Fragmentation – Progress Without Usability?
In agile development projects, each sprint ideally produces a runnable, tested feature that delivers immediate value. Ivalua projects look different:
Configuration progress—such as a new data structure, a rule, or a workflow segment—is often not yet usable on its own. Releases tend to be organized around use-case bundles or end-to-end scenarios. Full functionality only emerges from the interaction of multiple components.
This leads to a decoupling of progress and perceived value, which must be addressed in stakeholder management. A transparent communication strategy is required to present project progress clearly, without creating the expectation that every iteration will deliver a fully productive result.
Agility in the Tension Field of Conservative Process Logic
Another critical difference lies in the composition and expectations of stakeholders. While agile software projects are often IT-driven, Ivalua implementations are shaped primarily by procurement, finance, and compliance functions. These business areas typically operate in process-oriented, highly standardized, and regulatory environments.
Agility in this context means less radical change and more controlled adaptation. Methodological elements such as backlog prioritization, sprint demos, or iterative feedback cycles remain valuable—but they must be translated into formats understandable to these stakeholders and embedded into the platform’s system logic.
Best Practices:
Because Ivalua’s implementation approach makes purely agile execution difficult, jupitos—as a specialized implementation partner—focuses on a hybrid, practice-oriented project approach that respects system constraints while ensuring strong business alignment.
1. Ivalua Demands Hybrid Methods – With Agile Team Structures
The Ivalua implementation approach is based on a fixed project model (Design – Build – Validate – Deploy), which should not simply be replaced with classic Scrum logic. Projects are typically implemented in phases or “waves,” such as supplier master data, sourcing, contracts, invoices. This requires clear roadmaps that align business priorities with system dependencies, ensuring that these dependencies and value contributions build cleanly on one another. The challenge lies in combining this structural framework with agile elements without losing control or increasing complexity.
From the start, jupitos establishes a hybrid project model: We connect disciplined phase management with agile work practices such as daily check-ins, review cycles, and iterative configuration units. We define clear rollout roadmaps early on that reflect both business relevance and technological dependencies. This creates a project dynamic that is both predictable and adaptable.
In many Ivalua projects, there is no dedicated product owner with clear decision-making authority. Instead, role blending is common. A configurator may also act as analyst, tester, and project manager. In matrix-based project teams with limited agile training, the classic Scrum ideal is hardly achievable in practice.
At jupitos, we bring full methodological expertise—and apply agility in a way that works in the Ivalua context: with adjusted role models, structured backlog management, regular reviews, and clear iteration logic. Not dogmatic, but disciplined enough to provide guidance.
2. Business Areas Demand Individualization Instead of Standardization
Many business units tend to replicate existing processes 1:1 in Ivalua. However, this quickly leads to over-configured, maintenance-heavy solutions and weakens scalability. It also contradicts the platform principle, which is designed for reusability and standards.
Even before the project starts, jupitos conducts intensive preparation phases with the goal of providing a preconfigured system that already covers the expected scope as much as possible. This allows us to work with customers from the very beginning in a tailored environment. In our pre-kickoff bootcamps, we make the system tangible, validate it jointly with the customer where possible, and derive the necessary gaps.
Instead of immediate customization, we begin with a solid gap analysis—aiming to individualize only where it brings real value. This prevents scope creep and ensures long-term maintainability. Whether industry, retail, or financial services—we understand their specific requirements and know what can be transferred.
3. Workshops Without Output – Too Far From the System
Too often, requirements workshops drift into theory without system reference or tangible results. This leads to misunderstandings, inflated expectations, and a lack of commitment.
At jupitos, workshops are always system-centric—conducted in a preconfigured environment tailored to the customer. We arrive prepared, show specific solution proposals through system demos, and make the product immediately tangible. This generates acceptance and direct feedback.
4. No-/Low-Code Instead of Greenfield Development
A configurable no-/low-code platform does not automatically make Ivalua implementations easier. It introduces new challenges. Technical implementation moves closer to the business side, which often lacks the methodological or structural skills to efficiently connect configuration, rule logic, UI design, and testability. Without clear responsibilities, tight coordination, and methodological discipline, chaos rather than progress can emerge.
jupitos does not view no-/low-code as a simplification, but as a shift in responsibility—and manages this shift accordingly. We bring experienced configuration specialists who align business logic and system behavior. At the same time, we foster collaborative work with the business side, e.g., through targeted reviews and structured test management. Our project methodology prioritizes scope clarity, testability, and user acceptance.
5. Data Dependency & ERP Interfaces – The Critical Path
One of the biggest risks to project success lies outside of Ivalua: fragmented ERP landscapes, bad master data, and missing interface concepts not only delay go-live but can also jeopardize it structurally.
From the beginning, jupitos integrates a Data Readiness Assessment. Together with ERP and data owners on the customer side, we analyze data quality, mappings, integration logics, and gaps. Early collaboration with IT teams ensures that Ivalua can run on a stable foundation.
6. IT and Business With Different Target Pictures
In many projects, IT and business teams are not aligned. One side thinks in system constraints, the other in process chains. Without active alignment, the project risks being torn between technical limitations and business wish lists.
We actively moderate between both worlds—through modular reviews and deliberate involvement of key users from all areas. Collaborative testing, joint story validation, and close communication create a true shared project understanding.
7. Growing Complexity in Change Management
Ivalua is powerful but not self-explanatory. User adoption plays a decisive role in project success. Our previous blog article describes the six central factors for successful change management: stakeholder analysis, change analysis, communication, multipliers, continuous improvement, and training & support.
jupitos acknowledges the importance of change management for Ivalua projects and collaborates with specialized change partners who professionally handle communication, stakeholder engagement, and adoption.
Conclusion: Complexity and Pragmatism
Implementing Ivalua is not a purely agile software project—and this is precisely where the complexity lies. The platform approach, the no-/low-code paradigm, the fixed phase structure, and the strong proximity to regulated business areas such as procurement, finance, and compliance require a methodological approach that fits neither perfectly into known Scrum structures nor into purely waterfall models. Functional fragmentation, blurred roles, technical dependencies, and cultural differences between IT and business are part of project reality.
jupitos addresses these challenges with a proven hybrid approach that combines agile principles with structured implementation logic. We work system-centrically, use preconfigured best practices, prioritize standardization over individualization, and involve business units and IT from the very beginning. Our strength lies in guiding complex projects in a pragmatic, transparent, and collaborative way—focused on business value, user acceptance, and long-term scalability. To successfully implement Ivalua, you don’t need a dogmatic framework—you need a partner who masters both: the platform and the project methodology.