Everything that happens in a project is interlinked and knowing how to schedule a project with this in mind is a process your project management office (PMO) needs to support. There are different types of tasks dependent on each other, and here we’re looking at what discretionary dependencies are and giving you some examples.

Knowing the dependencies in a project will ensure that your project planning goes smoothly and is grounded in reality. Discretionary dependencies are ones that your project team can make decisions about, and it’s up to your PMO to help with that decision-making process.

So you can offer the proper support, we’re going to look at:

  • What discretionary dependencies are
  • Examples of discretionary dependencies in different industries
  • How to create a schedule building in discretionary dependencies

What is a discretionary dependency?

A discretionary dependency is when one task should finish before another one can start or be finished, but it’s a business decision rather than a hard and fast rule.

Rather than a mandatory dependency which is when two or more tasks are linked by rules, laws, or physical limitations, a discretionary dependency can be adapted and changed if the project requires it.

Your PMO or a project manager can decide that one task needs to be completed before another one can be triggered. This is a business decision, based on things like:

  • Expertise in the subject matter meaning you know a particular sequence of tasks is best
  • Industry knowledge that says doing things in a specific order produces optimum outputs
  • Internal business limitations such as wanting to avoid taking on freelancers where possible

Mandatory dependencies are sometimes called soft logic or preferred logic. They can and will change during a project lifecycle and/or as your PMO and project teams develop a deeper understanding of the projects you work on and get better data.

Examples of discretionary dependencies

There are multitude of discretionary dependencies, and they will be determined by a range of factors such as how your PMO and projects are run, the industry you’re in, or even the training and background of your team.

Here are some general examples of discretionary dependencies for industries that commonly work on a project basis:

  • IT and software development – when building a website or app, it’s unlikely to be an issue whether integrating a payment gateway or an email system is done first. It will come down to a matter of preference which one is worked on first.
  • Marketing – when putting together a new marketing campaign, whether the social media content is scheduled first or the email automation is designed first won’t change the project outcome. However, a PM might want to complete these tasks in a certain order knowing one can require more testing than the other.
  • Manufacturing – when the end goal of a project is to produce goods, there will be lots of physical limitations, but things like designing feedback and sending the product to be prototyped can be done in any order. It’s up to the PM to decide which will be first.
  • Construction – There is a clear logic to putting up a building, but things like wall finishings and floor finishings don’t have to be done in a certain order; it’s just sensible to do walls before floors.

How do I schedule discretionary dependencies?

When you create a schedule, you should plug in your mandatory dependencies first to ensure the sequences that are optional fit around them.

As you start to populate discretionary dependencies, be sure to document why something is being done in that order. If there is a need to change the schedule, it’s important that decisions are understood in case there is an unintended consequence further down the line.

It’s important to also focus on resource availability when working out your discretionary dependencies. A “nice to have” workflow could push a colleague too hard, for example.

Working with discretionary dependencies

Understanding discretionary dependencies in a project takes industry knowledge of best practices as well as intuition for how your business and PMO works. Planning for them can be less demanding than mandatory dependencies, but they’re no less important to successful project delivery.