PRINCE2 Agile is not a product we install. It is the method we work to — a management framework for directing and controlling projects, combined with agile delivery for the work inside each stage. It has a section of its own because it is a different kind of thing from the systems on this site: not something deployed on your servers, but the discipline that decides what gets built, who authorised it, and how you prove it afterwards.
Readiness assessment
A structured review of how your organisation currently governs projects, measured against PRINCE2 Agile principles — and a clear statement of what would need to change.
The assessment looks at where formal governance (business case, stage boundaries, tolerances, defined roles) needs to coexist with iterative delivery (sprints, backlogs, incremental release). Most organisations have too much of one and not enough of the other, and cannot see which from the inside.
- Current-state review. How projects are actually initiated, controlled and closed today — observed, not as described in the procedure manual.
- Gap analysis. Current practice measured against PRINCE2 Agile principles, themes and processes.
- Risk findings. Where the absence of governance is creating exposure, and where excess governance is creating cost without control.
- Tailoring recommendation. Which elements should apply to your organisation at your size and risk profile — and, importantly, which should not.
- Roadmap. A prioritised sequence of changes with effort and dependency, so improvement is planned rather than attempted all at once.
Governance and tailoring workshops
Facilitated workshops that apply PRINCE2’s tailoring principle: adapting the method’s themes, processes and controls to your actual size, complexity, risk profile and culture — rather than imposing the manual wholesale.
This is where most PRINCE2 adoptions succeed or fail. Applied by the book to an organisation it does not fit, the method becomes overhead people route around. Tailored properly, it becomes the smallest set of controls that gives you genuine oversight.
- Tailoring workshops. Facilitated sessions with your delivery, PMO and sponsor communities working through each theme and process.
- Project scaling model. Different control levels for different project sizes, so a small change is not governed like a programme.
- Role definition. Project board, executive, senior user and supplier roles mapped to real people and real decision authority in your organisation.
- Management product set. Which documents you will actually produce, in what form, and who reads them.
- Tolerance framework. Time, cost, scope and risk tolerances by project tier, and the escalation path when they are breached.
Process and tool tailoring
This is the service that distinguishes us, and the one most consultancies cannot offer: we translate governance decisions into actual configuration in the systems your teams use every day.
Most PRINCE2 consultancies never touch the tooling. Most tool installers never touch governance. The result is familiar — a tailoring document in a shared drive, and a project tool running vendor defaults that contradict it. Governance that is not visible in the daily tool is not governance; it is paperwork produced at reporting time.
- Management product mapping. Project Brief, Business Case, Highlight Reports and Stage Plans mapped to custom fields, epics and reporting views in the delivery tool.
- Stage boundary workflow. Workflow states configured to reflect stage boundaries and tolerance checkpoints, rather than a generic board.
- Tolerance visibility. Reporting views that surface tolerance status without a project manager having to assemble it manually.
- Service desk alignment. Ticket categories, SLAs and escalation paths configured to match your governance and escalation structure.
- Risk and issue alignment. Defect and issue severity and priority workflows aligned to the risk and issue management theme.
Training and coaching
Training and coaching for project managers, product owners and team leads — delivered on your premises, using your tailored method and your configured tooling as the teaching material.
Generic certification training teaches the manual. This teaches your organisation’s actual method, which is what people will be asked to follow on Monday. The intent is explicitly to reduce your dependence on external consultants over time, which is a message that tends to land well with organisations that value self-sufficiency.
- PRINCE2 Agile foundations. The principles, themes and processes, taught in plain language rather than exam vocabulary.
- Organisation-specific training. Your tailored method, your templates, your tolerances — as they will actually be applied.
- Tool-based coaching. Training conducted in your configured platform, so the method and the tool are learned as one thing.
- Role-specific sessions. Separate tracks for project managers, product owners, team members and board members.
- Ongoing coaching. Support through the first governed projects, where questions actually arise.
The part most consultancies leave out
Most PRINCE2 consultancies never touch the tooling. Most tool installers never touch governance. The predictable result is a tailoring document in a shared drive and a project tool running vendor defaults that contradict it. Governance that is not visible in the daily tool is not governance — it is paperwork produced at reporting time.
Because we do both, the tailoring decisions made in a workshop on Tuesday can be configuration in your delivery platform by Friday. That is the connective service, and it is why the method has a section of its own here rather than being sold as a document.
Two names, one umbrella
PRINCE2 and PRINCE2 Agile are not two products to choose between. PRINCE2 is the governance method — direction, stages, business case, tolerances, the decision about whether work should continue. PRINCE2 Agile is that same method with an agile way of delivering the work inside each stage. Neither is a system we install; both sit above the platforms on this site and decide how they are used.
Business justification, stage boundaries, roles, tolerances and exception reporting. Applies to every project, whether or not delivery is agile — a data-centre migration or a database cutover is governed the same way.
Sprints, backlogs, fixed time and cost with flexible scope, and the agile behaviours the method expects. Used where the work suits iterative delivery; left out where it does not.
Tuleap, Leantime, MantisBT and GLPI carry the stages, products and records; Zabbix feeds them. Governance decisions become configuration here, which is what makes them real.
That is what “umbrella” means in practice: the method is applied over whichever platform an engagement uses, whenever a piece of work is a project rather than a service. Choosing between our four platforms shows the mapping onto each one — stages, management products and roles.
The method we work to
IPTREK holds PRINCE2 certification, and applies the method as a practitioner rather than teaching it as a syllabus. What we bring is the experience of running the framework against real IT delivery — infrastructure projects, platform migrations, database cutovers — and knowing which parts of it earn their keep on an engagement of your size and which do not.
PRINCE2 and ITIL: two method families, not one
Two established frameworks shape how a well-run IT department operates, and they answer different questions.
| PRINCE2 Agile | ITIL | |
|---|---|---|
| What it governs | Projects — work with a beginning, an end and a defined product. | Services — work that continues indefinitely and is measured by availability. |
| The question it answers | Should this be authorised, is it still viable, and who decided? | Was this request handled correctly, and what was affected? |
| Where it lives | Stage boundaries, business cases, product descriptions, tolerance and exception reporting. | Incident, request, problem and change records, the service catalogue and the CMDB. |
| How we realise it | Explicitly — assessed, tailored in workshops, then configured into your delivery platform. | Implicitly — through GLPI, whose ticketing, change control and CMDB are already shaped along ITIL lines. |
The two are complements. A change approved at a PRINCE2 stage boundary becomes an ITIL change record when it reaches production — the join most organisations leave open, and one of the first things we configure.