Projects with strict safety requirements
Domains where mistakes are unforgiving. Releases that have to land cleanly, before and after go-live.
Services
We take on the work of carrying a project from intent to adoption — sharpening judgement and agreement before the first line of code.
Who This Is For
For organisations that need both safety and agreement.
Finance, insurance, healthcare, manufacturing, public sector, infrastructure, logistics, and the core of SaaS businesses — domains where the work cannot stop and where multiple teams must converge.
Daily operations that cannot pause
Live systems that need to keep running while change is introduced. Migration and parallel-run design that has to be carefully held together.
High demands on security and control
Audit, governance, and regulatory expectations that have to be translated into something the working teams can actually move on.
Friction between user and engineering teams
Conversations where the words don't quite match, and agreement collapses again somewhere around the requirements stage.
Strategy that won't reach the floor
Strategic intent that is clear at the top, but never quite lands as something the implementing teams can hold on to.
Primary entry points
Two ways to begin
Most engagements begin through one of two routes. The entry point depends on where the project stands — before it moves, or once early signals suggest it is already drifting.
New project
Foundation design for new projects
Before a project starts running, set the goals, requirements, stakeholders, decision structure, risks, and exit criteria. Putting the structure in place early reduces rework downstream and narrows the gap between business strategy, operations, and technology delivery.
Course correction
Course correction for troubled projects
When rework, misunderstandings, friction between departments, or stalled approvals start to surface, we step in before the situation escalates. We make the misalignments visible and help re-establish priorities and shared agreements — adjusting the structure rather than blaming the people in it.
Common contexts
Common Contexts for Consultation
These are not additional entry points. They are the consulting contexts in which the two primary entries are most often applied.
Alignment
Business and User Department Alignment
Non-IT stakeholders and actual users are included in requirements, decision-making, and adoption. Bridging the gap between what business needs and what development builds.
Decision support
Decision Support for Approvers and Project Owners
Risks, trade-offs, and options are structured into clear materials for approvers and project owners — so that the people authorising work understand what they are authorising.
Startup
Startup Structure Sparring
For founders, product leaders, and development leaders navigating business goals, product decisions, technical structure, and early organisation design — all at once. This is not a third primary entry point; it is a consulting context that usually begins through Foundation Design or Project Rebalancing.
Three Pillars
Three layers that hold a project together.
Hard, Soft, and Cultural. No single one of them is enough on its own.
Hard
Project safety
Surface gaps in requirements early. Bake security and control into the design. Build for the kind of business that cannot afford to stop.
Soft
Dialogue and agreement
Get business and engineering speaking the same language. Hold psychological safety and explainability in place while assembling agreements decision-makers can actually act on.
Cultural
Adoption and repeatability
Stay until the system is genuinely used. Reduce reliance on individuals, and leave behind a way of working that future projects can re-use.
What We Do
What we do.
We take on the work of carrying a project from intent to adoption — sharpening judgement and agreement before the first line of code.
Requirements analysis support
Structure the voice of the floor. Make assumptions and constraints explicit. Surface gaps before they become rework.
Definition and agreement support
Build requirements that business strategy, operations, and technology delivery can all hold — and leave behind agreements that don't quietly collapse later.
Mid-project adjustment
When mismatches and rework start to appear during delivery, work the points back into focus and re-establish agreement.
Cross-team communication
Reduce friction between teams. Design the meetings, organise the points, prepare the briefings decision-makers actually need.
Project safety review
For projects already in flight, review the state of safety and agreement and return concrete points to address.
Team rebuilding
After a fire, or after roles have hardened in unhelpful ways, rebuild the working relationship without losing anyone's standing.
What We Don't Do
What we won't take on.
Drawing the boundary first turns out to be where trust starts.
Selling hours as a substitute for judgement
We don't take on work that's defined purely as person-months. The focus stays on the quality of judgement and agreement.
Absorbing responsibility on someone's behalf
Decisions stay inside the organisation. Our job is to organise the material and the points so the call can actually be made.
Looking for someone to blame
We don't run projects as blame exercises. The energy goes into structures in which failure is harder.
Our company strictly prohibits, as a matter of business ethics, the presentation of exaggerated track records or the practice of portraying uncertain information as definitive facts. The fundamental principle of our communication is transparency and integrity in information.
Method
How the work moves.
Without rushing, but without stalling. Five steps.
- 01
Initial diagnosis
Listen across the structure, the people, and the points. Put what's happening into language.
- 02
Sharpening the points
Separate what has to be decided, what doesn't, and what cannot yet be decided.
- 03
Building agreement
Assemble agreements that business strategy, operations, and technology delivery can all hold — built so they don't quietly come apart.
- 04
Walking alongside
Stay close enough during delivery to support the adjustments and conversations that come up — but only as far as is useful.
- 05
Reflection and adoption
Stay until the system is genuinely used, and leave behind a way of working the organisation can re-use.
Phases
Two entry points where the work pays off most.
New projects
Before the structure sets
While requirements and assumptions are still fluid, work on foundations and guardrails — so that less has to be undone later.
Early signs of fire
Before it spreads
When rework and mismatches are starting to compound, organise the points and rebuild agreement — before the situation escalates further.
FAQ
Frequently asked.
Things that tend to come up before the first conversation.
At what stage can we bring you in?
Anywhere from early ideation through requirements, definition, delivery, launch, and adoption. The earlier the conversation, the more options remain on the table.
We already have a development partner. Is that an issue?
Not at all. In fact, much of the work happens precisely between client and vendor — staying neutral, and shaping agreements that work for both sides.
Can you help even if business users aren't yet engaged?
Yes. That's often where the work begins — designing how to bring them in without overload, on a path that feels manageable for them.
Are sessions online or in person?
Online by default. For agreement-heavy moments where presence matters, on-site sessions can be arranged.
What industries do you work with?
Primarily finance, insurance, healthcare, manufacturing, public sector, infrastructure, logistics, and core SaaS domains. Where we have less domain depth, we say so up front and contribute through structural work.
How is confidentiality handled?
All conversations are treated as confidential from the first message. Where useful, a lightweight confidentiality acknowledgement can be put in place even before contracts.
Can a startup consult, even if the main entries are project-oriented?
Yes. Startup support is a common consulting context, not a separate entrance. If the situation is a new product or new project, it begins from Foundation Design. If confusion, delay, or misalignment has already surfaced, it begins from Project Rebalancing.
Which entry point should a startup use?
Foundation Design if the work is at an early stage where structure and goals can still be set cleanly. Project Rebalancing if priorities between business, product, and development have already started to conflict. Startup Structure Sparring is a consultation style within either — not a separate route.
Tell us what you're seeing.
We can start from organising the situation. No prep deck, no internal sign-off needed beforehand. Whatever you can share is enough to begin.
Open the contact form