I have recently come across a plan where nearly 30%+ tasks in a plan were assigned to one single task in the plan. The schedule was 5K lines.
I know this mapping was creating issues with Critical Path and also huge slack for each of the tasks.
What are the other issues that we can potentially face with such a plan?
Whats the pitfall with mapping dependencies with a summary task?
Lets talk about linking summary tasks first.
While the concept sounds like it could make developing the schedule easier, applying predecessor/successor relationships to summary tasks is not recommended for the following reasons.
1. It can create dependency logic that is difficult to follow
2. It may produce logic errors and create circular relationships
3. It will result in inefficient use of resources
1) Dependency Logic that is Difficult to Follow
Within your schedule, there will be direct task to task relationships such as Task C following Task B. However there will also be indirect relationships at the summary task level. For example, Summary1 is a predecessor of Summary2 which means that no tasks within Summary2 can start until ALL tasks in Summary1 complete. When debugging a schedule constructed in this manner, tasks may show no predecessor and/or successor which means that in order to determine why a task is scheduling where it is, you now need to start following indirect relationships.
2) Logic Errors and Circular Relationships
Assume we have a schedule where Summary1 contains tasks A-C and Summary2 contains tasks G-K and Summary1 is a predecessor of Summary2. Because there are no direct dependency relationships between task A-C with any task G-K it’s easy to see how a PM can easily add task relationships between a task in Summary1 with a task in Summary2 that could violate the relationship of Summary1 being a predecessor of Summary2. Attempting to create such a task relationship will generate an error and because of the summary level indirect relationships, complicates the debugging process.
3) Inefficient use of Resources
This is one of the biggest issues. Assume Joe is assigned to Task A in the Summmary1 group and he is also assigned to Task G in the Summary2 group. When scheduled, Joe can start Task A today, but Task B will not be scheduled until ALL of Summary1 tasks are completed, which could mean Joe now has a gap of days/weeks where he is assigned no work.
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.
Hope these posts helped.