GLPI project management and Kanban boards

When IT teams need GLPI project management

IT work that spans tickets, changes and budgets often ends up split across spreadsheets, a separate project tool and the service desk, so nobody can see which requests a project depends on or what a change will cost. GLPI projects keep that work linked to ITIL items inside the same platform: a project can carry tasks, teams, sub-projects, Gantt diagrams, costs and links to tickets, and it can be linked to a change. If your IT organization already runs its service desk or change process in GLPI, this module is the place to plan and track the projects those processes produce.

The teams that usually implement this module are the IT operations or service management lead who owns the project portfolio, the PMO or delivery manager who runs multi-team projects, and the finance contact who needs project costs tied to budgets and assets. Change managers and the GLPI administrator are also involved, because project-to-change links and the Kanban views depend on how changes, statuses and profiles are configured. Confirm with your own team which project statuses, teams and cost categories you need before any build starts, since those decisions shape every later view.

Treat project management as its own workstream, scoped separately from change management, the wider GLPI rollout and any data center or asset work. It depends on those earlier decisions but has its own deliverables: project templates, status and team design, cost capture rules, and a tested Kanban layout for each audience. Agree the scope in writing, name an owner for each decision, and check the GLPI version you run against the GLPI projects documentation before you commit to a design.

What GLPI project management does

GLPI projects sit alongside its ITIL records, so a project can carry its own tasks and teams while still pointing at the changes, tickets and costs it depends on. The cards below cover the documented capabilities and note which ones rely on other GLPI modules.

Tasks and teams

Projects are broken into tasks, and each task can be assigned to people or groups. This gives a project lead a shared list of who owns what. Check that your GLPI users, groups and profiles are set up first, because task assignment depends on the directory of users and groups that GLPI already holds. Confirm how your team wants task status and ownership reviewed before rollout.

Sub-projects

A project can contain sub-projects, which lets a large initiative be split into workstreams that each keep their own tasks and status. This is useful when infrastructure, application and security work run in parallel under one programme. Decide early how deep the hierarchy should go, since a deep tree is harder for stakeholders to read and report on.

Gantt diagrams

GLPI can show project tasks on a Gantt diagram, giving a timeline view of scheduled work. It is a planning aid for the project lead rather than a full scheduling engine. Dates entered on tasks drive the chart, so the value depends on whether the team keeps those dates current.

Kanban method for projects

Projects can be viewed on a Kanban board, where project statuses move cards across columns. Statuses for projects are configurable, which lets your delivery vocabulary match your own process. Plan the status set before the first project is created, because changing it later affects how existing projects appear on the board.

Costs on projects

Projects support cost records, so budgeted or actual spending can be tracked against the project. Cost reporting depends on how your finance team wants amounts and currencies recorded, and it becomes useful only if those records are kept current. Ask your finance lead which cost categories must match existing budget or contract records, since that affects how costs are entered.

Links to ITIL items and changes

A project can be linked to ITIL items, and it can be linked to a change. That connection lets a delivery project reference the change records that approve and schedule its production work. It depends on the change management module being configured, so confirm that changes, approvals and impacted items are in use before relying on those links for audit trails.

Configuration decisions for projects and Kanban

This table compares the main configuration choices for GLPI projects and Kanban boards, with the situations where each option fits and what it changes later. Read each row before building anything, because structure, status and linking decisions are hard to reverse once tickets and projects accumulate.

Decision	Option	When it fits and what it changes later
Project structure	Flat projects per entity	Fits when each entity runs its own portfolio and visibility should follow the entity. Changing entity later means moving or recreating projects, so confirm entity boundaries first.
Project structure	Parent project with sub-projects	Fits a single initiative split into workstreams, such as a platform migration. Roll-up reporting depends on keeping the hierarchy consistent, so agree naming and depth before the build starts.
Team and role assignment	Individual assignees per task	Fits small teams where one person owns each task. Reassignments are simple, but reporting by team is weaker.
Team and role assignment	Teams attached to the project	Fits cross-functional work where several groups contribute. Confirm how team members are kept in step with your group and user records so access and notifications stay accurate.
Link to changes	Projects linked to a change	Fits deployments that need the change approval and planning record to sit beside the project plan. Confirm with your change process owner which record owns approval and which owns schedule.
Link to changes	Projects linked only to tickets	Fits work driven by service requests and no formal change approval. Later, adding change control means linking existing items and reviewing the workflow, so plan the change path early if it may be needed.
Project statuses	Custom status set	Fits teams with their own lifecycle stages. Project statuses are configurable, so define them once with the project owners and keep the list short to simplify Kanban columns.
Project statuses	Reusing ITIL-style status names	Fits reporting teams that want consistent wording with tickets. ITIL statuses are not configurable, so the project status list cannot mirror their structure, and the mapping must be explained to users.
Kanban scope	Project Kanban for planning	Fits teams managing a portfolio of projects visually. Project Kanban uses the configurable project statuses, so column design directly reflects your lifecycle.
Kanban scope	Ticket, change or problem Kanban	Fits operational queues. These Kanbans are global per type, so every user sees the same board for that item type, and filtering should be agreed with the service desk before rollout.
Cost tracking	Costs recorded on the project	Fits project budgets owned by the project lead. Confirm with finance whether project cost entries should also appear in financial records, because duplicate entry is a common source of mismatch.
Cost tracking	Costs recorded against financial records	Fits organizations where finance is the system of record. Linking costs to financial records keeps reporting consistent but requires agreement on who enters and approves amounts.

