Who determines task dependency?

Question

Say two tasks, A and B, have a F-S (finish-start) dependency, who actually decides this is the case?

Probably not the greatest example, but here's one: During software development, let's say the development team decides they want the front-end interface to be developed after the design.

During execution, the customer says that these two tasks don't need to have a F-S dependency. The customer then says that the "code base" can be started without needing the designs as reference.

How are these discussions avoided? If they do occur, how is the schedule to be updated?

Answer 1

The dependencies between tasks are based on logic and choice. Logic are hard dependencies and are created because one task cannot start until the other has finished--assuming a finish-start relationship--under any circumstances. For example, you cannot paint a wall until you hang the dry wall, which you cannot do until the wall is framed. You have no choice in the matter. You also have resource created dependencies. This is a bit softer than the previous example because you have some choice here. You have resources committed to perform task A. Same resources are assigned to task B. Therefore, A needs to finish before they are capable of starting B.

The last dependency type is very soft and is based on choice. And this is simply how you choose to schedule the work. You choose to do A before B and schedule it so. You establish a finish-start dependency but, if necessary, you can break it and start B earlier or even first. These type of dependencies are looked at first to fast track when you are trying to recover some schedule slips.

Why would you avoid having those discussions? If the customer wants to see a different approach on the last type of dependency, why not consider it?

It is assumed once the schedule is baselined, the customer would have agreed on the scheduling logic introduced in it. If you were doing scheduling simulations as part of your schedule risk analysis, changing the logic on those tasks where you can could have impacts on the probabilistic results and some of those impacts could be favorable. So overall, I don't think it is a conversation you want to silence. During execution, attacking those soft dependencies to recover a slip is very normal and the right thing to do if you are able.

Answer 2

Assuming that the example you gave was merely illustrative and that you are interested in the more general question:

The interesting thing about this question is that it reveals how many things can be assumed inside task dependencies. Dependency should be a matter of demonstration, not decision/power. If it isn't, then it seems there are problems elsewhere.

Maybe it's not clear what task A produces that is required for task B, or maybe it's not clear why task B requires that thing that task A produces. Maybe the granularity of the tasks is incorrect, and task A should be broken into two or more, only some of which might have a F-S relationship with task B.

The other thing that raised my eyebrows is that this is being challenged after execution has already begun. How was the plan baselined? Shouldn't this discussion have happened during the review of the plan? Why is the customer challenging the dependency now? This seems like there is an underlying problem.

Is the project behind schedule, or is the customer unhappy with the planned schedule because of external factors that have changed? If so, maybe the project needs a global replan.

Has some downstream dependency emerged that had not previously been called out? eg, does some other group need the result of task B in order to do their work? If so, can this be handled as a granularity issue, ie, refactor task B into smaller tasks, one of which can produce the needed thing?

How to avoid these discussions: I think it's okay and even desirable to have these discussions during plan review, before the plan is accepted and baselined. That helps avoid having them later, when they are more disruptive to the project. But the focus should be kept on products and requirements, rather than ownership and control.

Sometimes plans have to be changed, and schedules have to be updated. I'd think the important thing is to review the plan systemically, to be sure you've identified all the actual problems, rather than quickly and narrowly focusing on responding to the particular local item that is raising objections. That particular dependency may be a symptom rather than a cause.

Answer 3

Here be dragons.

True dependencies aren't negotiable. Design before construction is such a case. However, there can be overlap. In many fields, construction can begin before the design is complete. However, once construction has begun many design options are no longer possible without (possibly expensive) rework.

Resource loading dependencies are negotiable, and can often be reordered with little or no cost.

While it is possible to write code without documenting the design, there will be a design to the code base. If the design step is omitted, the quality of the code will depend on a number of factors:

• How complex are the requirements? Simple requirements can often be implemented without a formal design.
• How similar is it to other components that have already been developed? Developing something familiar is far simpler than something new and novel.
• How skilled is the developer? Skilled developers are likely to produce a better design.
• How familiar is the developer with the subject matter? Developers familiar with the subject matter are likely to make better assumptions about the design.
• How uncertain is the design? Many designs follow standard patterns, so construction of the standard components may not need to wait for the design to be complete.
• Is the developer kept in the loop during the design? If so, they can rework to match the design as it develops.
• Is the code being used to flesh out and verify the design? This may be a good approach for new and novel cases. However, these cases usually require more design effort, even if it is the developer that does the design.

In practice, design may not be complete until development (or testing) is. There may be issues that arise that require rework on the design.

The degree of documentation of the design can vary significantly. The factors above may provide some input on how detailed a design needs to be.

When a customer suggests skipping design, I would consider explaining what will be developed. Work the extremes of the possible design. Ask for their confirmation that this meets their needs. It may cause them to rethink skipping design. However, if the design is still clear, then the time allocated for design may be overstated and the customer has a point.