Frequently Asked Questions

There are reliable early warning signs. The most common: timelines keep shifting without clear reasons. Scope changes are no longer formally tracked. The team avoids difficult conversations about risks. Status reports stay green while everyone involved knows the project is in trouble. If more than two of these apply, it is time for an honest assessment — not another steering committee presentation.

More than most organisations calculate. The direct costs — team, licences, infrastructure — are visible. The real damage lies in the hidden costs: delayed business processes, workarounds that become permanent, the loss of trust in IT within the organisation, and the opportunity cost of everything that cannot be started because resources are tied up. In our experience, a stalled project costs two to five times the original budget when all these factors are included.

When continuing costs more than starting over. That sounds simple, but in practice this decision is delayed because of sunk cost bias. The key question is not how much has been invested so far, but: given what we know today, would we start this project again in this form? If the answer is no, a controlled wind-down with lessons learned is more valuable than throwing good money after bad.

The most common mistake is starting with tool selection. Before any product decision, three things need to be clear: What is the business objective driving the IT change? What does the current IT landscape look like, and what dependencies exist? And how high is the organisation’s capacity for change — not technically, but culturally and organisationally? Only once these questions are answered can meaningful requirements be formulated, vendors evaluated, and a realistic timeline established.

An ERP tender is not a feature list. The most frequent problems arise not from the wrong functions, but from unclear acceptance criteria, missing change request procedures, and contracts that do not allow for a realistic handling of scope changes. What matters is that the tender reflects your actual business processes, not an idealised version of them.

The product demo is the least meaningful part of a vendor evaluation. More relevant are: reference projects in your industry and company size. The actual implementation methodology, not the one from the sales deck. The team composition planned for your project. The licence and cost model over the entire lifecycle. And the contractual flexibility regarding scope changes.

Agility is not a process you roll out. It is a way of working that must fit the organisation. The most common mistake is introducing a framework without creating the prerequisites: decision-making authority within teams, short feedback cycles with the customer, and a leadership culture that genuinely allows self-organisation. That is why we recommend starting with a manageable pilot project.

That depends on the organisation’s size, the nature of the work, and the maturity level. Scrum is well suited for teams working on a single product in fixed cycles. Kanban is the better choice for less predictable work. SAFe comes into play when multiple teams work on a shared programme. In practice, it is often a combination.

An agile fixed price combines the planning security of a fixed-price contract with the flexibility of agile development. The overall framework — budget, timeframe, team size — is set. Within this framework, scope can be prioritised and adjusted. The agile fixed price is particularly useful for projects with a clear goal but a solution path that is not yet fully defined.

Pragmatically and in small steps. The most common mistake in OKR introductions is involving the entire organisation straight away. Better: start with a single team, run through a first cycle of three months, and learn from the experience. The first OKRs will not be perfect — and that is fine.

Too many objectives at once — when everything is a priority, nothing is. Key results that describe activities instead of measurable outcomes. Missing regular check-ins. And the attempt to link OKRs with existing target agreements or bonus systems — that creates the wrong incentive.

Not necessarily. For getting started, a simple spreadsheet or a Confluence board is enough. The process matters more than the tool. As the organisation grows or multiple teams work with OKRs, spreadsheets reach their limits. For that point, we have developed the OCENOX OKR Tool — free, web-based, hosted in the EU.

The European Commission has issued an adequacy decision for New Zealand under Art. 45 GDPR, most recently confirmed in January 2024. New Zealand provides a level of data protection equivalent to European standards. Personal data can be transferred from the EU to New Zealand without additional safeguards, without Standard Contractual Clauses, and without special authorisation. The data exchange is legally treated the same as a transfer within the EU.

No. Under German law, the territoriality principle applies (§3 SGB IV): what matters is the place where the work is actually performed, not the location of the client. OCENOX is based in New Zealand, works remotely from New Zealand, bears its own entrepreneurial risk, uses its own equipment, and works for multiple clients. There is no German social insurance obligation.

The time difference between New Zealand and the DACH region is 10–12 hours. This enables a follow-the-sun model: analyses, deliverables, and documentation are produced overnight while the European team sleeps. Results are on your desk in the morning. In practice, this means up to two additional productive days per sprint — without overtime, without night shifts. For 24/7 operations scenarios such as go-live support, incident management, or migrations with tight maintenance windows, having an experienced team covering the APAC time zone is a decisive advantage over purely European setups.