# Interpretation of 'negative lag' between tasks

I'd like to get your opinion on how you think, intuitively, 'lag' on a depency between two tasks works or should work. To make my point I will start with some examples that are no problem, and hopefully when I get to the one that my question is about, it will demonstrate where the disagreement between me and my collegue is :)

Let say we have two tasks, A and B, and B can only start one week after A is finished:

This is, I think, not controversial.

Now a variation: B should start 1 week before A will finish.

This is not controversial either, I think.

Now a bit more complicated: B should end at the same time A ends (end->end relationship).

Now we come to the point where I disagree with my collegue. When there is lag between when A ends and B ends, how should the sign of the lag be interpreted? E.g.:

or

To explain in words: do you think, intuitively, that the 'direction' (in time) of lag between two tasks depends on the type of relationship (end->start and start->start go 'forward' in time, start->end and end->end go 'backward') or should a 'positive' lag always go forward in time?

Edit:

(replaced ascii art with screenshots because it doesn't seem to work on IE)

• I can't entirely understand your diagrams, but it might be a formatting issue. Could you turn them into images that show timelines or Gantt charts and upload them? If you have image files on your computer already, you can upload them using the "Image" button and have them hosted for you. Sep 15, 2011 at 11:41
• Well I figured that using inline ascii art would make it easier since it's easy to put modified versions in without having to iterate through Paint. Maybe it's because I'm so used to working with them. Each image is a box (= task) with an arrow between them; using > for a rightward-pointing arrow and v for a downward-pointing one. Does that clear things up?
– Roel
Sep 15, 2011 at 11:51
• Is it meant to be read vertically? If it is, that makes a lot more sense. Otherwise, things don't seem right. In your first diagram, it looks like A and B are started concurrently, but B takes longer, but that doesn't correspond to your text. Are they formatted the way you intended them to be? Sep 15, 2011 at 11:54
• In that case it seems like you're seeing something different than I am :) I'm on FF6 / WinXP - I'll post a screenshot of how the first diagram renders for me, it's meant to be horizontal just like in MS Project - two tasks, equal duration, B starts after A ends. Please let me know if the image doesn't correspond to what you see, it might be a SE bug.
– Roel
Sep 15, 2011 at 12:02
• It's probably my browser at work. I was performing some long-running background tasks and I had IE open, so that's just what I used to check out a few SE sites. The screencap and what I see are very different. I'm going to read this again later in a different browser, when I have more time. Sep 15, 2011 at 12:05

Here is how I am interpreting your question. You need task B to end exactly one week after task A ends. If this interpretation is correct, then I see no intuitive or direct dependency in the start of these two tasks. It sounds to me like either task can start whenever; in fact, task B might be able to start before A if you chose to do it that way. I also, intuitively, do not see a relationship with the end of one task and the start of the next because, again, your example comes across as if these two tasks are not directly related or dependent upon each other. I am reading the constraint you have is that task B must end one week after task A perhaps because, at the end of that week, something else has to start.

Therefore, I'd schedule the two tasks with a start-start relationship with a x days lag in order to baseline task B finishing one week after the end of task A. I use x days because it depends on the target duration of task B and you did not supply that in your example.

You can use a finish-start constraint with x days lead and get the same schedule results; however, since you are asking intuitively, start-start seems more appropriate since you will have variances in task A. In other words, if task A starts to slip, that would delay task B. If task A starts to come in, then the start of task B will also start to come in. And since it sounded like you had a must-end, you need task B to start independent of what is occurring in the way of variances for task A. So if you are slipping in task A, you will still start B at the right time in order to finish at your must finish date.

Technically speaking, there is no such thing as a positive lag. That is a "lead."

Hope this helps.

EDIT: As I am re-looking at your two examples, I now am seeing you have a finish-finish relationship between the two tasks, i.e., there is some constraint in this project where these two tasks have a dependency where it is important these two tasks finish in some type of order.

If this is the case, the intuitive approach for me would be a finish-finish constraint. Now, if you want Task B to finish one week BEFORE Task A, it would be a finish-finish + x days LEAD (FF-xdays). If you want Task B to finish one week AFTER Task A, it would be a finish-finish + x days LAG (FF+xdays).

• Thanks, yes in your edit you are hitting the point. So, when something finishes BEFORE something (no matter what kind of constraint - start-finish, finish-finish, ...) you call it LEAD, and when it finishes AFTER, you call it LAG? That's great, basically you separate the 'direction' in time that the 'distance' between two points on tasks can be expressed in, into two different concepts (LAG and LEAD, rather than just LAG which can be 'into the future' or 'into the past'). Very useful, thanks.
– Roel
Sep 15, 2011 at 12:24
• Not just finishes. I use lead or lag to describe the direction in which the constraint needs to go, whether I am using a start-start, finish-start, finish-finish, etc. Glad it helped! Sep 15, 2011 at 12:33
• Yes, right, that's what I meant - finishes or starts. The difficulty of just describing the issue shows that it's very nuanced :)
– Roel
Sep 15, 2011 at 12:57

It depends how exactly you definite this relationship. I mean technically you can do it both ways. Exactly as in the first two examples you share. In the first one you have "positive" time shift in the second one the shift is "negative."

With the last to examples (those in question) it works the same: in the next to last you use "positive" and in the last you use "negative" time shift.

In short: first define the relation and then the case will be completely clear.

• Right, technically you're correct, but I guess it's just rephrasing the question: my question was, what is the more 'intuitive' definition for experienced project managers, or evn just for users of project management software? Without knowing the exact definition, what would you expect to happen?
– Roel
Sep 15, 2011 at 11:43
• @Roel, maybe I don't get something: in the first two examples you made differentiation using either positive (1w) or negative (-1w) number and it basically referred to a direction of an arrow. In the last two examples, those in question, it should be the same: you can use it both ways. If you stick with positive number (1w) it should be the next to last solution; if you use negative (-1w) it would be the last one. Sep 17, 2011 at 17:34
• Thanks, yes that's the issue :) The difference between the first and last examples is that the first have finish-start constraints, whereas the last ones have f-f. So, in the second one (and for the second task), the start date depends on the end date. One way of looking at it (but one that I'm more and more abandoning as I discuss it with various people, like in this thread) is that the direction of 'positive lag' depends on the type of constraint; that 'lag' is interpreted in function of its use in a constraint. But given that I can hardly even explain it, I guess it's not so obvious at all.
– Roel
Sep 19, 2011 at 9:40

A simple answer to this question is:

"Positive lag (lead) brings the successor's start date or finish date FORWARD, while negative lag (lead) brings the successor's start date or finish date BACKWARD."

• Making simple answers to scheduling problems is why too few people schedule properly. Sep 15, 2012 at 22:13
• Welcome to PMSE. Could you consider editing your question to provide a little more context? Why is your answer in quotes? Is there a link you could provide to support this? Sep 17, 2012 at 18:33