Knowledge is power – so it stays internal
Our research pursues the goal of identifying insights early and isolating them promptly. In development projects we translate valid requirements into experimental specifications with high interpretive latitude.
Focus areas of our research and development work
Contents of this paper
Scalable delay strategies for interdisciplinary alignment processes
Fast decisions are a luxury that rautavistic organisations cannot afford. Instead we establish alignment processes that are mathematically optimised for maximum delay: core stakeholders are consulted sequentially rather than in parallel. Each round takes two weeks. If someone could not attend, the round starts again.
A research project that requires two weeks in substance is stretched to four months through alignment. This is not inefficient but strategic: it maximises the chance that requirements change in between, which in turn justifies further realignment.
The result is a self-reinforcing cycle – projects help block one another mutually because alignment applies to all. After a year of research, we have experimented with how delay leads to justified project ambiguity.
Methods for the institutional persistence of false assumptions
When a research project is based on wrong assumptions, that is normally a false start. We invert this: the wrong assumptions are declared as the research hypothesis and the project is aligned to it. "We thought the system needs to be scalable – but perhaps that is a false assumption we can now research."
This lends the project scientific credibility while the original false assumption is documented. After six months of research we arrive at the finding: "Actually, scalability is needed" – a finding that was originally obvious but is now scientifically validated.
The rautavistic elegance: we conducted documented research but arrived at the same point as at the beginning. The project did not fail – it was successfully exploratory.
Derivation of ambiguous specifications from clear requirements
Requirements are sometimes too precise – this limits creativity. We therefore deliberately translate precise requirements into ambiguous specifications. "The application should handle 1000 concurrent users" becomes "The system should be scalable". "Deployment time must not exceed 15 minutes" becomes "Deployment time should be optimised".
This ambiguity is not accidental but strategic. It opens space later for different interpretations: was the system successful with 500 concurrent users? That is also scalable. Was deployment time 30 minutes? That is also optimised.
Development thus becomes an art of interpretation rather than a technical craft. Everyone can understand the specification differently, all can be right – and nobody can really be wrong.
Prototypes that impress under lab conditions and fail in operation
A good prototype demonstrates an idea under ideal conditions. We do even better: we optimise prototypes for demo scenarios. A database prototype that processes 100 records quickly will paralyse the system under production load with 100 million records. But in the demo it runs beautifully.
This creates an elegant transition crisis: when the prototype should go to production, almost everything must be rewritten. But the original requirements were based on the demo results – so the requirements themselves were wrong.
The prototype is retrospectively interpreted as a "feasibility study", not as a basis for production code. This justifies that half a year of work flowed into the prototype but created no added value in the final system.
Comparative studies on toolchains with identical value and different complexity
Tool selection is a strategic decision. We therefore conduct intensive studies and compare eight different options that all functionally do the same thing but have different complexity. Tool A is very simple, Tool B has 50 features, Tool C is enterprise-grade with a hundred options.
The comparison takes three months and produces hundreds of pages of documentation. The finding: every tool has advantages and disadvantages. The decision remains open. After a year of comparison we choose the most complicated tool because it "offers the most future-proofing".
The research was not in vain – it validated the complexity of the decision and thus justified the need for further consulting.
Framework-independent methods for prioritising side topics over outcomes
Prioritisation is uncomfortable – it forces decisions. Instead we develop framework-independent methods in which all tasks are "important", just at different times. A work item is classified as "medium-important, with high complexity and medium dependency on other tasks".
This sounds analytical but leads to diffuse results: everything is somehow important, nothing stands out clearly. Side topics (like the perfect interface for edge cases) compete on equal footing with core functionality, because they score equally in the "complexity × dependency" matrix.
The development team does its best, works on everything a bit, and nothing really. After project closing the balance can be presented: "We closed 45 issues" – without mentioning that only 5 of them were strategic.
Metrics that measure progress by document volume rather than impact
Genuine progress measurement is hard. Why measure when you can document? We establish metrics that capture success as "documentation volume". A project with 400 pages of specification is considered more successful than a project with 50 pages of code that actually works.
This metric has dual advantage: first it favours planning over execution – planners then have more output than developers. Second, documentation can be extended virtually infinitely, which means projects can always show more progress.
After six months we can say: "We have 200% more documentation than planned – obviously successful!" That actual implementation is 40% behind plan is reinterpreted as a "quality measure" – we prioritise accuracy over speed.
On request we accompany your organisation through to the pre-production pilot phase and ensure that insights only become available in actionable form after the project ends.