Parent Tasks as Predecessors

I'm not sure what's considered best practice.

We've never used predecessors on parent tasks (either in WF or in our previous systems), as most of our individual tasks are dependent upon the one above it (occasionally we have tasks running in parallel with each other or standalone tasks).

I suppose it could be a problem if (using your example) you were looking at a Parent Task in isolation (like in a report), and it wasn't obvious what the reason for a delay was--i.e., you'd have to investigate which task under the parent predecessor was the hold-up.

I'm curious as to what reasons there are for not doing it, but if it's working for you, I'd say continue.

We used to do the same thing that you are currently doing, but then we realized that teams were not getting email alerts for when their child tasks was ready so we moved all the predecessors to be on child tasks. It was causing a lot of issues with teams not getting their work done on time as some users liked receiving email notifications versus looking at home or a report.

I've had Workfront calculate dates incorrectly when doing this.  We typically give most tasks an As Soon As Possible constraint.  I've found that if the previous parent task and the last task (in your example, giving task 5 the predecessors of task 1 and task 4) seems to make dates calculate correctly.  

I never looked into why this was happening because it's an easy workaround for me.

Lots of people use Workfront for things that Workfront developers (and now Adobe) never intended and doesn't even know about. If it works well for you, use it. Don't let it spook you.

If it looks good, it IS good!

While I like the use of parent tasks as predecessors in the way you're showing, I have found it to create a couple points of confusion with end-users.

1. Newer team members don't always understand why tasks 6-8 aren't 'Ready to Start' because they don't always understand the parent-task affect on it's children
2. If you have task reports built that filter out parent tasks, it can sometimes be difficult to see why one isn't ready to go
3. If Parent Task 1 is completed, allowing child tasks 6-8 to go forward but then the PM goes back and inserts another task under Parent Task 1 then the 'ready' status of Parent Task 2's children appears to flip back and forth. This is the biggest hiccup we've had so far, I had two teams REALLY mad at each other until we figured it out. 
4. If you use multiple sets of nested parent/child tasks, this can be really frustrating in creating dependency loops for a less experienced PM. For lengthy project plans, it can be very visually difficult to trace backwards. 
5. If you have a case like your setup, but where 7 is also dependent on 6 and 8 dependent on 7, this also leads to confusion on why a task wasn't showing up in someone's queue as expected. The PMs perceived that they'd marked task 6 complete, so 7 should be ready to go without understanding that parent task 1 was also in the mix. 

Some of those can be handled with enhanced report/view designs, but #3 is the one that's genuinely caused the most issues for us.

I've used a parent task as a predecessor to a child task before, but only in a specific, low-stakes project workflow that I own where I know all the child tasks that a parent task encompasses. I probably wouldn't use a parent task as a predecessor in most workflows – one reason being that it can be helpful for people to see each individual predecessor in their task details so they know what has been done before.

So in the example you provided, if you wanted to use Parent Task 1 as a predecessor, I would set it up like this: