Concourse & Jira DC Portal

Hi everyone! Thank you for voting and providing additional context with comments!

Good news, this has been released!

Users can now override the progress percentage for work items that do not have a child underneath them (an example being a Deliverable without tasks or tasks without sub-tasks). The possible values for override is between 1%-99%.

The blocked status will not hold any percentage value. If the status of a work item is marked as blocked, it will retain the previous percentage value.

Users cannot override the progress percentage for the following items:

• Work items that have a child item underneath - the progress percentage for those items will be an aggregate of all child percentage values

• Work items with the status:

  • Not Started = 0%

  • Withdrawn = 0%

  • Completed = 100%

On the Deliverables page, the Progress column header now has an "i" icon where you can learn more about the current logic for the progress percentage.

Please continue to use this feedback portal as you have more ideas!

Thank you!

The ability to choose how % percent complete is tracked would be fantastic (e.g., checklist completion)

The current logic for completion percentage is very misleading to individuals that don't understand how it is calculated.

The completion percentage is based on the aggregate of all the associated tasks below the deliverable and depending on the status type.

Status Type Percentages

• In Progress = 50%

• In Internal Review = 75%

• In External Review = 90%

• Completed = 100%

For the deliverable status completion aka 'progress' it aggregates the totals from the tasks below.

If you have 3 tasks and

• 1 is complete = 100%

• 2 are not started = 0%

Your deliverable 'progress' will be 33%

The more tasks and subtasks you have, the less influence completing a particular task will have on the deliverable status completion / 'progress'.

I've had several conversations with teams who are very frustrated by this logic since they don't have the ability to weight tasks and sub tasks. Not every task or subtask should be weighted the same. Scheduling a client meeting versus actually completing a deliverable and receiving sign-off from the client should NOT be weighted the same.

The standard reporting is based on these metadata fields, which has caused their engagement leaders to feel the team isn't as far ahead or progressing as quickly as they should.

Additionally, a team used the standard reporting and it showed them as 80% complete one week, but only 60% the following week because the team had added additional tasks to their deliverables tab/delivery map. This caused a lot of confusion and frustration for all parties.

Plus it created inefficiencies for the team because they had to create another file to explain what had happened to cause this change and they had to bring senior leaders to the discussion to support the team's explanation.

This is an issue that needs to be escalated and addressed. I also heard these complaints from a senior partner and a PTL within our platform yesterday.

Thank you for submitting this idea – we’ve assigned this to our product team focused on additional research. The research team will be working with the team focused on the deliverables page to explore this idea further. Thank you again!