Pop Quiz: Cross Project Predecessor Toughie

[Doug_Den_Hoed__AtAppStore]

As per the image, can anyone suggest a way to preserve the "stepped" nature of Cross Project Predecessor related projects (which have fallen behind) as opposed to the "overlapped" behavior shown, from a Projected Date perspective (despite recalculating timelines, and making the Cross Project Predecessors Enforced)?

Regards,

Doug

[Doug_Den_Hoed__AtAppStore]

Under some duress, I grabbed my own rebound and noodled out a hack that will suffice for my immediate situation, as below; but am still very keen to learn of any As Designed answer within Workfront, if you have one.

Regards,

Doug

[DaleWh1]

Doug,

This is a great Friday-style problem.

First let me confirm that I understand what your concern was and how you solved it. We use cross-project predecessors a lot and it gets dark quickly. You have three projects that have tasks with cross project predecessors. Some of the tasks were supposed to complete in the past. Your challenge is that the projection does not reflect what you expect on those tasks.

If I got that right, I am inferring from your solution that you had to tell Workfront information about the performance of the previously completed and active tasks so that it updated its calculation. If you are not giving Workfront any information about the task progress, how do you expect it to come to any other conclusion than the series of activities would have a projected completion well into the future from today because no activity has been performed on them?

If you are not setting actuals and percent complete, another option is to use commitment dates, which will influence the projected completion date provided that the commitment date is greater than or equal to today. Of course there are task level settings that would allow for "assume on time", autocomplete, etc... but I would assume that for the purposes of this discussion, we can simplify it down to the dates and feedback.

Am I missing something?

[Doug_Den_Hoed__AtAppStore]

Thanks for playing Dale: yes, you are tracking.

In my first "pop quiz" screen shot, none of the Tasks had even been started, and I was disappointed to observe that the Finish-To-Start relationship between the Cross Project Predecessor related Project "overlapped" (or to put it more colorfully, "collapsed") according to Workfront's As Designed Projected Date calculations.

In my second "duress" screenshots, my (barely) acceptable workaround was to update the Actual Data (Start Dates, End Dates, and "just right" Percent Complete) in a way that effectively told Workfront that the Projects were all perfectly On Track, according to Plan, which then tricked the Projects' Projected Dates to align with the original Plan. Because our stakeholders are monitoring Projected Dates (longer story), and those Projected Dates now matched what those stakeholders required, my immediate concern is now under control: each week, in this manner and until further notice, the team will dutifully massage the Actuals and Percent Completes to keep the Projected Dates "stable".

My still unanswered challenge is how, natively, to direct Workfront to retain the "stiffness" of those Finish-To-Start Waterfall relationships on Projected Dates, which I had hoped would be the case if I marked each Cross Project Predecessor as Enforced (e)...but alas, is not apparently As Designed.

I will give your idea of Commit Dates, Assume On Time, and Autocompletes some thought -- thank you for those -- but if you can suggest a technique will accomplish my goal, I would appreciate hearing about it.

I am also leaning towards leveraging our UberCalc solution to automatically "push" the right data (e.g. "On Time" % Complete every day) which, having slept on it, might have broad appeal for a certain type of Projects.

Regards,

Doug

P.S. As an aside...a couple of years ago, working with one of our clients who makes heavy use of Cross Project Predecessors in their extremely complex industry (biotech), we developed our "Timeline" solution, which allows them to select one or more "Critical Tasks" on a Project and generate a Timeline of dependencies "up" to any predecessor whose delay could adversely impact the timing of such a Critical Task, presenting those predecessors in Gantt chart format, including "crawling up" into the Cross Project Predecessors to reveal their predecessors in a recursive fashion. It is a fascinating and revealing exercise for those who dare to climb up and breathe that rarified air, so if you'd like to check out the view sometime, please drop me an email at doug.denhoed@atappstore.com

[AnthonyIm]

This is interesting.... I would think if you have the Enforced predecessor box checked, that means you cannot start early. So if the projected completion date is moved, I would have assumed the projected date of the successor task in the other project would also move. I'm surprised the green box, doesn't move to a more "stepped" appearance.

To me, it seems misleading. If I was on project D: Stage 2, I would want to know if my project has a different projected start date than planned so I'd know the previous project is running behind.

My only thought might be that the start date of a project doesn't have anything to do with the first task of the project. (i.e. you can have a project start 1/1/20, but the earliest date in the schedule is 5/1/20). Did the Project Start Date of the successor task on the project have a Projected Start Date that is after the Projected Completion Date of project D: Stage 1?

