Part of building a project schedule entails the sequencing of tasks to be completed in furtherance of the project. There are a number of determinants that go into sequencing, but one of the most important is to determine project schedule task dependencies. A dependency between tasks is: what needs to happen before something else can occur. The first task, that is the task that is required, is called the predecessor task. The task that cannot occur without the predecessor task will be called the successor task. Note that the Project Management Institute uses the term “activity” and Microsoft Project refers to the same concept as a “task”; the terms can be used interchangeability. For this article, we will follow Microsoft’s designation of “task”.
Task Dependency: You need to open the door before you can walk through it.
With our example of walking through the door, the relationship between the task of walking through the door is logically successor on the task of opening the door. Opening the door is the predecessor task and walking through the successor task. In this case, it is physically impossible to do one task unless the other one is first completed.
Dependencies have attributes which indicate the logic of the relationship between the predecessor and successor tasks and whether the project controls the predecessor task. There are four types of dependency attributes organized in pairs of opposites. Only two attributes will apply to a dependency relationship. The first pair of attributes is mandatory / discretionary and the second is internal / external pair.
You Gotta Do What You Gotta Do
Mandatory and Discretionary Dependencies
Mandatory – Mandatory dependencies are those that express a logical connection where a dependent task is impossible unless the predecessor task is first completed. The dependency is inherent in the work or process of the project. Other reasons for a mandatory project schedule dependency relationship are legal requirements, regulatory constraints, business rules and standards, contractual obligations, and etc. Sometimes you will see this attribute referred to as a Hard Logic dependency.
Example: Where the user tables would need to have been created before data can be written to the tables. In this case, the tables must exist before they can be written to.
Discretionary – A dependency that is not logical or mandatory is considered to be discretionary. These types of dependencies are based on heuristics, best business practices, conventions within a company or practice, or where there is a preferential reason, and so on. The Project Management Institute’s PMBOK guide recommends that these types dependencies be fully and completely documented as “they can create arbitrary total float”. A discretionary dependence is one that can be considered for fast-tracking or other schedule compression techniques, if they become necessary on your project. This type of dependency attribute is occasionally referred to as Preferential or Soft Logic.
Example: Develop browser user login interface then develop mobile interface. One will use code developed for the other but the order is a preference of the development team for ease of coding.
Control Is in the House
Internal and External Dependencies
The relation of control to the performing project expresses its internal or external dependency. The determination of whether a dependency is external or internal is determined on where, in reference to the project team, the predecessor task occurs or who the responsible party is.
External – External dependencies are those that are outside of the control or responsibility of the project team. The predecessor task is said to be a non-project task that, none the less, has an impact on project tasks.
Example: Hosting service provider must spin up virtual servers before software can be installed. The hosting service provider is external to the project and the project team is dependent upon the completion of the task.
Internal – Internal dependencies are, as you probably have already guessed, where the predecessor task is within the control of, or to be performed by the project team.
Example: A version release must be installed on the QA server environment before user acceptance testing can commence. The install of the software is to be completed by project team members.
Risky Business
Schedule Risk Management and Dependencies
Every task dependency caries a level of risk. According to Edward Murphy Jr.: if there is an opportunity for something to go wrong then eventually it will. A dependency is an opportunity for something to go wrong. Further, on review of the dependency attributes, it becomes clear that there are greater inherent risks in some of the attributes than others. When you are performing risk management and analysis it is important to devote additional effort for tasks that have a high inherent risk. The graphic below demonstrates the relationship between dependency attributes and inherent risk. The greater the inherent risk, the greater the required risk analysis and planning.
External dependencies are riskier than internal dependencies because the project team has no direct control of the task and any potential deliverable associated with it. Mandatory dependencies have more inherent risk than discretionary as the dependent task cannot begin if the mandatory predecessor task has not been completed. An task with attributes of mandatory/external has the greatest inherent risk as the predecessor task logically and directly impacts downstream tasks and the project team has no direct control over the performance of the task.
What’s Does It All Mean
Determining the attributes of a dependency is a critical part of the process of sequencing tasks for scheduling. The determination of dependency attributes is one of a number of tools that will help in this part of the practice of project management.
The four project task dependency attributes form two axes: one on the spectrum of internal to external control and the other on the spectrum of discretionary (soft) to mandatory (hard) logic requirement. A dependency can have two of four attributes, one from each axis. The attribute pair should be documented with each dependency in your project schedule.
The attributes have inherent risk as one goes from internal to external control and discretionary to mandatory logic. The impact of the risk that must be reviewed and planned for as part of project risk analysis. It is a good practice to make this part of your standard risk management practice.
Leave a Reply