Once we have our work breakdown structure, the next step is to think about the dependencies among the actual activities. The dependencies will give us the logical flow of the project and ultimately, they will allow us to find out the duration of our project. So how do we think about the dependencies and how might we visualize the dependencies among the activities? Well, in order to go through the basics, we're going to start with an example. And we're going to start with the work breakdown structure of a simplistic project, just to walk through how the dependencies might emerge. So here's an example. This is a startup project and again, this is a simplistic high level view of a, of a project just to give us the basics. In this case, our startup project has the following activities. It has creative step, a strategy, information technology, fundraising, marketing and sales, finance and HR. So what is the dependency among them and what is the sequence in which I can execute these ex, specific activities? One useful way to think about the dependencies is in the form of a design matrix. The design matrix typically has the list of activities in the column and the list of the activities in the rows. And, for instance, in the design matrix that we're looking at, we have the following. Task four is dependent on task one. Similarly, we see from this design matrix that task five depends on task one and task two. Task six depends on task one and task two. Task seven depends on five and six. And finally, eight depends on four and six. Now, there's a lot of information in this design matrix. First, we can easily spot whether we have circular relationships, meaning two tasks that are continuously dependent upon each other. That will imply that we're going to do some rework along the way. Also from the design matrix we can spot how complex a project is. If many of the activities are dependent on previous activities, there's going to be a lot of iteration and our project is going to be more complex, and we will need to plan accordingly. Useful, visual way to depict the dependencies. Some people prefer to see it in a table format. And so we can list for each activity the set of predecessors that it has. Similar information, but in a different way. Different presentation. In this case, fundraising depends on the creative. What's important and what's helpful is, as we look at these dependencies, we can get everyone's buy-in and support. The individuals who are going to execute these tasks can agree that indeed they depend on others before them. They can also make sure that they understand who depends on the output from their tasks in order to ensure proper flow of the project activities. There's a third way to look at the dependencies and it's probably my favorite way, and that is the network diagram. Again, a visual representation of our project, and the flow of the information, and the physical aspect of the tasks and the materials that we need to accomplish along the way. In this case, we see, once again, the same links exist, in which creative feeds into marketing, sales, and fundraising. Now you might notice, in this network diagram, that IT is left hanging. it doesn't depend on anything, nor does anything depend on it. But that is technically not exactly correct, because the process cannot be completed until the information technology is installed and operates properly. And so one recommendation that you should be thinking about is that as you look at your network diagram, make sure that at the end of the day there are no hanging tasks. You have one endpoint for your project. In a similar fashion, you probably have one starting point that kicks everything off. And while I could do IT, strategy and creative at the same time, they're all going to be dependent on the start of our project. And so, we're going to add two nodes to our project. The start of the project and the end, and we no longer have any hanging tasks in our network diagram. Finally, as we think about our dependencies, there are different types of dependencies that we could think about. The most basic one and the one that you, typically, most people use, and I recommend using it, is a simple finish to start relationship. You need to finish Task A in order start Task B. Typical example of that might be software development. You need to finish the coding, most often, in order to start the quality assurance. Another type of relationship, however, could be a finish to finish. Two tasks that need to finish together. During a wedding, the bride needs to get ready and she needs to finish her preparation at the same time that she arrives, for instance, with the minister or the rabbi. In my case the rabbi was late, and I finished sooner. Another type of relationship that we might see is a start to start. Two activities that might need to start and work simultaneously together. Typical examples are construction projects, where we might need to cement and pave at the same time. And finally, a slightly more complex relationship might exist where we have a start, a start implying a finish. We cannot technically finish an activity until we start the next. More confusing, but again, typically holds in a situation where we have physical materials and we need to hold together for instance a skeleton by starting another activity. So as you think about your project, work with the correct dependencies, and find the visual that works best for you.
