Found in Projects → [Select single project] → Project planning → Project tree.
The project tree is the central tool for preparing the content of a single project in Leadtime. It connects structured requirements gathering, configurable project logic, and operational execution into a cohesive overall process. In this area, predefined project components are imported, adapted to the customer's individual needs, and turned into actionable tasks. The recorded information influences the project scope, the effort involved, and all downstream documents – especially the specification sheet and later also the offer. This way, you get a solid, traceable, and audit-proof foundation for the whole project execution.
The project tree makes it possible to prepare projects in a systematic, methodical way. By reusing standardized components, the error rate drops significantly. Customers are actively involved in defining requirements without getting access to internal tools. At the same time, the dynamic project structure boosts how scalable the organization is, since various customer situations can be mapped without redefining everything from scratch. Tying it in with operational tickets means project configuration flows smoothly into execution.
Under Administration → Project Components, the organization manages a collection of reusable project templates. These templates are pre-structured, generic templates for projects that the organization needs to run regularly. The templates already include structured work packages, descriptions, question catalogs, test procedures, and effort estimates. When starting a new project, one or more of these components are added to the project via the "Import from library" button. Every imported component is fully copied and can be changed independently within the project, without affecting the original in the library.
How to create project templates in the component library: Project templates
After importing, the component appears as a hierarchical tree structure in the left column of the interface. You can expand and collapse all elements there to get a quick overview. The project tree is usually divided into larger thematic areas (Epics), which in turn consist of concrete work packages. There are also checklists for preparatory customer contributions and test suites for structured acceptance processes. This hierarchy makes sure that projects of different sizes can be built in a consistent and understandable way.
The building blocks of project components
When you select an element in the tree, a detailed view shows up in the central column. Here you’ll find in-depth descriptions, logic for possible scenarios, input fields, and sometimes questionnaire structures. Plus, you can create a task at this spot, which will then be handled in the team’s ticket system. That way, defined requirements instantly turn into action steps ready to be worked on.
The right column has extra info that isn’t visible to the customer. This includes internal notes, tags to help organize, effort estimates, and linked tasks. With this info, the team can set priorities, assign responsibilities, and track progress. Since internal hints can only be seen by the team, more sensitive details can be stored safely there.
Work packages form the operational core of the project tree. They include descriptions, effort estimates, and often questions that get answered straight up in talks with the customer. The answers have a direct impact on the structure of the project. For example, more tasks might pop up, optional content could be enabled, or the estimated effort could go up automatically. This dynamic logic makes sure different customer requirements can be reliably mapped out using the same template.
The building blocks of project components
Checklists are especially helpful for tasks that the client can prepare themselves. Instead of static documents, the client gets structured entries in the ticket system, which they can work through step by step. Test suites are used to systematically check at the end of the project whether all functionalities were delivered as agreed. This helps with clear approval and reduces follow-up questions and correction cycles.
Lots of project components have hidden elements that only become visible after certain answers. That way, the project tree automatically adjusts to the client's needs, without the project team having to step in manually. For example, selecting “Need photoshoot” can add a new work package, which in turn needs a billable product. This automatic structure makes things scalable and efficient, especially for recurring types of projects.
About conditions in work packages
While the project tree is only available to the internal team, tasks are created from it that can then be assigned to the customer in the ticket system. This way, part of the requirements gathering can be delegated directly to the customer. The customer answers questions, uploads materials or confirms content. That cuts down on rounds of feedback and makes project management way more efficient.
Task and ticket generation
Work packages can be turned into tickets with just a click. These auto-generate descriptions based on the customer’s answers. The team immediately gets a briefing that can be put to use right away. Tickets can be assigned, commented on, prioritized and tracked for time inside the team. Progress is visible in both the ticket and the project tree, so there's no need for double maintenance.
All content configured in the project tree automatically flows into the requirements specification. This is a textual condensation of all planned services. Later, it forms a contractually relevant basis. Options, decisions, exclusions, and additional efforts are transparently documented. Since the requirements specification is generated from structured data, it’s consistent, reproducible, and free of transfer errors.
How to create requirements specifications: Projects – Tab Documents (Single projects only)
When you first open the project tree, it’s empty. The user has two options:
Import component from the library
This method is recommended if it's a standardizable project. Organizations can use the library to provide pre-made project templates that are reusable, tested, and quality-assured.
Create component ad hoc
You can build a component just for this project using the Create new button. This component won't be added automatically to the global component library, so it's not reusable. This way works well for single or special projects. But a component you create ad hoc in a project can still be added to the component library later with the context menu feature “Export to Library”.
After import or creation, the structure shows up right away in the left tree; all edits happen directly there.
How to create project templates in the component library: Project templates
A typical process:
Open project tree
Import project component(s)
Discuss work packages with customers
Capture responses
Check dynamic packages
Add internal notes
Validate effort
Save version
Generate tickets
Start implementation
That way you get a clean, reproducible business process.
There are four basic building blocks in the project tree that make up the structural process of a project:
The building blocks of project components
Epics represent big thematic sections of the project (e.g. "Design", "Technical implementation"). They help structure the scope logically and make it easier to group work packages in a meaningful way.
These are the operational work units. They include:
Descriptions and contexts
Questionnaires to clarify requirements
dynamic logic (activating conditions)
Effort (in hours)
the button for ticket creation
Work packages are the foundation for later tickets and thus the actual production unit of the project.
Checklists are used when individual steps need to be checked off by the customer or team. Examples: “Delivery of material”, “Collect SEO data”.
Test suites are made up of predefined test cases, which are typically used for acceptance and quality assurance (e.g. “Website Responsive Test”).
You can use arrows to expand or collapse epics and their content. That helps you keep track of big projects.
You can move elements around in the tree:
Change order
Move work packages between epics
Define new logical order
This also lets you create even better structures later.
Each element has a menu (three dots icon). The options change depending on the element type, but typically include:
Create Tasks
Generates tickets for all subordinate work packages. Important: Only run if the configuration is finished.
Delete
Removes the item from the project (but not from the global library).
Edit
Opens the edit dialog for basic data like description, internal notes, tags, estimated time.
Duplicate
Duplicates items (like several product variants, recurring task blocks).
Available additionally at the component level:
Export to Library
Lets you write a customized component back to the global library. This makes it possible to standardize a custom change long-term.
A plus button below the component lets you create new structure elements in the tree. You can add:
new epics
new work packages
new checklists
new test suites
This way, the standard can always be extended for each project without changing the global component.
When you click on an element, a detail view pops up in the middle. It includes:
Description
Content explanation of the work package.
Question fields
The customer or the team answers structured questions here. The answers affect:
Effort
Activation of optional packages
Structure of the requirements specification
Comments
Allow follow-up questions and internal coordination.
These fields form the basis for later service descriptions.
Many work packages react to answers:
"Yes/No" decisions activate more packages
"Other" shows free text fields
Requirements automatically increase the effort
Example: "Do you need a photo shoot?"
→ Activates the "Photo session" package and requires the product "Photoshooting Day".
This logic makes it easier to model complex variants.
In the right column, you’ll find the button:
Create task
If you trigger it:
A ticket is created with the info saved in the work package
Effort is carried over
the ticket can be assigned, commented on, and timestamped
Progress gets mirrored back to the project tree
Later, if Create tasks is used at epic or component level, all tickets that haven’t been created yet will be generated in one go.
Tags are inherited:
Tags from the component
Tags from the epic
Tags from the work package
In the ticket system, tags help with filtering and assigning tasks.
Example: You can instantly see which tasks are part of "Design."
Using tags in project components
Every element can have internal notes. These:
don't show up in the specs
aren't visible to clients
can include implementation guidelines, warnings, quality standards
Example: "Watch out for responsive image sizes," "For this client, always check data privacy."
Internal notes are like a built-in memory bank.
About Internal Notes
Every work package has a time value in hours. The sum of all efforts:
forms the offer price (if calculation is time based)
is documented in the requirements specification
changes dynamically through customer answers
This way, the scope becomes automatically relevant for the budget.
How project efforts are calculated
The project tree has a versioning mechanism. Every substantial change should be saved in a new version, like after:
customer meetings
questionnaires that have been answered
suggestions for expansion
The version documents:
scope of services
objective
change history
When the customer approves the offer, they reference one project version. This version is legally binding later.
