Of the four standard activity relationship types you can define in most half decent scheduling tools, the Start to Finish relationship is the least used, but the one responsible for most of the puzzled looks I get when training new schedulers. Admittedly in my 25 years of working with schedules on various systems, I’ve used the Start to Finish relationship precisely zero times; until this week that is.
In this article I’m going to take a look at this peculiar Start to Finish relationship type and share some thoughts on whether to use it or not.
Definition
For those not familiar with the Start to Finish or SF relationship type, here’s the textbook definition, plucked directly from our very own P6 Professional training manual:
The first question is “Under what circumstances might one need to model a situation where something cannot finish until something else starts?” I’ve asked dozens of schedulers that question over the years and have never found a really good actual live-use example where this relationship is being used. If you have one, I’d love to hear from you.
Moreover, I’ve seen scheduling guidelines that actively discourage the use of SF relationships, largely because few consumers of schedule output truly understand what the scheduler is trying to model. The best written example I’ve seen recently is in a book by Daniel L. Williams, PhD and Elaine Britt Krazer, PMP called Oracle Primavera P6 Version 8: Project and Portfolio Management.
Ten Six]reviewed this book a couple of years back and that’s when I found the following example for using a Start to Finish relationship:
“Imagine that you are building a facility in an area that has no power transmission lines. Activity B can be: run a generator to power up site X. Activity A can be: turning on a power line to the site, which is being built while the rest of the project progresses. B must continue as long as A has not started. It is not necessary that B finish once A starts, but it is allowed to finish once A starts.
Making such a link between these two example activities is easy enough. And indeed here it is, as performed in Primavera P6 Professional. The following figure shows the Start to Finish link on the A and B example. Note how making the link and then scheduling didn’t move activity A. B can’t finish until A starts, and A doesn’t yet have a predecessor so it’s just sitting on the Data Date.
I think further confusion comes when thinking about SF linked activities in context with other preceding or succeeding activities. It can be hard to grasp what a Start to Finish link is buying us in terms of how the critical path will be affected and how these predecessors and successors will be impacted. And my research uncovered no practical discussions of SF relationships in the context of a true scheduling situation.
In the previous figure you can see that in isolation, the link hasn’t moved anything. For now, both the activities are sitting back on the Data Date because they have no other predecessors. We’ve told P6 that the Generator cannot be stopped until the power line goes live. Nothing has been moved when the schedule was calculated because activity A is not dependent on the longer duration activity B. Quite the opposite in fact, activity B’s completion is entirely dependent on the start of power being turned on in the lines.
So let’s explore that situation first.
In order to power up the lines, there must be some effort to get the cable run from the power grid to the site. So this would precede the Turn on Power Line to Site activity. So let’s say it will take 25 days to run the cable out to the site, so we add ‘Run Power Lines from Grid’ activity to the scenario.
Let’s now make the ‘Run Power Lines’ activity a Finish to Start predecessor of ‘Turn on Power Lines’ and watch what happens.
Now what do we have? That’s interesting; the ‘Turn on Power’ activity has dragged the ‘Run Generator’ activity out the extra 5 days. The Start to Finish relationship is pulling on its predecessor. What is also interesting is that if you look at the Total Float value for the Run Generator activity, it only shows 2 days.
Why only two days? Didn’t it just slip 5 days further out from the current Data Date?
To answer that question we have to go under the hood and look at a sample of the forward and backward pass process on our Start to Finish activity. The following network diagram helps us to see what’s going on during this process – at least somewhat.
Because B – Run Generator can’t finish until A – Turn on Power Lines starts, the normal Finish to Start process changes. During the forward pass, the finish date for B gets set equal to the start date of A – then B’s duration is subtracted (26 – 20) to get an early start date of 1/6. On the backward pass, the late finish date of A is applied to the late finish of B (1/27). Now you might be wondering why B is apparently showing a 2 day float on the late dates, but a 3 day float on the early dates (the delta between the early and late dates is the total float). It’s because A’s SF relationship has pulled activity B’s end date to the beginning of the shift on 1/26. It’s easier to show you than explain it, so take a look at the schedule when zoomed in to Day/Hours.
Look how activity B’s end date has been dragged across the non-work period (grey area) to give it an early finish date of 1/26, and then it’s late finish date of 1/27 has been calculated to equal A’s late finish date. So you have ended up with an apparent extra day on activity B because it’s finishing at the very start of the following day, so the backward pass has subtracted the delta of activity B’s the early and late dates (1 day) from the duration and takes only 19 days from the finish date an early start date of 1/8. In short it’s a date vs. duration issue that the backward pass has compensated for. A final observation that you might note here, is that the earliest we may turn off the generator is at the very beginning of 1/26, and the latest is end of the working day on 1/27. If activity is turned off any later than that, it will in this example become critical. The float of activity B then, is always equal to the duration of its SF predecessor A.
Moving on…
Ok, pass the Excedrin and enough of this backward number-crunching stuff. It just makes me glad I was borne in the computer age. Imagine doing this stuff manually like they did in the project rooms of yesteryear. Indeed I wonder if they used SF at all. All we need to know these days is that Primavera P6 is doing it right.
So what has all this bought us in terms of our power lines and generator scenario?
If the power line guys are really dragging and the planned finish date starts slipping, you are going to see increases in the at complete duration of the Run Generator activity and variance on its finish date if a baseline has been taken. But as for a compelling reason to use Start to Finish, I’m still not there.
Technically it is correct. But what it buys us, versus the headache we get trying to figure out how it affects the critical path is questionable. I could just make Run Generator a Level of Effort (LOE) activity in P6. That seems to sit better because running a generator isn’t a deliverable; it’s an ongoing thing and exemplifies the purpose of an LOE activity. I could then have tied this LOE to the back of the Turn on Power lines activity with a nice, simple, Finish to Finish relationship.
When the power lines go live, we kill the generator and the LOE finishes. If the Turn on Power Lines activity gets delayed, the LOE would just stretch out with it. I would also have the benefit of not having to compute Run Generator’s percent complete with every status cycle because P6 does that for me with LOE activities during the schedule calculation process. See above; delayed power lines activity with status and an FF link to LOE Run Generator activity.
Exploiting Start to Finish in P6
I did find one use for the SF relationship this week. It’s not proper use of the SF as it was intended, but it served a purpose.
I was planning a large number of long duration training delivery tasks that represented many one day classes over a period of weeks. The training was for two different business groups, one of which needed to finish before the other.
This was part of a huge estimating schedule, and I didn’t have time to create a detailed plan of every one of the many courses. Therefore rather than create two consecutive activities for every class and group, and then tie a finish milestone to the back of each one, I simply used a SF relationship and then put a lag on it. I used a SF relationship because the milestone was a finish milestone. In P6 finish milestones don’t allow start to start relationships, so it was either a choice of use the FF with a negative lag (generally considered not good practice) or use the SF with a positive lag. I thus took the path that seemed most compliant with the generally accepted scheduling best practice guidelines. It kept a lot of unnecessary detail out of the schedule, but still gave a provable date of completion that would slip appropriately if the start of the training got delayed.
Summary and Conclusions
Most examples of start to finish relationships always seem to refer to non-deliverable type activities. The one I see most is “shift B cannot finish until shift A starts”. I think that is why most examples for SF use don’t convince me that you every really need this type of link. Shift changes and even running generators are ongoing, non-deliverable items. They don’t really represent activity in the true sense of building a project deliverable. There is almost always an easier and more understandable way to model what SF is supposed to be modeling, particularly when using a tool as flexible as Primavera P6. Furthermore the one example I just cited is pretty pathetic too because I was exploiting the SF relationship in order to link to a finish milestone and not for its designed purpose – whatever the heck that might be.
Now I know someone out there must be using start to finish relationships on a real project, and have a great reason for doing so. If that someone is you, I’d love to hear all the gory details about the how and why, with screenshots if possible. It would make the topic of a fascinating follow up blog for sure. And I’m sure the entire scheduling community would be delighted to see this relationship in action.
I had hoped that by researching an article on the topic of this obscure relationship, I would uncover some compelling situations where it can and should be used. Sadly it did not. While I understand what it’s doing from a technical standpoint, 25 years of schedule building and the research for this article have got me no closer to finding a really good and practical application.
It almost seems like Start to finish linking is an unpleasant little prank we schedulers might exact on some poor unsuspecting recipient of our output. Complexity for the sake of complexity? My conclusion as to the “use it, or not” question is; unless you really understand it, and are certain your audience also understands it, don’t use it.
After the hours spent studying and testing this relationship type, I better understand why many scheduling guideline dissuade schedulers from its use. It’s just too darn confusing. After all, a schedule is an important communication tool. It therefore behooves us schedulers to make sure everyone can understand what we are saying.