Content
View differences
Updated by Jens Ulferts 12 months ago
**As** a project portfolio manager
**I want to** have phases adjusted automatically based on changes of preceding phases
**so that** rescheduling is simpler and less error prone.
Context: Gates are by now part of a phase so they do not need to be scheduled separately (see ##61952)
### Acceptance criteria
* Phases are automatically (re)scheduled to the extent the information provided by the user allows for. Whenever the finish date of a phase changes, the succeeding phase's start date is updated to be on the working day after the date selected to be the finish date of the predecessor.
* If the succeeding phase has a finish date set and had a start date set that is now changed, the finish date is updated to preserve the duration of the succeeding phase. The duration is the number of non working days between the start and the finish dates (both dates included). The finish date might thus be moved into the future or the past.
* If the succeeding phase has a finish date set but did not have a start date set before, no duration existed before. Therefore, the successor's finish date does not need to be updated as long as it is at least on the date of the start date. If the finish date is before the newly set start date, the finish date is updated to be on the same date as the start date.
* This case can happen if the user decides to not start at the beginning of the project lifecycle when inserting dates but rather set e.g. a finish date for the second phase first and only then sets dates for the first phase.
* This continues until the end of the chain of phases is reached.
* Automatic scheduling happens fully automatic. The user is not asked for confirmation.
* Even if the user hasn't yet specified the dates for durations of all the phases, automatic scheduling will start as soon and to the extend where durations of succeeding phases are present.
* Automatic scheduling only happens forward. Therefore, setting a finish date on a phase that is before its start date will result in an error being displayed (The front end should also prevent this from being possible). The start date will not be automatically changed. Even if the provided finish date is not before the start date, the duration is not kept in this case, but changes.
* Phases active in a project are considered to be following each other based on the sort order in the administration.
* In case a phase is inactive in a project, the next active phase is considered to be the successor. Multiple inactive phases can be ignored that way.
* Inactive phases are not scheduled.
* If the user removes the finish date of a phase, the start date of the succeeding phase is kept so that the duration is kept as well.
* OLD: ~~If the user removes the finish date of a phase, this also removes the start date of the succeeding phase. The finish date of the succeeding phase is not touched in this case.~~
case.
* If a phase is activated, depending on its position in the sort order, it may then automatically receive a new start date.
* If it already had a duration (start/finish date set), its finish date would then also be updated to keep the duration. This might then trigger a rescheduling of succeeding phases.
* If it had no duration, the start date might be set but the finish date would remain unset. This might in turn unset the start date of the succeeding phase.
* If a phase is deactivated, the dates of the deactivated phase are kept. The new chain of active phases is then scheduled from the position of the deactivated phase onward.
* Adding or removing non working days triggers a rescheduling of all phases in all projects spanning the affected days. In turn, successors of those phases (and successors of those, ...) might also be rescheduled. The goal in this case is to keep the duration unchanged.
* Deleting, adding, reordering phases in the global administration potentially affects projects since they might already have phases active and scheduled. For now, no automatic rescheduling happens in this case. But the first time the user touches the lifecycle, the schedule is updated. Again, the goal is to keep the duration of the phases unchanged.
### Out of scope
* Backwards planning
* Durations displayed in the UI
* Gaps (implicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) are not allowed.
* The lag (explicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) cannot be set by the user currently. By that, it is effectively always 0.
* This is subject to change in a later feature.
**I want to** have phases adjusted automatically based on changes of preceding phases
**so that** rescheduling is simpler and less error prone.
Context: Gates are by now part of a phase so they do not need to be scheduled separately (see ##61952)
### Acceptance criteria
* Phases are automatically (re)scheduled to the extent the information provided by the user allows for. Whenever the finish date of a phase changes, the succeeding phase's start date is updated to be on the working day after the date selected to be the finish date of the predecessor.
* If the succeeding phase has a finish date set and had a start date set that is now changed, the finish date is updated to preserve the duration of the succeeding phase. The duration is the number of non working days between the start and the finish dates (both dates included). The finish date might thus be moved into the future or the past.
* If the succeeding phase has a finish date set but did not have a start date set before, no duration existed before. Therefore, the successor's finish date does not need to be updated as long as it is at least on the date of the start date. If the finish date is before the newly set start date, the finish date is updated to be on the same date as the start date.
* This case can happen if the user decides to not start at the beginning of the project lifecycle when inserting dates but rather set e.g. a finish date for the second phase first and only then sets dates for the first phase.
* This continues until the end of the chain of phases is reached.
* Automatic scheduling happens fully automatic. The user is not asked for confirmation.
* Even if the user hasn't yet specified the dates for durations of all the phases, automatic scheduling will start as soon and to the extend where durations of succeeding phases are present.
* Automatic scheduling only happens forward. Therefore, setting a finish date on a phase that is before its start date will result in an error being displayed (The front end should also prevent this from being possible). The start date will not be automatically changed. Even if the provided finish date is not before the start date, the duration is not kept in this case, but changes.
* Phases active in a project are considered to be following each other based on the sort order in the administration.
* In case a phase is inactive in a project, the next active phase is considered to be the successor. Multiple inactive phases can be ignored that way.
* Inactive phases are not scheduled.
* If the user removes the finish date of a phase, the start date of the succeeding phase is kept so that the duration is kept as well.
* OLD: ~~If the user removes the finish date of a phase, this also removes the start date of the succeeding phase. The finish date of the succeeding phase is not touched in this case.~~
* If it already had a duration (start/finish date set), its finish date would then also be updated to keep the duration. This might then trigger a rescheduling of succeeding phases.
* If it had no duration, the start date might be set but the finish date would remain unset. This might in turn unset the start date of the succeeding phase.
* If a phase is deactivated, the dates of the deactivated phase are kept. The new chain of active phases is then scheduled from the position of the deactivated phase onward.
* Adding or removing non working days triggers a rescheduling of all phases in all projects spanning the affected days. In turn, successors of those phases (and successors of those, ...) might also be rescheduled. The goal in this case is to keep the duration unchanged.
* Deleting, adding, reordering phases in the global administration potentially affects projects since they might already have phases active and scheduled. For now, no automatic rescheduling happens in this case. But the first time the user touches the lifecycle, the schedule is updated. Again, the goal is to keep the duration of the phases unchanged.
### Out of scope
* Backwards planning
* Durations displayed in the UI
* Gaps (implicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) are not allowed.
* The lag (explicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) cannot be set by the user currently. By that, it is effectively always 0.
* This is subject to change in a later feature.