Updating a feature's dates should automatically adjust dates of features with downstream dependencies

For this comment, please see notes shared with your support team....
Many of us (I'm assuming many), use Aha for more than just Feature road maps, and while we all want to use the buzzword agile, sometimes the reality is, labels aside, waterfall is appropriate and good ole fashion project management. For us:

It's not just a road map, it's a project schedule. I think this is a distinction that is important for Aha moving fwd. We know Aha is a purpose driven tool for all things Road map, but you guys are very close to being a strong option as a PM tool. So many customers need project methodology to manage/guide the deployment of their products, especially B2B, enterprise type solutions, etc. We fit that mold, so our use of Aha and our further desired use is very practical. Every company in our industry needs this framework (Product hardware + product software + config (project tasks) + services (custom SOW based project tasks) to deliver value to a customer. This is where a lot of our needs are coming from and we'd prefer to do it all in Aha, not split between Aha and MS Project (and we're currently integrated with JIRA for the engineers' work).

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.

Hey everyone I'm currently evaluating AHA and I find it amazing that dependent dates don't auto adjust in the Gantt view. In my mind the Gantt view is where you see the implications of decisions made. The argument that auto moving would be bad because "collaborate as a team" seems really strange to me...this is what you have to do regardless of the tool...collaborate...and the start of that discussion is knowing it has to happen... I.E knowing that recent changes in one item had implications...and now the team has to work on this together. Not having an auto updating Gantt chart is to me avoiding the discussions that has to happen. ( and a potential deal-breaker for me )

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.