A process that runs across five departments, three systems that contradict each other, and a wish list that grows with every meeting. That is what a complex challenge looks like in practice. The temptation is to meet it with an equally complex answer: one system that does everything. Our experience since 2001 points the other way. The best solution is almost always simpler than the challenge suggested.
That simplicity does not come from a clever idea at the right moment. It comes from a way of working: ordering, weighing up, and having the nerve to leave things out.
Untangle the question before you develop
Anyone who comes to us with a software question has usually already discussed it extensively in-house. There is a list of wishes, built from your own experience and from what you have seen elsewhere. That list is valuable, but it is not a design yet. Wishes that sound simple sometimes turn out to be hard to build; wishes that look complicated are sometimes surprisingly quick to make. So we do not start with building, we start with ordering: what purpose does each wish serve, who will use it every day, and what happens if it is dropped? Once the question behind the question is on the table, much of the complexity disappears.
Complexity often sits between systems, not inside them
Remarkably often, the core of a complex challenge is not inside a system but in the space between systems. Data gets retyped from one package into another, reports contradict each other, and staff fill in by hand what the systems leave out. The challenge then feels like “we need new software”, when the simple answer is an integration that lets the existing systems work together. We wrote earlier about what goes wrong when systems do not talk to each other; here the same logic runs in reverse: a good integration can replace a web of manual work.
Making something feasible means making choices
Building everything within a fixed budget rarely works, and it does not need to. What does need to be clear is what each choice costs and what it delivers. You cannot make that call alone as a client: it requires judging what something costs to build, and that is exactly our trade. Ahead of a project, we set out for each part what it takes, what it delivers, and whether it can be simpler without losing the goal. Questions that come up along the way:
- Which part of the challenge is demonstrably costing your organisation time or money right now?
- What needs to work from day one, and what can wait for a later phase?
- Which existing systems stay in place, and what does the solution need to connect to?
- Where does a simpler version do the job while staying close to what you actually want?
The result is a functional design with a timeline and a budget: a blueprint that means the same thing to the client and the development team. Only then do we start developing.
New insight along the way is part of the process
Once the first screens start working, new ideas tend to surface. That is not a sign of poor preparation, it is a sign things are going well: only once an application takes shape can a client see the whole. Meanwhile, we keep watch over the scope and weigh every new insight against the bigger picture. Sometimes a change is worth the extra budget, sometimes it fits better in a later phase. As long as that conversation stays open, there are no surprises, and without surprises a large project stays manageable too.
Not sure whether your challenge calls for new software or better cooperation between the systems you already have? Put it to us. You can read how we approach data integrations on the service page; in a first conversation, we untangle where the complexity in your organisation comes from.