RELATED IDEAS
Updating of Feature dates should automatically adjust dates of features with downstream dependencies
Summary:
This comes from a project management use case where a team manages a set of activities/tasks through Features for a project and the activities have a very sequential delivery with fixed offsets between each activity. The plan starts off with loosely defined dates and dependencies between each activity. For example, Activity 2's due date will always need to be offset to complete 2 weeks after the scheduled due date of Activity 1. As the Activity 1 due date is solidified and updated (pushed out a week), the desire is that the week 2 activity would automatically push out by the 1 week to maintain the desired 2 week offset in due dates.
These dependency relationships will be maintained IF you modify the dates via drag/drop/stretching on the Releases -> Overview/Roadmap page. However, if you instead modify the dates in the drawer page, it will not shift the downstream dependency activities/features. Instead, any violations of the Finish/Start dependency relationship are highlighted in Red but all downstream Features/Activities maintain their previous dates. .
Desired behavior: Ability/option to have the downstream activities/features start on and due on dates to adjust when modified in the drawer page. Admittedly, I can see where you might not want date changes to automatically push out downstream dependencies as you may want to instead view the changes and collaborate on them as a team to decide whether you want to push things out, reduce scope, etc. However, in some instances when you have a team managing a very large number of projects, they want to be able to automate as many processes as possible and minimize manual rework. Having the option to make automate these dependency related dates regardless of modifying in the Releases Overview/Roadmap views or in a drawer page would be ideal.
Suggestion for implementation:
When an Activity/Feature has a dependency, allow the dates configuration to have options, just like progress field is today:
Manual : current behavior, setting start and end dates
From dependency: Replace the start date field by a dependency dropdown (that would have the current assigned dependencies as options, on the correct "direction") and duration instead of end date. Keep in the background the start and end dates, for backward compatibility, but make those fields now calculated.
So manual changes to one activity would then cascade the calculation of all it's dependencies that are using the calculation. This can be a recurring function, so all project gets processed as needed. Circular reference controls are needed, if not already existing.
If an activity is using the "from dependency" option and the selected one is deleted/removed, automatically set it back to manual and use the current calculated dates from it as values. There is no need to cascade this, as the other records would not be affected. User would just see an interruption on the dependency chain and can fix/update as needed.
This is a must IMHO for critical path tracking and estimations.
I wish there was more I could do to push this to the top of the list. I can't believe this was submitted in 2017, and still hasn't been implemented. This is such important and basic functionality for anyone who has more than a handful of Features.
I couldn't agree more with the post below mine. This is simply a matter of overhead. We have 13 staggered (preliminary) releases in one project; for me to have to sit and individually move each one of the 12 subsequent releases as a result of the ETA of the first release changing is a bit absurd, with all due respect.
To elaborate - if an activities date was changed and it had cascading activities linked by dependencies, today I would have to edit each cascading activity to account for the changed date to add or subtract additional days to ensure they maintain their original duration. This becomes more time consuming and error prone as the number of cascading activities increase.
I second Travis Fahey's comments. We too WANT to consolidate into one PM tool but this is a major barrier for our existing PM's to get onboard with using AHA as this something they are accustomed to with other tools like MS Project.
We have moved away from more robust project management tools in favor of consolidating all of our product and delivery data in one environment. One of the biggest sacrifices we made when that change occured was our ability to have dates auto-adjust based on a dependent date finishing early and late. Without that key functionality, our PMs are spending many more hours manually calculating new dates, which is in direct conflict with why these Project Management Information Systems exist. You are missing one of the most important pieces of functionality, which would make your product world class in the project management space.
I am new to Aha!, so excuse me if the vocabulary I'll use is not completely accurate. However, I would definitely be interested in the functionality Matt Case references. I attempted to setup a template that basically does this using Milestones and Tasks, but found it to be inconsistent (but that could be due to my novice status at this point)
I would vote yes on having this feature.
I agree this is a current limitation and frustration since the app is inconsistently applying dependency rules. If you set dependencies and use the Release Overview view to extend feature durations and/or dates, any dependent feature is automated moved out as you would expect (as described in original post here). But if you make the same update in a list view, those automated rules don't get triggered, making the app inconsistent. Doesn't seem right that the view dictates the business logic applied. Our project teams often like to use the Feature List view in planning/status meetings since you can view more information and do bulk updates. We often need to adjust dates and durations as part of this but since the dependent dates do not adjust automatically, we are forced to go into the Release Overview screen to make adjustments and see the downstream impact of our decisions - make it pretty disjointed right now.