Part II – Dependency Relationships
Having one task that is a predecessor to many tasks may be valid, it may be the result of redundant dependencies, or it could be the result of not really understanding the work. So while it appears on the surface to be an issue, I think you’re going to need to dig into these relationships, understand why they are there, determine if that individual relationship is value, and clean up un-needed relationships one by one.
Are there valid reason for these dependencies? For example, construction of the house really can’t start until the foundation is completed. Once completed a multitude of task can then start.
Are these unnecessary dependencies. For example, looking at a simple example with tasks A-D that are pure waterfall, the only dependency links required are A-B, B-C, and C-D. However, some PMs will add redundant relationships such as A-C, A-D, and B-D. As a result, Task A now appears to have 3 dependencies. These redundant relationships can be removed with no schedule impact.
Dependencies can also be the result of not really understanding the work. I’ve been involved in several projects where task relationships assumed at the beginning of the project have completely changed once the team has a better understanding of the tasks.
Unfortunately, I don’t know of any magic bullet that will clean up this scenario for you.