Change Management

How we handle changes during development – and why they are not a problem if the process is right.

Changes are Normal

Software doesn't emerge in a vacuum. It appears in contact with reality. And reality changes – during development just as much as afterwards. New insights from daily operations. A process that turns out to be more complex than expected. A better idea that only arises while working with the system. A shifting market.

Two Models, Two Approaches

How flexibly we can manage changes depends on how we collaborate. Depending on the project, we work with one of the following two models:

Retainer – Ongoing Collaboration

In the retainer model, we work with a fixed monthly allocation of developer days. There is no rigid requirement specification and no formal change request process. Instead, we prioritize together in short cycles: What has the greatest impact right now? Changes naturally flow into ongoing work. New insights, changed requirements, better ideas – everything is taken into account in the next iteration. Without bureaucracy, without addendum negotiations.

The retainer model is particularly suitable for:

• Long-term system development and continuous enhancement
• Projects where requirements are specified over time
• Companies wishing to continuously develop their operating system

Requirement Specification – Defined Project Scope

In some projects, a clearly defined scope is useful. In this case, we work with a requirement specification: a documented scope on which we develop, calculate, and deliver. This works well – as long as nothing changes. However, once a change is needed, our change request process kicks in:

---

How the Change Request Process Works

When we work with a requirement specification and a change to the agreed scope becomes necessary, it proceeds as follows:

1. Report Change

You report the desired change – whether it's a new requirement, changed logic, or additional feature. This can be done informally via email or in the shared project channel. Your point of contact for changes is our project manager.

2. Assessment

We evaluate the change: What does it mean for the architecture? How much effort does it involve? Does it impact the timeline? Are there dependencies with other components?

3. Proposal

You receive a transparent estimation: estimated effort in man-days, impact on the timeline, and – if relevant – on other parts of the system.

4. Decision

You decide: Implement, postpone, or discard. Only after your approval does implementation begin. No hidden costs, no surprises.

---

What Changes Cost

Changes aren’t free – that would be unrealistic. But they should be transparent. Therefore, our principle is:

How You Minimize Changes

Changes can never be completely avoided. But they can be significantly reduced – through good preparatory work:

• The system audit makes the difference. The more thoroughly we understand your company before development, the fewer surprises arise during it. Interviews with all relevant stakeholders – from management to operational key users – reveal requirements that would otherwise only become visible months later. The system audit report provides a solid current analysis, a clear architecture, and a concrete implementation roadmap. This is the best insurance against addendums.
• Short development cycles help. We don't develop for months in isolation and then present the results. We deliver in short iterations, gather feedback, and correct the course early. This drastically reduces the likelihood of major changes.
• Honest communication saves money. If something changes in your company – a new process, a new client, a new priority – let us know early. The sooner we know about it, the cheaper the adjustment.

---

Summary

---

Relevant Documents: