Issue 4 – Dependency Mismanagement
Non-Value added time and delays to the project result if dependencies are not managed
I’ve often seen contractors and sub-contractors begin design and development for their piece of a project only to find they have to revisit both due to other dependent items that must be completed prior to the contractor’s design and development effort. Even if no technical dependencies are established, the testers cannot start testing until other pieces of the code are completed. This results in either unnecessary time spent (=$) by the contractor or added costs to the client, not to mention delays to the project.
We Project Managers must be able to plan for and manage the dependencies among tasks in the network diagram when scheduling. A dependency is a link amongst a project’s activities or tasks. The greater the project complexity requires further dependency planning. There are four relationship types of project planning dependencies in three categories. The relationships between dependencies are Finish to Start, Finish to Finish, Start to Start and the least used one Start to Finish.
In keeping with the spirit in this blog series, that is, minimizing project failure risks, a key tip in getting your projects in on time is learning how to break-down dependencies. Dependencies in a project happen when at least two tasks or activities depend on each other.
The most common type of dependency is a “ Finish to Start” (F2S) dependency. This means the first task must finish before the second task can start. For example, if you’re building system feature, you cannot test the feature before it’s developed. The problem with dependencies is that they force a constraint on the project’s schedule. If you have two different tasks or activities that both take a day to complete, with the right resources you should be able to get both done in a day. But, if there is a F2S dependency on the activities, then your group of activities is forced to take two days. It’s for this reason that when I begin a project, given I have the optimum number of skilled resources (yeah…right!), I like to break the dependencies down as much as possible. There are a few tips at the end of this blog concerning the use of dependencies to minimize risk on a project.
A clear understanding of the four network diagram relationships is necessary before we begin to offer strategies on managing those dependencies. That said, here’s a brief lesson on the four types of network diagram relationships (in order of frequency of use):
1. Finish to Start (FS)
- F2S = Task B can’t start before Task A is finished
- New system requirements must be completed before designing the new system
2. Finish to Finish (FF)
- F2F = B can’t finish before A is finished
- The design for order cancellation (B) cannot finish before the design of order entry (A)
3. Start to Start (SS)
- S2S = B can’t start before A starts
- Project work (B) cannot start before project management planning activities (A) has is started.
4. Start to Finish (SF)
- S2F = B can’t finish before A starts
- Here’s the only example I can think of for S2F and this has to be an organizational policy in real life.
In shift work, the relief shift worker has to arrive, clock in and start her shift, before the current shift worker can clock off and end his shift. If the relief shift is late, the existing shift can’t finish. It can only finish once the following task has actually started.
Summing up the dependency relationship lesson, F2S is considered a “natural dependency” whereas the other dependencies are constraints imposed by the scheduler to reflect resource shortage or discretionary dependencies. S2F is seldom used, and should be avoided.
There are three kinds of dependencies with respect to the reason for the existence of dependency:
1. Causal (logical)
- It is a poor practice to code a feature of the system before that feature is designed.
- It is illogical to pour concrete before you dig the foundations of a building
2. Resource constrained
It is logically possible to code all of the system features at the same time but there’s only one software engineer.
It is logically possible to paint four walls in a room simultaneously but there is only one painter.
3. Discretionary (preferential)
I want to code the backend of the system (ex. order fulfillment) before coding the front-end (eCommerce site) but I can also start the coding for the front-end before the backend of the system because it does not matter.
Early critical path derived schedules often reflected only on logical or discretionary dependencies because the assumption was that resources could be made available. Experienced and competent project managers, and schedulers know that schedules must be based on resource availability. The critical chain method necessitates taking into account resource constrained dependencies as well.
To add to the network diagram complexities leads and lags can modify these dependencies. For example: When building two independent system features from a design, one feature might start on day 1 and the second feature 2 days after the first is complete so that the second team can learn from the first. This is an example of a lag in a S2S relationship.
A project manager may specify lead time when tasks are performed in parallel in a Finish-Finish relationship. For example: I am short one testing resource. When I’m developing the network diagram, I’ll make sure the coding for feature A finishes 5 days before the coding of feature B so that my only testing resource has time to test each feature individually. Although feature A and feature B may have different durations, they will be planned to finish 5 days apart. This is an example of a lead in a F2F relationship.
Minimizing Project Risk through Dependency Strategies
1) Eliminate Mandatory Dependencies with Interfaces
A mandatory or hard dependency is a required sequence that must be honored. Hard dependencies can still be broken with an interface. In this example, an interface is a placeholder on the network diagram that represents the dependency between the two activities. Using the example of building a house the project manager can break the dependency between laying the foundation and putting up walls, the walls could be constructed ahead of time, if we had a “mock foundation” to use as a guideline. Additionally, the most of the mix for the foundation could be poured as long as we had some facsimile of where the walls would fit in. The walls could then be grafted in later with steel reinforcement. (OK, you construction project managers are probably laughing your #$#@s off at this example). Breaking down the hard dependencies takes a lot of skill and imagination. The PM has to think outside of the box. But, if you allow yourself to ask these questions, your past experiences and imagination can sometimes come up with a creative solution. Regardless of whether the project is to build a house or implement a complex ERP system, breaking hard dependencies is worth exploring, if you want to get a promotion to Senior Project Manager, Program manager or PMO.
2) Eliminate Discretionary Dependencies with Risk Planning
A discretionary or soft dependency is a dependency that isn’t mandatory. It’s a good idea or a preference of the project manager. For example, it’s a good idea to get sign-off from the client/customer on the requirements for the new system before you design and code the new system, but there’s no physical reason why you cannot do both at the same time. Intuitively, it seems risky in that you might waste time coding the system if the client decides to eliminate a set of features initially scoped on the new system. What I’m suggesting is that you eliminate these discretionary dependencies. In most cases, following good practices like this are integral to risk management. By establishing this type of dependency you’re controlling the risk that the software engineers won’t waste time building features that the client does not want. The issue with this practice is that you’re masking risk management into the schedule, which is definitely not a good project management practice.
3) Defy the Normal Tendency to Sequence Things
Newly minted project managers have an urge to create dependencies, even when no dependency exists (yes, I’ve been guilty!). This is only human nature to think in terms of sequences. Breaking system features into activities, and further into task sequence is a natural process that we follow for problem solving. This is fine if there’s only 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 not necessary.
The reason this shows up in the schedule instead of the risk management plan is usually due to poor (or nonexistent) risk planning. The further 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 get better skilled resources or invest in better PM tools.
A word of advice:
Resist the urge to do the natural order of things. Consider, breaking down soft dependencies with risk planning, and breaking hard dependencies with interfaces. Look over your current project plan. If you remember the key points of this blog, you should be able to remove some of the dependencies and shorten the schedule for insurance against those unknown risks.
