Predecessor Best Practices

Hi Jodi, Yes it's possible to have 13 predecessors and even reasonable depending on your project (size, dependencies, etc.). Whether it's accurate is probably more the question and that is up to you. If the task in question isn't truly dependent on all the predecessors, yes it should be changed. Because as you stated this will impact your timeline and your critical path. And you always want your plan to reflect the truth (as best you can). Grouping or using a Summary Task as a Predecessor (or successor) is totally a style preference. I've heard the argument you shouldn't use the Summary Task as a Pred and have even seen tools that don't allow it. But I've found it to be useful and easier in many cases. So I've done both, and I like using the Summary task when necessary (then I have one Pred, instead of 13). The risk is that there are Tasks underneath that Summary task that aren't truly a predecessor and you have to be sharp enough to catch it, otherwise your plan is inaccurate. But you can make the same mistake my missing preds. So basically it's important to keep a close eye on the preds in general otherwise you can be off course without knowing it. Let me know if that helps or if you need more detail. I can talk Preds all day �� .

I think Vic hit on all the high points but to share some complementary thoughts: As Project Managers, we like to try and deal in absolutes. And in some cases, predecessors are in fact absolutes and it is impossible to start Task B until Task A is 100% complete. However, I rarely find that is the case as my projects have to remain flexible. In my firm, the policy states that QA Testing must be 100% complete before a deployment can take place. In reality, it's just not the case. One scenario/environment/use case/defect always lags behind and we go to Production knowing we have to validate one final scenario as quickly as possible. Now, I could expand the QA testing task into 10 tasks, one for each scenario...but they are all assigned to the exact same people which means they'll never be managed/have time charged to them properly at that volume. So, I fake it. I either remove QA as dependency on my Deployment task or I set the end date of Test task to be when I NEED it to be for my Deployment task to work and QA continues charging time to it long after the End Date. Neither are "right" but you gotta do what works (our mantra is the fewer tasks the better, both from a WF performance standpoint and a Keep It Simple standpoint). Also, philosophically I agree with Vic, if you are going to group Predecessors, never use the Parent Task, always create a Summary task that all the Predecessors tie to (I always think Parent Task should be in bold at the top of tasks, where as Summary tasks are at the bottom and never in bold). A former mentor did it that way and he had "reasons" that were really nothing more than personal taste, but that's what has stuck with me. From a WF standpoint, it's a lot easier to remove a Predecessor from a Summary Task then to try to manipulate a task out of a Parent Task and not mess up the indentation. Jason Maust McGuireWoods LLP

I would say that it's certainly not out of the ordinary to have that many predecessors and especially if it is a critical task, it makes sense that items need to be locked down before it can be moved forward. Is there a concern with your project that this will make it unable to move forward in a timeline or is it just a circumstance you've never encountered before? You mentioned you've determined that all of the predecessors are not dependent on one another, so perhaps your concern is that 13 paths have to be completed before the critical task can be completed? If your question was truly is it normal to see that many predecessors, I would say it depends on the business, but yes. Especially if it is a task that is quantified as "critical" to the project, because you need to have as much locked down as possible to make that as accurate and effective as possible. If you have other concerns or questions, please let everyone know. It seems that you have a grasp of the system and know how to make it work, but just had more of an open-ended project management question. Emma Hendren Pivot Point International

In the terminology I've been taught, a Summary Task and a Parent Task are the same thing (MS Project calls it a Summary Task, WF a Parent Task). If it's at the bottom (and not highlighted), I think what would be more of what is called a Milestone Task (in PM terminology, not the WF setting). And then usually I've seen it where all the prior tasks in the group are linked to that Milestone and then use the Milestone as a predecessor for subsequent tasks. And I agree, that can be super cumbersome especially in WF. Which is why I went back to using the Summary/Parent task when needed. As you mentioned it's all preference and your personal PM artistry �� . And I agree you adjust your plan as needed to reflect reality while you're in progress. But initially I would still structure the plan with those hard predecessors as it will inherently build in some contingency for you in your timeline and give you a little cushion.

Thank you everyone for the input! Helpful & much appreciated! Jodi Biscevic GM Financial - International Operations

VIc, we actually refer to them as Milestone tasks as well at my current firm. Our preference is to always summarize a group of tasks with Milestones (but, as you pointed out, not WF milestones) and not to use the Parent tasks. Jason Maust McGuireWoods LLP

Cool. Thanks. Yeah I've done both (used the Parent/Summary and used the Milestone). Totally a preference thing. I went back to using the Parent/Summary in Workfront (when appropriate of course) because I got tired of entering all the preds in the Milestone. Felt like it was too time consuming when I could just use the Parent/Summary. But I understand the merits of both methods. Cheers.