Concourse & Jira DC Portal

Give engagement teams the option, at activation, to keep Sub-stage (L2) and Activity (L3) as fields on each work item rather than as parent levels. The hierarchy would go from six levels to four: Stage, then Deliverable/Event, then Task, then Sub-task. Lifecycle position stays visible on every item.

Problem Statement
Teams consistently say the six-level hierarchy is too deep to plan and manage day to day. Users must go through Stage, Sub-stage and Activity before reaching the work they deliver at L4–L6. The resulting parent-child chains cause practical problems:

• Kanban boards: teams can’t build a board of all L4s within a Sub-stage, because L3 sits in between (CONC-I-2429).

• Ongoing activities: governance work that stays open extends Sub-stage and Stage due dates through roll-up (CONC-I-2544).

• Navigation: Jira shows only the immediate parent, so users click through each level to see where an item sits (CONC-I-2477).

• Upfront structure: items can’t be created without assigning a parent first (CONC-I-2349).

Most teams don’t use L3 for delivery or reporting, and few assets are linked to it (CONC-I-2429, CONC-I-2583).

Why It Matters

• Fewer layers: the hierarchy drops from six levels to four, so teams reach the actual work directly.

• Lifecycle visibility is kept: Stage stays in the hierarchy, and Sub-stage and Activity are on every item. Teams, clients and quality reviewers can still see where the engagement is in the PDM lifecycle.

• Better planning and reporting: filtering, grouping and boards by Sub-stage or Activity become simple field queries, not hierarchy workarounds.

• Works within Jira’s limits: Jira allows only one hierarchy per site, and this simplifies that hierarchy rather than adding a second one.

Related Ideas
CONC-I-2294, CONC-I-2583, CONC-I-2429, CONC-I-2399, CONC-I-2614, CONC-I-2480, CONC-I-2477, CONC-I-2544, CONC-I-2349, CONC-I-1911