Skip to Main Content
Status Future consideration
Categories Features
Created by Matt Case
Created on Feb 16, 2017

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.

  • Attach files
  • Matt Toburen
    Reply
    |
    Jan 26, 2024

    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).

  • Guest
    Reply
    |
    Jun 2, 2023

    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.

  • Max Jackl
    Reply
    |
    Feb 1, 2023

    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.

  • Guest
    Reply
    |
    Jan 3, 2023

    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.

  • Guest
    Reply
    |
    Nov 1, 2021
    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 )
  • Julius Tancinco
    Reply
    |
    Sep 15, 2021

    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.

  • Julius Tancinco
    Reply
    |
    Aug 12, 2021

    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.

  • Travis Fahey
    Reply
    |
    Jul 15, 2021

    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.

  • Don Fifer
    Reply
    |
    Oct 31, 2019

    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.

  • Guest
    Reply
    |
    Jan 26, 2018

    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.