One of the most valuable skills I learned when I became a project manager was how to analyze the dependencies in a project. The term “dependencies” is project-management jargon for the fact that some of the tasks involved in any undertaking depend on each other. To better understand the concept, think about baking a cake. It makes no sense to put the cake in the oven before you’ve mixed in the flour. The “put the cake in the oven” task is dependent on the “mix in the flour” task.
Analyzing the dependencies of any project — what has to happen before you can “put the cake in the oven” — is actually not a particularly hard thing to do. The problem is: We don’t do it often enough. Or at all. So perhaps it’s more accurate to say that the most valuable thing I learned from my project-management training was how to make analyzing dependencies a habit.
I do that analysis constantly now, almost without realizing it. Not only do I understand the dependencies of all my work projects, but I am also likely to start working through dependencies at home — for example, when my family is planning an outing. That’s not because I’m a control freak who wants every minute of her day scheduled: I don’t. And my days are not that scheduled. It is because the habit is so useful.
Most of the time, figuring out the dependencies in a work project will not be as obvious as the cake example, but even when you’re having trouble spotting them, they are there. In fact, intuitive understanding of dependencies is one of the things that makes someone who is experienced more effective than a novice. The experienced person can essentially see the future, predicting a delay in a certain task based on what’s happened before.
Even when you have no prior experience with a particular task, taking a deliberate look at a project’s dependencies can help you foresee the potential fallout ahead. And that allows you to respond more strategically to the changes that inevitably arise.
For example, if Task A is taking longer than expected, should you keep going? Or should you temporarily set it aside and move to Task B, which was previously scheduled to start at this point? The best answer depends on what any delays in Task A and Task B will do to the other tasks downstream. Sometimes a project can absorb a delay without much change to the overall timeline. Sometimes the delay will produce a catastrophic cascade of problems that derails the entire thing. Most times, the effect is somewhere in between. As you get used to thinking about dependencies, you will usually be able to choose which option will cause the fewest problems for your work goals.
There is nothing particularly fancy involved in doing a dependency analysis. You just sit down and think about how the different tasks in your project depend on each other. There are, of course, tools to help you with this process. If you use a formal project-planning tool like Microsoft Project, Project Manager or ProjectLibre, you can add the dependencies in your project plan and then the tool will show you the cascading effects of a delay in any task. However, to take advantage of this feature, you have to build a plan that breaks down the work into steps (known in project-management jargon as a “work breakdown structure”), and include time estimates for all your tasks. Some web-based, project-management tools like Asana and Trello can also be configured to allow you to track dependencies among tasks. Regardless of the tool you use, this level of task tracking may be overkill for some projects.
I certainly don’t have a work breakdown structure for every family outing I plan. And yet, I still understand the dependencies for each outing. I understand the steps involved in getting my family out the door, and I understand the consequences of certain delays (e.g., put off lunch too long and I’ll probably have two irritable children on my hands).
You can apply the same informal dependency analysis to your work projects:
- List the steps involved in the project.
- Try to put them in the order in which they will occur.
- Think about where that order is fixed and where it is flexible.
- Note any cases where you need someone else’s involvement, and think about whether that person’s schedule would be able to accommodate delays in your project, or whether delaying that step would have a negative consequence analogous to the grumpy children in my delayed lunch example.
- Think about any other negative consequences from delays to the various tasks on your list. Is there a task that will take you one week if you can get to it before classes resume in the fall, but a month once your time is partially committed to teaching? Conversely, are there any tasks that might actually get easier if you wait? For instance, if a colleague is working on an analysis that will produce results that might simplify the analysis you need to do, it could very well make sense to delay your analysis to wait for your colleague.
“Dependency analysis” is really just thinking through the logical chain of consequences of various things that might happen. You will not foresee every scenario, nor should you try. But by thinking through some of the more likely ones, you will learn valuable things about your projects. I put effort into planning and dependency analysis, not because I expect my plans to come true in every detail, but because the information I gather in planning allows me to make better decisions when changes do occur and reality begins to deviate from my plans.
You might dismiss the utility of this effort because your projects are subject to a lot of changes. That would be a mistake. There is a famous quote from Dwight D. Eisenhower: “Plans are worthless, but planning is everything.” It captures the fundamental truth of project planning in an uncertain world.
You don’t need to spend a lot of time on dependency analysis at the start of a project, but if you regularly spend a little time on it, you might be surprised by how much more effectively you are using your workdays.