Skip to main content

We’re starting to look again at managing dependencies using successor/predecessor relationships across projects/work items.  In the past we’ve avoided this due to the risk that a single change from a predecessor project could have a ripple effect across the entire portfolio, impacting everyone’s plans with no control or obvious ‘root’ cause.  However I’ve recently been led to believe that there are global parameters which can be set to restrict this ability to reprofile downstream plans as a result of a planning violation without a direct confirmation from the owning Plans PM if dependencies fall out of line, instead some kind of warning or notification is launched.  Has anyone used, this? If so I’d be keen to see some support material & any downside impacts that such a constraint may have on, for example, progressing engine processes, wider plan scheduling or CPM

@James Bonfield 

To reduce the risk of unintended schedule ripple effects across projects, consider the following approaches:

1. Use Milestones for Controlled Linking

  • Add a milestone in the downstream project and create the predecessor relationship from the upstream project to that milestone.

  • This ensures that changes from the upstream project only affect the milestone, not the full downstream schedule.

  • The downstream project will only reflect changes after the Schedule (CPM) button is clicked manually.

2. Leverage the “Dependencies” Tab for Visibility

  • Use the Dependencies tab to clearly visualize project relationships.

  • Combine this view with filters or highlights to surface critical paths or problem areas.

3. Monitor with “Inter Project Relationships” Tile

  • Use the Inter Project Relationships tile to:

    • Understand dependency types and dates

    • Identify any scheduling violations

    • Proactively manage potential risk areas across projects

4. Restrict Dependency Creation via Permissions

  • Consider enabling the global option:
    "Respect Read/Write Work Permissions to Create Inter-Project Relationships"

  • This helps limit who can establish cross-project dependencies, important because not all project managers maintain the same level of scheduling discipline, which can unintentionally introduce planning disruptions.


Thanks ​@pawan.raju .

We have many of these controls in already -

  • The use of specific milestones and appropriate relationships are recommended, but we can’t enforce our community to use these and always stick to our guidelines.
  • I’m keen to understand which ‘Dependencies'’ tab you refer to - Planview has so many independent ways of managing dependencies!  Could you be a little more specific, I’d like to confirm I’m not missing something here
  • The T127 Inter- Project Relationship tile is in use, and we’re developing a PowerBI dashboard which would present similar data and more in a format which is more presentable to stakeholders and which will remove the inevitable duplicate records if you have both dependent projects in your work portfolio
  • Restricting access isn’t really an option given our resourcing model, but raising the relationships isn’t the problem, it’s if the dependency subsequently moves. 

 

What we were led to believe is that there is an option to warn the downstream project that movement has taken place and flag some kind of violation without applying this directly to the plan, despite automated CPM activity through the Progressing Engine runs.  This sounds too good to be true but it’s really this piece of functionality that I’m trying to uncover! 


Reply