Choosing Between Our Four Platforms

We deploy four open-source platforms for managing work. They are not four competing project-management products — they answer four different questions, and most clients need one or two of them rather than all four.

This page sets out what each one is for, how they compare, why we selected these four specifically, and how each maps onto PRINCE2 governance. If you would rather start from your problem than from a product name, the four cards below are the fastest route.

What are you trying to manage?

That question is the whole sales conversation. Four products, four distinct problems — which is a great deal clearer than four platforms competing for the same buyer.

The portfolio at a glance

The fourth column matters as much as the second. A product recommended without a stated limit is a product being oversold.

Very little overlap — and a clear upgrade path

The reason this set works as a portfolio rather than a catalogue is that the products barely compete. GLPI is almost entirely orthogonal to the other three: it manages the estate, not the work. Among the three that do manage work, the difference is the weight of process each one carries.

Two natural progressions follow from that, and both are worth knowing before you choose:

We would rather start you on the lighter tool and move you when the need is real than sell you the heaviest platform on day one. Migration between them is a service we offer precisely because we expect it to happen.

Why we selected these four

Every platform here had to clear the same four tests. They are stated as things these products have, because that is what you are buying — not a list of what other software lacks.

What integration actually means here

The fourth criterion is the one that pays for itself, and it is worth being concrete about. These four share a common technical foundation, which means one hardening standard, one backup approach, one monitoring pattern and one upgrade rhythm across everything you run:

• PHP
• Linux
• Nginx / Apache
• MySQL / PostgreSQL
• Redis
• Docker

For you that means the runbooks we hand over are the same shape whichever platforms you run, your staff learn one operating model rather than four, and adding a second product later is an extension of what you already know rather than a new discipline. It is also why we can support all four properly instead of spreading a team thin across unrelated technologies.

• One authentication source — LDAP or Active Directory across every platform, so joiners and leavers are handled once.
• Linked records — a monitoring alert becomes a ticket, a ticket links to an asset, a defect links to the requirement it violates.
• One backup and recovery regime — the same engines underneath, so restore testing covers the estate rather than one system at a time.
• One upgrade cycle — planned together, tested together, with the same rollback approach.

And all of it stays inside your network

This is the part that matters most to us, and it is why the licence criterion came first. Every platform on this page runs entirely on your infrastructure. None of them requires a connection to anybody else to function.

It is worth being precise about what this data actually is. A work-management estate is not incidental administrative exhaust — taken together, these systems describe your organisation in more detail than almost anything else you hold:

• Your requirements and backlog — what you are building, and therefore where your business is going next.
• Your defect history — where your systems are weak, and how long weaknesses stay open.
• Your asset and licence register — a complete map of your estate, its versions and its suppliers.
• Your ticket history — who asked for what, who approved it, and what broke.

A cloud platform will promise to keep that safe. The promise may well be sincere and the engineering behind it may be excellent. But it remains a promise made by somebody else, revocable under terms they write, subject to a jurisdiction you did not choose, and dependent on a commercial relationship continuing. On-premises replaces that promise with a fact you can verify yourself.

The full argument, including the honest counter-arguments, is on Why On-Premises.

How each fits PRINCE2

PRINCE2 is a governance framework, not a work-management tool. You do not replace PRINCE2 with any of these products — you use the product to operationalise the controls PRINCE2 defines.

The division of labour is consistent whichever tool you run:

• PRINCE2 — governance, roles, business case, stages, tolerances, decisions, risks, issues, progress.
• Agile — iterative delivery, backlog, sprints, user stories, continuous feedback.
• The tool — records, workflows, tasks, issues, evidence, dashboards and traceability.

Ratings are our assessment of fit for this purpose, not a general quality score.

LAYER 1 — GOVERNANCE PRINCE2 — project governance Business case · Risks · Quality Management stages · Decisions · Progress Tolerances · Change control · Exceptions The board sets what must be delivered, and within what limits. authorises and controls LAYER 2 — DELIVERY MANAGEMENT Agile · Scrum · Kanban How the team actually produces the product. PRINCE2 does not dictate this — the team manager chooses it. is recorded in LAYER 3 — TOOL PLATFORM Tuleap Requirements, sprints, code, tests and releases — linked. Full engineering lifecycle under governance. Leantime Goals, milestones, tasks and kanban. Project control without an ALM platform. MantisBT Defects, verification and closure. The quality subsystem underneath the others. accepted product hands over to AFTER CLOSING A PROJECT — OPERATIONS GLPI — operational ITSM and asset management Configuration items · Servers · Network · Software · Users · Contracts · Incidents · Maintenance

Tuleap — the strongest PRINCE2 and Agile combination

If your objective is specifically to run a PRINCE2 project using agile delivery, Tuleap is where we would start. Almost every PRINCE2 management product has a native home in it, which means governance stops being a parallel set of documents and becomes the structure of the tool itself.

The part that matters most: traceability

The mapping above is convenient. The chain below is the reason to choose Tuleap at all — every link in it is queryable, which is what turns ‘we follow a process’ into evidence.

Stages outside, sprints inside

The structure that follows is the cleanest reading of PRINCE2 Agile we know: PRINCE2 stages provide management control, agile sprints provide the delivery mechanism, and the stage boundary is where the board actually decides something.

Leantime — the easiest PRINCE2 implementation

If the organisation is not primarily a software-development shop, Leantime is frequently the better answer. It gives you a lightweight PRINCE2 control layer over ordinary work management, without asking business users to learn an engineering platform.

Concretely, a PRINCE2 Stage Plan defines the objective, products, quality criteria, resources, cost, schedule, risks and tolerances. Leantime then carries the work underneath it — milestones for Backend, Frontend and Testing, each with its own tasks — and the stage boundary remains a management decision rather than a status column.

MantisBT — the quality subsystem, not the project system

MantisBT is narrower, and we would not try to turn it into a complete PRINCE2 project-management system. It works best sitting underneath one.

The join is the Quality Register. PRINCE2 states the criteria — response under two seconds, no critical defects, UAT approved. MantisBT records each defect against them, and carries it through developer fix, tester verification and project-manager acceptance. That is a clean architecture when another system already handles project management.

GLPI — where the project becomes an operational service

GLPI’s strength appears when a PRINCE2 project involves IT infrastructure, assets, services and operational transition. It is least useful for agile software development and most useful at the point most projects handle worst: the end.

Closing a Project requires moving the project’s products into operational use. That is exactly what GLPI is for — the servers, virtual machines, network equipment, software, users, contracts, support tickets and maintenance the project just created become a maintained operational record rather than tribal knowledge held by whoever built them.

• Configuration items and the relationships between them
• Servers, virtual machines and network equipment
• Applications, licences and support contracts
• Users, incidents and ongoing maintenance

A combination we would actually recommend

You do not need all four. For a medium or large software or IT organisation, three of them cover the ground with a clean separation between governance, delivery and operations:

MantisBT joins that only if Tuleap’s own defect management is not sufficient for your QA process — which, for most teams, it is. Adding a fourth tool to a working three is a cost, not a feature.

Which combination is right for you is a scoping question rather than a catalogue question. It depends on what you are obliged to evidence, who has to use the tool, and what you already run. That conversation is the first thing we have.