How a project module rollout runs

The sequence moves from agreeing who owns project work to a tested set of projects that teams can use without help. Each step produces a decision or artifact that the next step depends on, so the rollout does not stall at configuration.

Confirm the operating model and roles
Agree with the IT portfolio owner, change manager and team leads which work belongs in GLPI projects and which stays in tickets or in another tool. Name who creates projects, who owns each project, who approves changes linked to them, and who maintains the configuration after go-live. The step closes with a written RACI sheet signed off by the sponsor, so later configuration choices can be checked against it.
Define project statuses and team structure
Design the project status list first, because GLPI lets you configure project statuses while ITIL statuses stay fixed. Map each status to a stage your teams recognize, such as proposed, active, on hold and closed, and decide which of them appear as columns on the project Kanban. Then set up the teams and group assignments that match the RACI. The output is an approved status model and a team structure that a reviewer can walk through against real project examples.
Configure project templates and tasks
Build reusable project templates for the project types your organization runs most often, with standard task lists, sub-project structure and default teams. Keep the number of templates small at first, since each one needs an owner who updates it when the process changes. Confirm that tasks can be assigned, dated and ordered the way your Gantt view needs. The step is complete when each template creates a project that a project lead can use without editing its structure.
Set up cost and link rules
Decide which projects record costs, who may enter them, and whether costs must be reviewed before a project closes. Then define how projects link to ITIL items: which projects must reference a change, whether a project can link to a problem or ticket, and who may create those links. Test each rule with a sample project that carries a cost entry and a linked change, and confirm that the linked change shows the project in its own record. Document the rules so change and finance reviewers know what to expect.
Validate Gantt and Kanban views with real projects
Load two or three live or near-live projects into the test instance, with tasks, dates, teams and at least one linked change, and check the Gantt diagram and project Kanban against the status model. Confirm that ticket, change and problem Kanbans show what the team expects, since those boards are global per item type and cannot be tailored per project. Record any gap as a configuration fix or as a limitation to communicate. The step closes when project leads confirm that the views match how they plan work.
Train users and hand over
Run short sessions for project leads, team members and the change approvers who will see project links, using the tested projects as the examples. Give each group a one-page guide to the status model, templates and cost rules, and name the administrator who owns the configuration after handover. Confirm the handover with a checklist: documented RACI, template owners, linked-change rule, and a list of open items with owners. The rollout is finished when the first live project starts from a template without help from the implementation team.

What the Kanban views show and where they stop

GLPI's Kanban view displays projects, tickets, changes or problems, and each of those item types gets its own board. The ticket, change and problem boards are global per type, so every technician who opens the ticket Kanban sees the same columns and the same set of items their profile can read. Teams cannot give their own group a separate ticket board with a different column layout, and a board does not become a team-specific workspace because a particular group works through it most often. Before you design any board around a team's workflow, confirm this behavior, along with any board filtering options, against the GLPI version you plan to install, since the Kanban documentation is the reference for what each release supports.

The statuses are where the design choices sit. Project statuses are configurable, so you can define the columns that match how your projects move from intake to closure. ITIL statuses on tickets, changes and problems are not configurable, which means a change board uses the status set GLPI ships with, and any stage your change process needs beyond that must be handled through existing fields, approvals or a separate tracking method. Decide early which process stages must be visible on a board and which can live in the item's history. If a team's change process depends on a stage GLPI does not model, plan for that gap rather than assuming a board will close it.