[Doug_Den_Hoed__AtAppStore · Accepted solution]

Thank you Anthony,

I concur that it is misleading, and as per the screenshot and notes below, conducted a detailed test that now explains the Good (blue), the Bad (Orange), and the Ugly (Red)...the latter being my original "overlap" concern.

THE GOOD:

• (1) Project A has a single 40 hour Task A with a Planned Start Date of Nov 16
• (2) The Gantt chart correctly shows the Planned footprint of Project A from Nov 16 to 20
• (3) Project A is a Cross Project Predecessor to Project B
• (4) Project B has a single 160 hour Task B with a Planned Start Date of Dec 1
• (5) Since (intentionally) none of these Tasks have an Actual Start Date, the Gantt chart correctly shows the Projected footprint of Project A from Dec 7 (next Monday, since today is Saturday Dec 5, and the Project Schedule excludes weekends) to Dec 11
• (6) The Cross Project Predecessor is also correctly honored, pushing the Projected Start Date of Project B to Dec 14 (the Monday following Project A's Friday Dec 11 Projected Completion Date), and noting that the original Planned gap between Project A and Project B was "eaten" during the process just as it should be (and, alternatively, could be "baked in" by adding a Lag to the Cross Process Predecessor, if desired)
• (7) Accordingly, the Gantt chart correctly shows the Projected footprint of Project B from Dec 14 to Jan 8
• (8) Moving up to the Portfolio (or Program) level Gantt Chart, the Gantt Chart correctly shows the Projected footprint of Project A from Dec 7 to Dec 11, and
• (9) Correctly shows the Projected End Date of Project B as Jan 8, and
• (10) Correctly shows the Planned Start Date of Project B of Dec 1, but

THE BAD:

• (11) Because the Portfolio Gantt is at a higher level, it does not reveal the Projected Start Date of Project B as Dec 14, and worse...

THE UGLY:

• (12) The Portfolio Gantt shows the Projected Start for Project B as Dec 7 for some As Designed reason I cannot imagine (or, I suspect, a coding error, such as aligning Start-To-Start with Project A), which then results in the red arrow "overlap" as I reported in my original post

CONCLUSION:

So! Now that I know, my "duress" workaround above is not as important for the particular case I was concerned about, since it is the Task level projected dates that are being scrutinized. However: I will also be sure to educate those (closer to the details) who might also look at the Project level projected dates that the latter might be misleading.

Regards,

Doug

[DaleWh1]

So, I took a look at this in a simulation and I would like to share some further insights.

At the portfolio level, the projected start date of the project (not the tasks) is based off the planned start date of the project. If the planned date is in the past, the projected date moves forward, as you would want. But if you are scheduling the projects from a start date, the anchor point for the project start date is that anchor.

To see this in greater detail, create three projects to start on the same day. If you create three one week tasks that are chained on each, you will see that all take three weeks. When you chain one project to another, you will see that the project end date shifts, but the anchor at the project level is still the project start date. As a further enhancement, if you move the first project backward four weeks, you will see a 1-week delay in the start of the first linked project because the project start date is enforced.

And from the item types in question, there is nothing preventing the project from starting as projects only have an anchor of Schedule from Start or Finish. The tasks are prevented from starting, which pushes out the duration (and end dates) of a project from a projected date.

The behavior makes sense when you consider the different item types and the respective enforcement at each level of the hierarchy. Now, if you wanted a sub-project style of behavior that would allow project 2 to float as a container against sub-project 1... I think that requires a different item type that has been requested in the exchange for a while.

Just my $0.02 for a Monday.

[AnthonyIm]

Yeah, it is almost like we need a 3rd option on a project: From Start Date, From Completion Date, Based on Tasks.

The third option would remove any "anchors" and both start and completion dates would be dynamic based on earliest and latest tasks.

[Doug_Den_Hoed__AtAppStore]

Thanks Dale and Anthony,

Yes, yes: agreed. There are some nuances here that I think could be improved to better reflect how real projects work.

Regards,

Doug

[Doug_Den_Hoed__AtAppStore]

Ah! Actually...

Another even easier angle I'll pursue (once it's warranted) is to use our UberCalc solution to automatically keep the Project Start Date aligned to the Projected Start date of the first task in the Project (provided it has not yet started), which would then force the behavior I seek at the Portfolio and Program report.

Tricky one, but I think we got there; thanks again, gentlemen!

Regards,

Doug