Documenting Dependencies
By: Rick Edwards
A good carpenter never blames his tools. There is also an aphorism “it is the poor musician who blames his instrument”. Why do so many good project managers blame their scheduling tool when their project schedule doesn’t fit their desired schedule?
Project managers often struggle with documenting task dependencies utilizing the technology of the day. In an environment where working “in-parallel” and “multi-tasking” is the norm, sequential relationships are hard to find. Often, when project managers do define sequential relationships in their project plans, their WBS becomes so large and complex that the schedule becomes difficult to read. Some project managers solve this problem by utilizing Start-to-Start, Finish-to-Finish and Start-to-Finish dependencies to help conceptualize these dependencies in the project plan. While this works to a degree, it does add complexity to the plan and makes critical path analysis a bit cumbersome.
It has been my experience that it’s best to design the WBS to the level where I can build “soft” sequential relationships. These sequential relationships can be as soft as placing relationships on tasks that I would prefer happen in a particular order. These relationships are admittedly arbitrary. However, this practice allows the project manager to identify when the project might experience problems, while maintaining a reasonable level of complexity within their WBS.
One important caveat to this approach is that it is extremely important to document in the project scheduling tool the nature of the relationship. Is it a hard or soft dependency? Is it technology or resource related? If it’s soft, what risks would be incurred by the project if the dependency was broken. All of this information must be well documented. This will pay huge dividends later when you have to make trade-offs with your schedule.
How do you manage your dependencies in your project plan?