GLPI project module: tasks, phases, and dependencies

GLPI project module: tasks, phases, and dependencies

GLPI is not Jira and was never meant to be. The Projects module, in GLPI since 9.1, is built for internal IT projects — migrations, upgrades, rollouts, hardware refresh — where the team already works with tickets and assets in GLPI and adding a project layer means they don't have to switch tools. If you're running agile product development for an external client, GLPI Projects is the wrong choice. If you're running an Exchange-to-M365 migration or a new ERP rollout, it's exactly right.

Hierarchy: project, phase, task

The module has three object levels:

  • Project — top-level unit. Has an owner, a manager, start and end dates, percent complete, budget (amount + currency), priority, status (Planned / Running / Completed / Suspended), and entity (multi-tenant scope).
  • Project task — tasks within a project. They have their own status, planned and actual time, an assignee, predecessors (dependencies), and percent complete. Tasks can be hierarchical (parent-child).
  • Sub-project — a project nested inside another. Useful for large programs (for example "ERP Migration" → sub-projects "Finance migration", "HR migration", "Logistics migration").

GLPI does not use "phase" as a separate object — phases are modelled either as hierarchical tasks (a parent task "Infrastructure prep" with child tasks "Order servers", "Configure network") or as sub-projects.

Task dependencies

Each project task can have predecessors — tasks that must finish before this one can start. In the task detail view, the Predecessors tab lets you link other tasks. GLPI doesn't ship a native Gantt as rich as MS Project, but it does render a timeline view in the project (the Gantt tab on the project).

Dependencies are not hard-enforced — you can mark a task complete even if its predecessor is open. GLPI just signals the conflict visually. If you need hard dependencies with automatic date shifting, the module doesn't cover that — that's MS Project or a dedicated PM tool territory.

Linking to tickets and assets

This is the main value-add over a standalone PM tool. On a project, the Tickets tab links existing tickets or creates new ones tied to the project. That means:

  • Helpdesk volume during a rollout or migration is automatically aggregated — the project manager can see in real time how many incidents arose during the database migration.
  • Assets (servers, switches, licences) are linked to a project via the Items tab. At audit time it's clear which hardware components belong to which initiative.
  • After project closure the links stay — the manager keeps the historical context for why a particular configuration was chosen.

Practical fit: GLPI vs. another PM tool

Use GLPI Projects when:

  • The project has a large share of operational work (changes, incidents, physical installs) — that work already lives in GLPI.
  • The project touches assets (HW migration, refresh, replacement, retirement) — the link to inventory is a real win.
  • The team is inside the GLPI organisation — no need to share with external clients.
  • The project has clear phases and deliverables, not sprint-based agile development.

Avoid GLPI Projects when you're running agile product development, working with external clients who need their own access, or relying on advanced PM reporting (capacity planning, burndown charts, velocity tracking) — Jira, Asana or Monday do those things better.

Time tracking and allocation

Every project task has a Planned duration and Actual duration. Time is logged either via the Time tracking tab on the task, or automatically aggregated from time logged on tickets linked to the project — if a technician logs 2 hours on an incident tied to the project, GLPI adds it to the project total. That gives the project manager a real view of where time is flowing in the project, without having to keep separate timesheets in another system.

For resource allocation, the module doesn't have a notion of "technician capacity" the way dedicated PM tools do. Assignment is straightforward — a task has one or more assignees — but GLPI won't stop you from giving the same person 60 hours of work in a week. For harder capacity control you need an add-on plugin or external reporting.

Reporting on projects

Built-in GLPI dashboards show active projects with status, percent complete, and assigned manager. For deeper reporting (time tracked through tickets linked to a project, hours worked vs. planned, cost vs. budget), use the built-in report builder or the Dashboard plugin for GLPI 11, which lets you build custom widgets over project data.

The Projects module in GLPI isn't a replacement for Jira or MS Project. It's a bridge between operations (tickets, assets) and project coordination. For IT-internal work, that bridge is often the missing piece — and in GLPI you get it without another tool, another licence, and another context switch.

Need help with this topic?

Get in touch