Hierarchical Work Breakdown Structure (WBS) as the foundation for project planning
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 36.9k
- Forks
- 5.2k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 713
Description
[!TIP]
Help move this idea forward
- Use the π reaction to show support for this feature.
- Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
- Subscribe to receive notifications about status changes and new comments.
Is your feature request related to a problem? Please describe.
Deck is an excellent Kanban tool and is evolving towards a more capable project planning application with features such as the Timeline/Gantt view. However, for medium and large projects there is still no way to organize work in a true hierarchical project structure. Today, boards, stacks and cards represent a mostly flat structure. Checklists can break down a task, but checklist items are not first-class project objects. They cannot be independently scheduled, assigned, linked with dependencies or visualized in a timeline.
Because of this it is difficult to:
- create a proper Work Breakdown Structure (WBS)
- decompose deliverables into work packages
- build a dependency network (PERT)
- generate a meaningful Gantt schedule
- summarize progress on higher project levels
- estimate effort at different levels of the project
Describe the solution you'd like
Introduce an optional hierarchical project structure where cards may contain child cards, creating a true Work Breakdown Structure.
Example:
Project
βββ Phase 1
β βββ Deliverable A
β β βββ Activity 1
β β βββ Activity 2
β β βββ Activity 3
β βββ Deliverable B
βββ Phase 2
Each node in the hierarchy should be a normal Deck object that can have:
- assignees
- labels
- start dates
- due dates
- estimated effort
- attachments
- comments
- dependencies
Parent objects could automatically summarize:
-
progress
-
estimated effort
-
completed work
-
start and finish dates
Work Breakdown Structure β βΌ Task Dependencies (PERT) β βΌ Timeline / Gantt β βΌ Daily Execution (Kanban)
The idea is that every planning view is based on the same underlying project model rather than maintaining separate representations.
The hierarchy could become the common data model for multiple planning views:
- Kanban
- Timeline / Gantt
- Calendar
- Future dependency (PERT) visualization
- Reporting and dashboards
A simple dependency model would greatly improve planning. If an activity is moved, successor activities should automatically be rescheduled according to their dependencies.
Example:
Activity A ββββββΊ Activity B ββββββΊ Activity C
If Activity A is delayed by three days, Activities B and C should automatically move by the same amount unless a task has been explicitly marked with a fixed date. This would provide basic scheduling capabilities without introducing the complexity of a full enterprise project management system.
Describe alternatives you've considered
Currently the closest alternative is using: multiple boards, stacks as pseudo hierarchy, checklists for subtasks
Unfortunately none of these provide true hierarchical planning because child work items cannot be independently managed or scheduled. External project management systems (such as Microsoft Project or OpenProject) support WBS, but they require maintaining project information outside the Nextcloud ecosystem.
Additional context
The intention is not to turn Deck into a replacement for Microsoft Project or other advanced enterprise project management tools. Instead, the goal is to introduce a lightweight but powerful planning model that supports the most common project management needs while keeping Deck simple and easy to use.
The following basic capabilities would already provide significant value:
- hierarchical Work Breakdown Structure (WBS)
- Task Dependencies (PERT)
- simple Finish-to-Start dependencies
- optional fixed dates (tasks that should not move automatically)
- progress roll-up
- Timeline/Gantt generated from the hierarchy
Rather than implementing many isolated features (advanced Gantt, dependencies, reporting, resource planning), a hierarchical WBS could provide the underlying project model on which future functionality can naturally build. This would allow Deck to evolve from an excellent Kanban application into a lightweight project planning platform without sacrificing its simplicity.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up β it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are identified. Start by mapping Deck's existing card, checklist, Timeline/Gantt, and dependency-related models and views, then determine which smallest part of the proposed hierarchy can be scoped independently. Done would require an agreed data model and defined behavior for child cards, scheduling, and progress roll-up.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, php
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100