New plan items: how to avoid start (and finish) dates in the past

doctor_i
doctor_i
edited 12/09/19 in Smartsheet Basics

Hi all - I'm a relatively new user and a little stumped figuring out how to best handle this scenario:

1) A project sheet has dependencies are enabled.

2) The project team identifies a new task they want to track; that task is ready to start (there are no dependencies).

3) The task is added to the sheet with an estimated duration. No predecessors are set.

Observed: the start and end dates auto-fill based on the duration and the first date of the project. Both are in the past. Any subsequent tasks that will be dependent on this one will be inaccurately planned.

I've done a couple of quick searches in the community and review multiple help topics but was unable to determine a best practice with Smartsheet and am a little stumped on the paradigm. Should new tasks be dependent on the date they are added somehow? It does not appear that I can force the start dates with dependencies enabled. 

Thank you,

Doc

    

 

Tags:

Comments

  • Paul Newcome
    Paul Newcome ✭✭✭✭✭✭

    Have you experimented with adding lag/lead time? I personally do not use dependencies because the restrictions they create make some of the things I need to do impossible, but adding lag/lead time may resolve your issue.

  • Thanks. I've played with lag time but have two blockers there: 1) can't add lag time unless there is a predecessor and 2) there is a little bit of trial and error to get the lag time set to just the right number of days to pin the start date to a particular calendar day... not an elegant work flow.

    I'll look up lead time and see what I can do with that. 

  • Paul Newcome
    Paul Newcome ✭✭✭✭✭✭

    Ok. Hopefully you are able to figure something out. It does seem to make sense that a task with no predecessor would start on the first day of the project if there is no "dummy time" built in.

     

    As I previously said... I don't do much with dependencies enabled, but one thing I have heard is using a dummy task as a time filler, but now that I think about it, that almost seems as if it is simply the same as using lag/lead time. 

     

    Hmm...

  • More detail: what I think is going on is that the added items are children of a parent item that has a predecessor, and thus they are forced to inherit the start date of the parent.

    I'm not crazy about this "feature". I don't think a child item should not be forced to inherit it's parent's calculated start date. Rather, the child item should be allowed to have a fixed start date and duration (or any two values) and have the third value calculate.

  • Paul Newcome
    Paul Newcome ✭✭✭✭✭✭

    I was under the impression that the parent was a summary of the children rows when dependencies were enabled and not a driving factor...?

  • Doesn't seem to work that way when the parent has a predecessor set. But I would expect different behavior. My expectation is that the parent's dependency would prevent a child task from starting before the dependency is met... instead, it forces the sub-task to start when the dependency is met. That's just non-sensical and this is a great example of why.

    I'm adding a new task to a parent container that is already underway, and smartsheet is forcing the task to start in the past.  

    A defect?

  • Paul Newcome
    Paul Newcome ✭✭✭✭✭✭

    At this point my best suggestion would be to reach out to support and see what they have to say unless someone else here on the community is able to provide a little more insight.