Practically, this means the Kanban views are a shared operational picture rather than a per-team planning tool. Ask your GLPI administrator to test the boards with a representative profile from each group before rollout, and check which items each profile can see on each board. Agree on how teams that need their own views will work, whether through saved searches, the standard lists, or project boards for work that is genuinely project-shaped. Confirm these options on your installed version first, because board behavior is the kind of detail that changes between releases and should not be built on from memory.

What drives the effort and cost of project setup

This table lists the main drivers that change how much work a GLPI project setup takes, why each one matters, and how to keep it contained. Read it before scoping, since the first two or three drivers usually set the size of the build. Keeping the status model, entity layout and migration scope small early is the most effective way to control effort.

Driver	Why it raises effort	How to keep it down
Number of teams and entities	Each team needs its own project visibility, profiles and entity placement, and cross-entity projects multiply the access rules to test.	Start with one entity or a small set of teams, and confirm with stakeholders which people truly need to see which projects before creating profiles.
Status model complexity	Project statuses are configurable, but every added status also needs a Kanban column, a meaning agreed by teams and a consistent use in reports.	Agree a short list of statuses that match how work actually moves, and avoid mirroring every stage of a legacy tracker.
Cost tracking depth	Project costs and links to ITIL items require someone to define what gets recorded, who enters it and how it reconciles with financial records.	Decide early whether projects carry only planned effort or full cost lines, and confirm with finance which fields they will actually use.
Integration with change management and financial records	A project linked to a change, or feeding financial data, depends on how change and budget records are configured, so each dependency adds design and testing.	Build the project model first, then connect changes and financial records in a second pass, and test one linked project end to end before rolling out.
Data migration from existing project trackers	Existing tasks, owners, dates and attachments rarely map one to one, and cleaning source data often takes longer than the import itself.	Migrate only open projects and active tasks, map fields in a short written table, and confirm with the data owners which history must be kept.
User training	Teams used to other tools need guidance on Gantt views, task ownership and when to use the Kanban board for projects versus ITIL items.	Write a one-page guide per role, run a pilot with one team, and ask the partner to quote training sessions as a separate line item in the written scope.

How project data connects to the rest of GLPI

A GLPI project rarely stands alone. Its tasks, costs, schedule and status draw on changes, tickets, problems, financial records and user accounts, so each link needs a clear owner. The cards below cover the connections to check first and the sibling topics where each linked module is set up.

Linking projects to changes

A GLPI project can be linked to a change, which lets a larger piece of work, such as a data center move or a platform upgrade, be tracked alongside the individual change records that deliver it. Decide before build which object is the source of truth for dates and approvals, because the project and the change will each carry their own status. Check that the link is set in both directions so reviewers see the same picture from either record. The change side is covered in the GLPI change management implementation topic.

Tickets as project intake

Requests that turn into projects often start as tickets, so ticket categories, requesters and the ITIL items attached to them shape how project work is reported. Ask who converts a ticket into a project and whether the original ticket is closed, kept open or linked. Poor ticket categorization makes project portfolios hard to group by service. The helpdesk configuration is covered in the GLPI helpdesk and ticket management topic.

Problems that drive project work

Some projects exist to remove a known error found in problem analysis, and the cost and impact recorded there becomes the business case for the work. Agree how problem records and project tasks reference each other so closure of the project can be checked against the problem. Keep problem status and project status separate to avoid false closure. Problem routing and analysis records are covered in the GLPI problem management implementation topic.

Costs and financial records

Project costs in GLPI only help with budgeting if they are matched to the budget periods and entities that finance uses. Confirm which budget a project cost draws from, who approves spending, and how sub-entity visibility affects who sees the totals. Negative remaining balances are a common source of confusion when project costs are posted late. The financial setup is covered in the GLPI budgets and financial management topic.

Users, groups and visibility

Task assignments, team members and Kanban views all depend on user records and group membership coming from the right source. If users are imported from LDAP or Active Directory, departed staff or renamed groups will leave stale assignments on project tasks. Check profiles and entities before granting project managers wide visibility. Identity and access setup is covered in the GLPI authentication and access control topic.

Data quality from other modules

Project reporting is only as accurate as the records it points to. Stale asset links, missing change categories, unmaintained ticket statuses and outdated user accounts all distort Gantt views and Kanban columns, so reporting may show work as late or complete when it is not. Before relying on project dashboards, sample linked records in each module and set an owner for the cleanup. Inventory data quality is covered in the GLPI inventory and network discovery topic.

