Approach · Principles
Delivery principles.
The commitments we use when speed, cost, scope and quality pull against each other.
Principles that settle arguments.
Every engagement has moments where speed, cost, scope and quality pull against each other. These are the commitments we use to decide.
Principles are only useful if they are specific enough to guide a decision. “Quality matters” does not tell a delivery group what to do when a deadline is at risk. “We do not release a critical workflow without a tested failure path” does.
The six principles below are the ones we apply most often. They are not slogans, and they are not always comfortable. Following them sometimes means slowing down, changing a plan or declining work.
01 / Architecture is a decision, not a diagram
Architecture exists to make the important choices visible: what owns the data, where the boundaries are, how the system fails, what can change independently and what cannot. A diagram that cannot answer those questions is decoration.
We produce architecture artefacts that are used during delivery and reviewed after it. If a decision changes, the record changes with it. The goal is a shared, current understanding of how the system works, not a perfect document.
02 / Every system has an owner
A system without an owner accumulates ambiguity. Someone must be accountable for the business rules, someone for the technical operation, and someone for the data. We make those roles explicit at the start of the engagement.
Ownership is the obligation to make a decision when one is required and to accept the consequence, not the same as doing all the work. When ownership is unclear, decisions default to the loudest voice or the longest delay.
03 / Delivery is proven in increments
Large promises are easy to make and difficult to verify. We prefer a sequence of smaller, demonstrable outcomes that show whether the architecture and the assumptions are working.
An increment is a coherent capability with acceptance criteria, tests and documentation, not a partial screen. The client can see it, use it and decide whether the next increment should proceed as planned.
04 / Documentation is part of the product
Documentation is how a system survives a change of staff, supplier or technology. It includes architecture records, interfaces, operating procedures, known limitations and the reasoning behind significant decisions.
We write documentation for the person who will maintain the system, not for the person who already knows it. That standard is harder to meet, but it keeps the system maintainable after delivery.
05 / Security is designed, not tested in
Security begins with the threat model, the data map and the access model. It continues through secure coding, dependency management, environment separation and release control.
Testing is necessary but not sufficient. A penetration test can find a vulnerability; it cannot create a secure design. We treat security as an engineering discipline with evidence, ownership and a response path.
06 / The handover is the measure
An engagement is complete when the organisation can operate, support and change the system without the original author in the room, not when the last invoice is issued.
That means runbooks, monitoring, access procedures, known issues, a support path and a real knowledge-transfer process. It also means being honest about what remains fragile and what should be improved next.
What happens when principles conflict.
Principles do not eliminate trade-offs. They make the trade-off explicit and reviewable.
Deadline versus quality
If a deadline threatens a critical control, we reduce scope rather than remove the control. The decision and its consequence are recorded, not absorbed silently.
Speed versus architecture
We look for the smallest architectural decision that prevents irreversible rework. Some decisions can wait; data ownership and security boundaries usually cannot.
Client preference versus evidence
We present the evidence and the trade-off. The client owns the decision; we own the responsibility to make the consequence clear.
Reuse versus fit
Reuse is valuable when it genuinely fits. We do not force a process into a template to avoid a design conversation.
How a principle becomes a decision.
Consider a request to add a new integration two weeks before go-live. The principle “security is designed, not tested in” does not automatically mean no. It means the integration must have an owner, a contract, an authentication model and a failure path before it is enabled.
If those conditions cannot be met, the options are to delay the integration, reduce its scope or accept a documented risk with the client’s decision owner. The principle gives the conversation a structure and prevents the risk from disappearing into a delivery status report.
That is the standard we apply. The aim is to make the important trade-offs visible while there is still time to act, not to be rigid.
A principle in practice: scope.
Scope is where principles are most often tested. A stakeholder asks for one more integration, a date is fixed before the design is complete, or a “small” change is treated as if it has no effect on testing or support. The principle “scope is visible” requires a response, not a shrug.
We write the change down, estimate its effect and present the trade-off: extend the date, reduce another item, or accept the risk with a named owner. The decision can go any of those ways; what matters is that it is made explicitly and recorded.
That discipline is how the organisation avoids discovering at the end of a project that the scope grew without anyone deciding to grow it, not bureaucracy. A visible scope is the basis for a trustworthy relationship, even when the answer is uncomfortable.
Want a delivery partner with explicit principles?
Tell us where the tension is. We will show you how we would resolve it.