The "Implementation Overview" section is used for operational management and monitoring of ongoing projects. It gives a condensed overview of all work packages and tasks defined in the project tree, letting project managers keep an eye on the current implementation status in terms of content clarification and time allocation. The page is closely tied to the project tree: every element modeled there that has a ticket is continually evaluated here.
While the project tree is for designing and configuring the project's content, the "Implementation Overview" is all about tracking the execution. It answers the question: How far along are the individual project components—both in organization and in terms of actual work done?
To the project tree: Projects – Planning tab
The "Implementation Overview" makes the switch from planning to execution transparent and measurable. While the project tree models the project's dimension, the Implementation Overview monitors the operational reality—clear, traceable, and efficient.
Combined, both sections let you:
scalable project implementation
methodically sound planning
clear responsibilities
solid proposals
transparent billing
The progress of a work package is assessed by two factors:
Content progress within the work package
The subject elements in a work package (e.g. questions, to-dos, test cases) get checked off as soon as they’re fully clarified or completed.
Example: A work package contains 10 questions, 8 of which have been answered → 80% content progress.
Implementation of the work package as a ticket
If a ticket was created for the work package, the actual working time spent is compared to the estimated time.
Example: The ticket has a budget of 8 hours; 4 hours have been logged → 50% completion.
Both dimensions are shown side by side to make it transparent whether a package is already clarified in terms of content but not yet implemented — or maybe even the other way around.
When you open the area, you’ll see a table with all the project tree elements that need to be handled as work packages, checklists, or test objects. The list includes these columns:
Checkbox
Element name
Number of cleared entries (Cleared)
Total number of entries (Total)
Time already logged (Worked)
Assigned time budget (Budget)
Ticket status
Currently assigned person
Direct link to ticket
That way, you can quickly identify, prioritize, and manage individual packages.
There's a button above the table:
Create tickets for selected work packages
This feature creates tickets in the ticket system for selected items. It's relevant once a project's concept is fully modeled and you want to start working on it.
It's also possible to select all sub-packages of one component at the top level with just one checkbox. That way, you can create dozens of tickets in one click.
Each work package has a set number of items to cover. These are worked through in the project tree (for example, during a customer meeting) and then reflected here. The progress bar shows how much of the content has already been clarified.
Example:
“Capture design wishes” contains 7 questions
2 of them have been answered
The bar clearly shows incomplete preparation → Need for action
As soon as a ticket exists, the actual time spent will be shown. This goes into the project's budget review. The bars visualize any deviations:
Green: within the range
Yellow: critical
Red: over budget
Besides the progress, you can see:
whether a ticket is open, in progress, or closed,
who is currently responsible for it.
This way, project managers can tell at a glance if tasks are stuck or unassigned.
If there are tickets in the "Tasks" tab that aren’t assigned to any work package in the project tree, they show up in a separate group Unassigned Tasks.
This is an important early warning sign:
these tickets were created manually,
they aren’t based on any specification,
they weren’t modeled in the process.
That can make sense (for example, support cases), but it’s an organizational risk, since it happens outside the planned structure.
Recommendation: Additional tasks should be managed in a separate support project to keep the project tidy.
The project progress mainly serves to:
spot bottlenecks,
identify blocked work packages,
show workload overload for specific people,
spot risks in the budget early on,
make additional effort easy to communicate.
Project managers typically use this view regularly during implementation.
Clarifying content and planning the timing creates versions. Versions capture the documented state of a project at a certain point in time. As soon as a work package is changed by answers in the project tree, a new version should be saved. This way, it's easy to track:
when the scope of work changed,
how the effort developed,
what basis the later offer is based on.
The “unsaved” status above shows that changes haven't been versioned yet.