Questions teams ask before setting up GLPI projects

How much effort does setting up GLPI projects take?

The setup effort depends mostly on how many project types, statuses and teams you need, and on how much your existing project data has to be cleaned before it goes in. A basic configuration of projects, teams and a few Kanban views is a small task compared with a rollout that defines project statuses for several departments, links projects to changes and imports historical plans. Effort also grows with the number of approval steps and cost categories you want tracked. Ask any partner to break the work into configuration, data preparation, testing and user onboarding, and to state which of these is included in a fixed scope.

How long does a GLPI project rollout usually take?

Duration depends on the drivers rather than on a fixed template: the number of teams adopting projects, the volume of historical data to migrate, the number of integrations with change management and approvals, and how many review cycles your stakeholders need. Rollouts that start with one pilot team and expand usually move faster than those that switch every department at once. Ask for a written timeline that lists each milestone, the people who must review it, and the dependencies on other GLPI workstreams such as change management or the GLPI version you run.

What does our internal team need to provide?

Your team needs to supply decisions and access rather than GLPI expertise alone. Typical inputs are a named owner for the project process, the list of teams and their roles, the project statuses and workflow your organization already uses, and access to a test instance where configuration can be checked before production. Someone must also approve the Kanban layouts and the rules for who can move a project between statuses. Confirm these inputs early, because late decisions about statuses or teams are a common source of rework.

Can our own team configure GLPI projects without a partner?

Yes, a capable GLPI administrator can configure projects, teams, tasks and Kanban statuses without outside help, provided the design decisions are already made. The harder part is the design: deciding how sub-projects reflect your portfolio, which costs are recorded, and how project records relate to ITIL items. Teams that run this internally usually document the decisions, test them in a non-production instance and review permissions with the people who will use the views. Check your GLPI version first, because menus and Kanban options can differ between releases.

Can we customize the Kanban board for each team?

Project statuses are configurable, so each organization can define the columns that match its project process. ITIL item Kanbans for tickets, changes and problems are global per type and their statuses are not configurable, so a team cannot give them its own column set. This means per-team customization is limited to projects, and any team that expects different ticket or change columns will need a process decision rather than a configuration change. Confirm the exact Kanban options available in your GLPI version before you promise separate boards to different groups.

How do GLPI projects relate to change management?

A GLPI project can be linked to a change, so planned work such as a platform migration can be tracked alongside the change record that authorizes it. Keep the roles separate: the project holds tasks, teams, sub-projects, Gantt planning and costs, while the change holds the approval, impacted items and implementation plan. Decide early which record is the source of truth for dates and status, because duplicate status updates in both places create confusion. Confirm how links and notifications behave in your GLPI version, and align the design with your change management workflow before you build the views.

What should we confirm about GLPI projects before we start?

Confirm four things with the vendor documentation and your own test instance: the GLPI version you will run, the project features you intend to use, the Kanban options that version offers, and the authentication and permission model for project users. Check that the project features you rely on, including Gantt diagrams and cost tracking, behave as your process needs in that version. Record the answers in the design document so the configuration, the training and any future upgrade work start from the same facts.

How DeployOpen scopes and delivers GLPI project management

DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For project management and Kanban boards, we start from the written scope, agree how projects, teams, statuses and change links will be used, and then build and hand over the configuration in your environment.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We list which project statuses, team groups and sub-project structures your organization needs in GLPI.
We confirm which projects must link to changes, problems or tickets, and which ITIL Kanban views your teams will use.
We ask you to confirm your GLPI version and hosting, since project features depend on the environment they run in.

How we build

We configure project statuses, task templates and team roles in a test instance before touching production data.
We set up Gantt, cost and project-to-change links, then check them against the scenarios agreed during scoping.
We test Kanban boards for projects and ITIL items, noting that ITIL statuses stay fixed while project statuses are configurable.
We verify notifications and access rights so each team sees only the projects and items it should.

How we hand over

You receive written configuration records covering statuses, teams, Kanban views and the change linking rules.
We document the working procedures your project managers and change managers follow day to day.
We walk your administrators and project leads through the configuration and the known limits of each Kanban view.
We agree in writing what remains with your team to maintain after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can plan project configuration checks alongside GLPI 11 and 12 upgrades, including plugin reactivation after major updates.
We can review project and Kanban configuration when your processes or GLPI versions change.
Support scope, response expectations and fees are set in the written agreement, and a quote follows from that scope.