How can you make a deadline on a project, when a deadline doesn’t seem possible? A key trick in getting your projects in under schedule is understanding how to break dependencies. Dependencies in a project happen, when two or more activities depend on each other. The most common kind of dependency is a “Finish to Start” dependency, meaning the first task needs to finish before the second task can start. For instance if you’re building a house, you cannot put up the walls until the foundation is dry.
The obvious problem with dependencies is that they force a constraint on your project’s timeline. If you have two different activities that both take a day to complete, with enough resources you should be able to get both done in a day. However, if there is a start to finish dependency on the activities, then your group of activities is forced to take 2 days.
For that reason, whenever I setup a project that has been allocated a good number of equivalently skilled resources, I go out of my way to break dependencies. Here are 3 key tips that will help you pull it off:
Tip # 1: Resist the Natural Urge to Sequence Things
Novice project managers tend to create dependencies, even when no dependency exists! That’s because it’s human nature to think in terms of sequences. Processing things in blocks, and further in sequence, is a natural process that we follow to solve a problem. This is fine if you’re one person trying to solve a problem, but it creates an unnecessary extension on your finish date. If you question and challenge the sequence of every step, you’ll find in most cases the dependency is artificial.
Tip # 2: Eliminate Soft Dependencies with Risk Planning
A soft dependency is a dependency that isn’t mandatory, but more of a “good idea.” For example, it’s a real good idea to paint before you lay carpet, but there’s no physical reason why you cannot do both at the same time. Intuitively, it seems risky (i.e. you might get paint on the carpet), so what many project managers will do is treat this as a dependency and call it a best practice.
What I’m suggesting is that you eliminate these soft dependencies. In most cases, following good practices like this are in-built risk management. By establishing a dependency like this, you’re controlling the risk that paint will get on the new carpet. The problem with this approach is that you’re masking risk management into the schedule, which is a bad idea. The reason this shows up in the schedule instead of the risk management plan is usually due to poor (or non-existent) risk planning.
The more advanced approach is to break the dependency, and call it out as a risk on your risk management plan. Since you’ve highlighted the risk, you can deal with it as a risk instead of hiding the details in the schedule. Building the dependency is only one way to control this risk. You could also buy paint-resistant carpet, hire more skilled painters, or invest in better painting tools.
Tip # 3: Eliminate Hard Dependencies with Interfaces
If a soft dependency is just a good idea, a hard dependency is a mandatory sequence that must be honored. That said, it can still be broken with an interface. An interface is a simulation or placeholder that mocks up the dependency between the two activities. For instance, in construction, to break the dependency between laying the foundation and putting up walls, the walls could be constructed ahead of time, if we had some sort of mock foundation to use as a guideline. Also, the majority of the foundation could be poured as long as we had some mock-up of where the walls would fit in. The walls could then be grafted in later with steel reinforcement. Breaking hard dependencies takes a lot of imagination. You have to force yourself to think outside of the box, but if you allow yourself to ask these questions, your imagination can sometimes come up with creative solutions.
Breaking dependencies is an art that’s worth exploring, if you want to take it to the next level as a project manager. Some key tips include resisting the urge the naturally order things, breaking soft dependencies with risk planning, and breaking hard dependencies with interfaces. Take some time today to look over your current project plan. With these tips in mind, you should be able to remove some of them, and bring your project end date in.