News from the Product Desk: Changes to progress tracking in 14.6 based on user feedback
In version 14.0, we made significant changes to the way that progress and work estimates are tracked in OpenProject. Since then, we have received extensive feedback from our user community telling us that the changes do not reflect their needs and sometimes even made things unnecessarily more complicated.
We greatly appreciate the time and effort put in by those who communicated their reservations to us. Your input is invaluable in helping us improve OpenProject. Based on that feedback, we have taken two main actions: We enhanced our feedback gathering process internally and, more importantly, decided to allow users to revert the changes made in version 14.0.
Starting with OpenProject version 14.6, the % Complete field will once again be manually editable in work-based mode and % Complete totals will no longer require Work to be input.
This blog article details how these changes might affect you.
Upcoming adjustments
Manually-editable % Complete in work-based mode
You will once again be able to manually enter a value for % Complete in work-based mode. This will be possible in both table view and work package details view.
As is the case today, % Complete will continue to be tied to Work and Remaining Work. What changes now is that those two values will no longer be required to enter % Complete. This means that if you do not enter Work or Remaining work, the % Complete field will remain an independent, manually editable field and behave like it did pre-14.0.
However, if you enter a value for % Complete and one other field (Work or Remaining work), the third one will automatically be derived based on the other two. In other words, there can be one value or three values but never just two values.
How the three fields are connected
The Work, Remaining work and % Complete fields interact in predictable ways.
When no field is set
When a work package has none of these three values set, which field you enter first will determine if the others are derived as well:
- If you enter just % Complete, nothing else is derived. Work and Remaining work remain empty.
- If you enter just Work, Remaining work is set to the same value as Work, and % Complete is set to 100%. You can remove these derived values manually if you want.
- If you enter just Remaining work, Work will be set to the same value as Remaining work and % Complete is set to 100%. You can remove these derived values manually if you want.
When one field is set
When only one field is set and you enter a value for a second field, the third is automatically derived:
- If you enter % Complete when Work is already set, Remaining work is derived.
- If you enter % Complete when Remaining Work is already set, Work is derived.
- If you enter Remaining work when Work is already set (and vice-versa), % Complete is derived.
There are however, two important exceptions:
- If you enter a value for Remaining work that is higher than Work, this will result in an error, since this is not logically possible.
- If you enter a % Complete value of 100% when Remaining work has a value, this will also result in an error, since Remaining work must be 0h when % Complete is 100%.
When all values are set
When all three values are present, the following table explains how changing one value affects the others:
Increasing Work
When you enter a value for Work that is higher than the current value, this adds the same value to Remaining work (since the total Work has increased by a certain amount), which then also updates % Complete:
| Work | Remaining work | % Complete | |
| Initial state | 100h | 60h | 40% |
| Wechseln | 200h | ||
| Updated state | 200h | 160h | 20% |
Decreasing Work
If you decrease Work, Remaining work is lowered by the same amount:
| Work | Remaining work | % Complete | |
| Initial state | 100h | 60h | 40% |
| Wechseln | 50h | ||
| Updated state | 50h | 10h | 80% |
If you decrease Work by less than the current value for Remaining work, then Remaining work will be set to 0h and % Complete to 100%.
| Work | Remaining work | % Complete | |
| Initial state | 100h | 60h | 40% |
| Wechseln | 30h | ||
| Updated state | 30h | 0h | 100% |
Das Verändern vom Verbleibendem Aufwand aktualisiert % abgeschlossen
| Work | Remaining work | % Complete | |
| Initial state | 100h | 60h | 40% |
| Wechseln | 40h | ||
| Updated state | 100h | 40h | 60% |
**Das Verändern von % abgeschlossen aktualisiert Verbleibenden Aufwand **
| Work | Remaining work | % Complete | |
| Initial state | 100h | 60h | 40% |
| Wechseln | 60% | ||
| % Complete updated | 50h | 40h | 60% |
Status-based mode
These changes do not affect status-based progress calculation mode, in which the % Complete value for a work package is set by the status.
Please note however that since version 14.4, you can freely assign any % Complete value for any status without being limited to 10-percent increments. This was something that many of our users requested.
Helpful hints on derived values
OpenProject 14.6 has also improved the Work estimates and progress pop-over to make things even clearer and easier to understand.
When you add, edit or remove a value for Work, Remaining work or % Complete and this affects the value of another field a helpful caption will indicate what has changed and why.
New admin settings for calculation modes
Currently, when you display a hierarchy in table view, totals for the % Complete column only include values for work packages that also have a value for Work; those that do not are ignored. This was not ideal for some of our users, who wanted % Complete totals in a hierarchy without having to also enter values for Work.
Starting with version 14.6, this will once again be possible.
Administrators will see a new page under Administration → Work packages called Progress tracking with three settings:
- Progress calculation mode lets you select between work-based and status-based modes.
- Calculation of % Complete hierarchy totals lets you pick between:
- Weighted by work: The total % Complete will be weighted against the Work of each work package in the hierarchy. Work packages without Work will be ignored (current behaviour)
- Simple average: Work is ignored and the total % Complete will be a simple average of % Complete values of work packages in the hierarchy
- % Complete when status is closed lets you chose what happens to % Complete when you close a work package (even in work-based mode):
- No change, where the value of % Complete will not change even when a work package is closed
- Automatically set to 100%, where a closed work package is considered complete.
Migrating from 14.x
If you are upgrading to version 14.6 from version 14.x, none of your existing values for Work, Remaining work and % Complete will change. They will be preserved as is.
The only difference will be that % Complete will be manually editable again and you administrators have new settings available to them under Administration → Work packages → Progress tracking.
Migrating from Pre-14.0
Some users told us they were refraining from updating to version 14.0 because they did not want their manually-entered % Complete values to be overwritten. If this is your case, we recommend upgrading directly to version 14.6. This will preserve your existing values of Work and % Complete in most cases.
The following cases detail what will happen in 14.6 in a number of different scenarios. They concern the field Work, Remaining work and % Complete.
Case 1: Only one value set
If only one field out of three fields had a value set (Work, Remaining work or % Complete), one of two things can happen:
- If only % Complete was set, nothing will change. Work and Remaining work remain empty.
- If only Work was set, Remaining work will be set to the same value as Work and % Complete will consequently be set to 0%.
- If only Remaining work was set, Work will be set to the same value as Remaining work and % Complete will consequently be set to 0%.
Case 2: Two values set
If only two of the three fields had a value set (for example, only Work and % Complete; or Work and Remaining work), the third field will automatically be derived and a new value set in 14.0.
No existing value will be overwritten or changed. Some examples:
Case 2.1: Remaining work was not set
| Work | Remaining work | % Complete | |
| Pre-14.0 | 50h | 60% | |
| New value set with migration | 20h | ||
| Post 14.0 | 50h | 20h | 60% |
Case 2.2: % Complete was not set
| Work | Remaining work | % Complete | |
| Pre-14.0 | 50h | 20h | |
| New value set with migration | 60% | ||
| Post 14.0 | 50h | 20h | 60% |
Case 2.3: Work was not set
| Work | Remaining work | % Complete | |
| Pre-14.0 | 20h | 60% | |
| New value set with migration | 50h | ||
| Post 14.0 | 50h | 20h | 60% |
Case 3: All three values set
If a work package had all three values, then there are two possible scenarios:
Case 3.1: All three values are consistent
If all three values are consistent and in sync (i.e, % Complete accurately reflects the relationship between Work and Remaining work), all existing values will be preserved and no changes made.
Case 3.2: Remaining work is higher than Work
Since Remaining work can never be higher than Work, it will be updated to preserve % Complete:
| Work | Remaining work | % Complete | |
| Pre-14.0 | 10h | 20h | 5% |
| New value set with migration | 9.5h | ||
| Post 14.0 | 10h | 9.5h | 5% |
Case 3.3: Remaining work is lower than Work but % Complete is inconsistent
If all three values exist and Remaining work is less than Work but the three values are inconsistent (% Complete does not reflect the relationship of Work to Remaining work), % Complete will be updated to make them consistent:
| Work | Remaining work | % Complete | |
| Pre-14.0 | 10h | 8 Std. | 50% |
| New value set with migration | 5h | ||
| Post 14.0 | 10h | 5h | 50% |
Thank you for your feedback
These changes are a direct result of user feedback.
We want to extend our heartfelt thanks to everybody who took the time to reach out to us and explain why the changes made in 14.0 did not work for them. As an open source company, we are grateful for our engaged and passionate community of users.
We are also working to improve our internal processes for gathering and processing user feedback. This includes conducting more user research and conducting more tests as part of our design process. In the coming months, we will publish more information on how we plan to create even closer links with our user community.
In the meantime, as always, feel free to join our public OpenProject Community instance, where you can follow feature development in real time, create feature requests, report bugs and provide feedback.
