Seven stages.Each one leavessomething behind.
The same structure governs a two-week review and a ten-week build. What changes is the weight given to each stage — consultancy work concentrates in stages one to four, development work in stages three to seven.
You are never asked to approve a large amount of work you have not seen. Every stage produces a document, a design or a working system you can look at and challenge before the next one starts.
Understand
Before anything else, we need to know what the organisation is trying to do and where that is currently going wrong. Not what system you want — what outcome is not happening.
- Conversations with the people doing the work, not only with those commissioning the project
- Walking through real examples end to end, including recent ones that went badly
- Establishing what “better” would actually look like, in terms somebody could measure
- Identifying the constraints that are genuinely fixed and those that are simply habitual
A written statement of the problem and the intended outcome, agreed with you before any solution is proposed. If we have misunderstood something, this is where it surfaces — at the cheapest possible moment.
Assess
What exists today, honestly examined: the systems, the data, the process and the workarounds people have built to get around all three.
- Inventory of the systems in scope, their owners, their cost and their condition
- Data quality assessment — whether the information held can be relied on
- Integration points, dependencies and the places where information is re-keyed
- Risk: unsupported software, key-person dependency, absent backups, no exit route
A findings log: what we observed, where we observed it and what follows from it. In a consultancy engagement this is a substantial deliverable in its own right. In a development engagement it determines what has to be migrated and what has to be replaced.
Define
The stage most often skipped, and the one that determines whether the result works in three years. Definitions, structures and rules written down and agreed.
- For development: the data model — entities, relationships, states and permitted transitions
- For reporting: the measure dictionary, with one agreed definition per measure
- For selection: the requirements document and the weighted evaluation criteria
- For continuity: critical services and the tolerance the business will accept
- Scope boundaries: what is explicitly not included, stated as clearly as what is
A specification document that belongs to you and outlives the engagement. If you later work with a different supplier, this is the document that saves you starting again.
Design or recommend
Development work designs the interface. Consultancy work reaches a recommendation. Both produce something reviewable before commitment.
Screen designs for the tasks performed most often, reviewed with the people who will perform them. Designed for speed of use rather than for a screenshot.
Options compared on agreed criteria, with a stated preference, the reasoning behind it, the residual risks and the conditions under which we would change our view.
Either an approved interface design or a written recommendation. In both cases the decision remains yours, and in both cases the reasoning is on paper rather than in somebody's recollection of a meeting.
Build or implement
Delivered in reviewable increments, core first. You should be testing the substance of the system well before it is finished.
- The record and the workflow built first, because they are what everything else depends on
- Regular working releases rather than a single reveal at the end
- Data migration attempted early, since it is where unpleasant surprises live
- Structured acceptance testing against the scenarios agreed at stage three
- For consultancy engagements: supporting your team as the recommendation is acted upon
A working system, tested against agreed scenarios, with a record of what was verified. Defects found during acceptance are corrected before go-live rather than logged for a later phase.
Review
After go-live, the questions change. Not “does it work?” but “is it being used, and is it producing the outcome we described at stage one?”
- A review session a few weeks after launch, once real use has revealed the friction
- Comparison against the outcome statement written at stage one
- Adoption check: which parts are being used as intended and which are being avoided
- Any defects arising in the delivered work corrected within the agreed support window
A short written review with any corrective work identified, plus an honest note of anything that has not delivered what we expected. That note matters more than the parts that went well.
Improve
Optional, and entirely at your discretion. Systems that are used generate ideas; whether you act on them with us, with someone else or not at all is your decision.
- Change requests scoped and quoted individually — no obligation, no minimum term
- Small monthly arrangements where continuous small changes suit you better
- Periodic re-review for consultancy work, particularly continuity plans
- Documentation kept current as the system changes, so handover remains possible
We do not build systems that require us. Documentation, data structures and export routes are yours from the outset, precisely so that continuing with Alvoris is a choice rather than a dependency.
The same seven stages, weighted differently.
A consultancy engagement concentrates its effort early and finishes with a document. A development engagement carries more weight through the middle and finishes with a working system.
How we conduct ourselves during an engagement.
These are not aspirations. They are the terms on which we prefer to work, and we would rather state them before an engagement than explain them during one.
- 01Scope changes are quoted, not absorbed silentlyWhere a request falls outside agreed scope we say so, explain the effort and let you decide. We do not accumulate unspoken extras and produce them at the end.
- 02Bad news travels immediatelyIf something is going to be late, or has turned out harder than expected, you hear it when we know it rather than at the next scheduled meeting.
- 03One point of contactThe person who scoped the work runs the work. You will not be handed to an account manager who was not in the original conversation.
- 04Written summaries after each stageShort, factual, and sent without being requested. A verbal update is not a record.
- 05Your data and documentation are yoursStructures documented, export routes provided, no artificial dependency on us for access to your own information.
- 06We will say when we are not the right supplierSome enquiries need a specialist we are not. Saying so early costs us a project and saves you considerably more.
Three things, and they are not negotiable.
Engagements go wrong for predictable reasons. These are the conditions that prevent most of them.