Every engagement follows the same five stages, whether it is a two-week certificate project or a year-long platform rollout across a branch network. The depth changes; the sequence does not.
Where project governance is in scope, this methodology is itself PRINCE2 Agile-informed — we apply the stage control we consult on. That is deliberate. It would be difficult to recommend a governance model we did not run our own work under.
The five stages
Assess and scope
We look at what you actually have — the estate, the current tooling, the constraints and the obligations you are working under. The output is a written scope with the unknowns identified, not hidden.
Install and configure
Deployment on your infrastructure, hardened, integrated with your directory, and configured to your process rather than left at vendor defaults.
Integrate
The connections between systems — directory, monitoring, ticketing, delivery tooling and databases — built and tested so the estate behaves as one system.
Train and hand over
Your people trained on the system as configured, with documentation, so operation does not depend on us or on one internal expert.
Support
An agreed support arrangement if you want one. Not required for the system to keep running — the software is open source and the deployment is yours.
What each stage produces
How we scale to the project
The same method covers a departmental pilot and a nationwide rollout — what changes is the control level, not the sequence. We have delivered at both ends of that range, and the most common mistake we see is a small project being governed like a large one, which produces overhead nobody sustains.
- Departmental or pilot scale — a single team or site, light control, fast cycle. Frequently how a longer relationship starts.
- Institution scale — multiple departments, integrated systems, formal change control and defined stage gates.
- Multi-site and branch network scale — distributed deployment, remote collectors, phased regional rollout and performance tuning for volume.
What we ask of you
Engagements go well when a few things are true on your side, and it is fairer to say so up front than to discover them at week three.
- A named person on your side with the authority to make decisions, not only to relay them.
- Access to the environment early enough that assessment is based on the estate rather than on a description of it.
- Honesty about existing constraints — the undocumented system, the server nobody will reboot, the process everyone routes around. We will find them anyway; finding them early is cheaper.
- Availability of the staff who will operate the system, during handover rather than after it.
After handover
You own the deployment. The software is open source, the configuration is documented, and your staff have been trained to administer it. A support agreement is available and many clients take one — but it is a service you buy because it is useful, not a dependency we engineered in.