Delivery method
A delivery system, not a set of ceremonies
Every engagement runs the same six phases and produces the same artefacts. You always know which phase you are in, what it produces, and what it costs. This page is the whole method — it is not a summary of something we keep to ourselves.
The six phases
From first conversation to continuous improvement
-
Qualify
Confirm the problem, the decision-makers, and whether this is worth doing at all.
-
Discover
Interviews, process maps, users, risks, and a prioritized backlog you own.
-
Shape
Architecture, UX flows, MVP scope, and a release plan with an honest estimate.
-
Deliver
Short iterations, working software every one, risk and scope tracked openly.
-
Launch
Production readiness, testing, training, and rehearsed deployment and rollback.
-
Improve
Measure the outcome, prioritize on evidence, and keep making it better.
Each phase, in detail
Qualify
Before anyone quotes anything, we establish whether this is worth doing.
- Confirm the business problem and what it currently costs
- Identify who decides and who is affected
- Understand the urgency and what is driving it
- Verify technical and commercial fit
- Decide honestly whether to pursue, refer elsewhere, or decline
We decline work fairly regularly. Usually because the decision-makers are not engaged, because certainty is expected that cannot reasonably exist, or because someone else is a better fit. Saying so early is cheaper for both of us.
Discover
Paid, fixed fee, and the single highest-value phase.
- Interviews and workshops with the people who live the process
- Current-state process mapping
- Users, outcomes and success measures
- Assumptions and risks made explicit
- A prioritized product backlog
You own everything discovery produces, whether or not you continue with us.
Shape
Turning understanding into a plan someone can commit to.
- Architecture direction and the decisions behind it
- User experience flows where interaction matters
- MVP scope, including an explicit list of what is out
- Release plan and estimate with stated assumptions
- Governance, security, quality and deployment expectations
Deliver
Short iterations, with working software you can see every one.
- Demonstrations of running software, not status percentages
- Risk, budget, scope and decisions tracked in the open
- Automated testing and deployment as part of finishing work
- Change control when scope moves, so surprises are commercial rather than personal
Launch
- Production environment prepared and verified
- Acceptance, load and security testing proportional to the system
- User and administrator training
- Deployment and rollback plans, both rehearsed
- Adoption and incident monitoring from day one
Improve
Launch is when the most useful information starts arriving.
- Measure the business outcomes that justified the work
- Prioritize new capability on evidence rather than enthusiasm
- Reduce operational noise and support burden
- Continue as managed support or ongoing product development
Artefacts
What every significant project produces
These exist so that the project survives people changing jobs — including ours.
Project charter
What we are doing, why, and what success looks like.
Stakeholder map
Who decides, who is affected, who must be consulted.
Product vision and success measures
The outcomes the work is accountable to.
Prioritized backlog
Maintained with you, not for you.
Architecture decision records
What we decided, what we rejected, and what would make us revisit it.
System context and deployment diagrams
What talks to what, and where it runs.
Risk register
Named, owned and reviewed — not a document written once.
Decision log
So nobody relitigates a settled question six months later.
Release plan
What ships when, and what has to be true first.
Quality and test strategy
Proportional to risk rather than uniform.
Security requirements
Explicit, testable, and agreed early.
Operational runbook
How to run it, and what to do at three in the morning.
Quality
The standards we hold ourselves to
Applied proportionally. A system handling money gets more of this than an internal reporting tool, and deciding which is which is part of the job.
- Code review for every material change
- Automated unit and integration tests proportional to risk
- Repeatable builds and automated deployment pipelines
- Separated environments with no manual production changes
- Logging, metrics and tracing that someone actually looks at
- Dependency and vulnerability review on a schedule
- Backup and recovery planning, with the restore tested
- Performance testing for the workflows that matter
- Secure secrets management — never in configuration files
- Documentation sufficient for someone else to take over
Agile, specifically
What we mean, and what we do not
Agile here means a disciplined system for shipping small increments and learning from them. It does not mean a calendar full of ceremonies, and it is not an excuse for an absent plan.
Concretely: we plan around business outcomes and small releases, maintain a prioritized backlog, demonstrate working software every iteration, include quality and deployment work in the definition of done, and track decisions and risks openly.
And one commitment that matters more than the rest: we will not promise a fixed scope, a fixed date and a fixed cost simultaneously when uncertainty is high. Two of the three, honestly, with the third managed in the open. Anyone offering all three is managing you rather than the risk, and the correction arrives later as change requests.
What we ask of you
Our side works when yours does
- A named product owner who can make decisions
- Access to the people who actually do the work being changed
- Attendance at iteration demonstrations — they are where course corrections happen cheaply
- Timely decisions on the questions we raise
- Honesty about constraints, including political ones
- Test data and environment access when the work needs it
When these are missing, projects do not fail dramatically. They just get slower and more expensive in ways that are hard to attribute afterwards.
A note on this website
We build business applications in C#, .NET and Blazor. This site is plain HTML, CSS and JavaScript, generated at build time and served as static files.
That is deliberate, and it is the same judgement we would apply to your system. A marketing site is a content-delivery problem: it needs to be found by search engines, load instantly on a phone on mobile data, and stay cheap to run. A client-rendered application framework would have made all three worse in exchange for capabilities this site does not need.
Choosing the simplest thing that safely does the job — rather than the most impressive thing available — is the habit we are actually selling.