Dependency is a Risk to be Managed

Anyone in project management knows that dependency is a risk. When tasks are using the most common finish-to-start dependency, the delayed completion of predecessor task introduces a risk to the project. When resources are unavailable to start the tasks or their capacity is reduced to work on a project, their dependency on other project commitments poses a risk. Waiting time on processes, such as workflow approval, or not having a clear process, such as a lack of documented code review guidelines, introduces dependency on others. Technical architecture decisions requiring a dependency on other SMEs or dependency on training due to the lack of knowledge on the technology or tools adds risk. Organizational cultural considerations on budget approval, procurement considerations, or hiring processes are dependent on stakeholders for decision-making. 

So, as you can see, there are people, process, technical, and organizational dependencies either deliberately introduced (hard logic) or mandatorily included (hard logic) can be looked from internal and external considerations. The internal considerations may be within the team or within the company. As a result, we can come up with a table as below. Given below are some examples of dependencies that may be a risk.

How do you think this will work for your organization? Share your thoughts.