Here I outline a method – including the ImposeZFF macro – to provide “just-in-time” scheduling of flagged tasks in MSP. I also include a separate macro, RemoveZFF, to restore the tasks to as-soon-as-possible scheduling.
Another missing feature for anyone coming to MSP from Primavera’s planning tools is the “Zero Free Float (ZFF)” constraint. (Primavera now calls this the “As Late as Possible (ALAP)” constraint – NEVER to be confused with MSP’s identically-named version, which is pretty useless for forward scheduling.) The ZFF constraint delays an activity as much as possible without impacting any successor activities. It is useful for scheduling just-in-time works and deliveries while preserving the correct logic flow through the project schedule.
Consider the simple project shown here. The overall project completion is limited by a constraint on task B. (I never use such mandatory constraints in practice but use it here to avoid having to add other extraneous logic to the example.) Task A must be completed before B, but for maximum efficiency it is desired to perform this work just-in-time. Because MSP has no other obvious feature to arrive at the desired schedule outcome, the scheduler is tempted to make task A a Start-to-Finish successor of B. Such an approach is unsound and is to be avoided for a number of reasons. All links in a logic-driven project schedule must reflect real logical constraints, and real Start-to-Finish constraints are extremely rare.
So what is the scheduler to do? Most situations are easily solved by adding logical milestones to the project schedule. For example, a logic-driven “Site Ready for Delivery” milestone as a Finish-to-Finish predecessor of “Eqpt Delivery” would be quite normal. In the very few occasions when suitable logical workarounds cannot be devised, then it may be useful to impose early-start constraints to achieve the zero-free-float objectives. For good control over the process, I use a custom flag field to designate specific tasks requiring ZFF constraints. Then I run a macro that automatically computes and assigns the appropriate constraint to all the ZFF tasks in the project at once. This makes ZFF constraints easy to audit, review, and justify.
For our simple project example, I inserted the Flag20 local field into the Gantt Chart entry table and called it ZFF. Then I marked task A with the ZFF flag and ran the macro. The macro automatically imposed a new early-start constraint on the task. As a result, the 12 days of Total Slack (like the 12 days of Free Slack) that previously existed have been consumed. Task A is now correctly shown as Critical.
If your project has a logical chain of tasks that are all ZFF-flagged, then you’ll have to re-run the macro several times (or add a simple iteration loop to the code. I have one but didn’t include it here for simplicity.)
[May 2019 Edit: Though I don’t use this macro, one user has reminded me that when used to delay a string of connected tasks, selecting the tasks in reverse order may be more efficient than the forward order first included in this article. I.e. use the “For i…” block shown here in place of the “For each t” block originally included. I might get around to modifying that code eventually.]
Dim i As Long For i = ActiveProject.Tasks.Count To 1 Step -1 Set t = ActiveProject.Tasks(i) If Not t Is Nothing Then 'If t.GetField(Application.FieldNameToFieldConstant(FieldName)).... '... '... End If End If Next i
The code for imposing the constraints is shown below. Drop it into a VBA module in your Global.mpt file (or in a specific .mpp file if necessary), then look for and run macro “ZFFImpose”. I normally use another function to find the ZFF flag field in a project, but that function was too big to include here. So if you want to use a custom flag field other than Flag20, just change the “FieldName = “Flag20″” statement in the code.
Sub ZFFImpose() ' Macro Coded 31-08-16 by Thomas Boyle PE PSP PMP. On Error GoTo 0 Dim i As Integer Dim t As Task Dim L1 As String Dim L2 As String Dim SW1 As Boolean Dim SW2 As Boolean Dim SW3 As Boolean Dim FieldName As String 'FieldName = FindField_Flag("ZFF") 'Function not included here Fieldname="Flag20" If FieldName = "" Then MsgBox Prompt:="No ZFF Flag Field Found", Title:="ZeroFreeFloat Constraints" Exit Sub End If CalculateProject For Each t In ActiveProject.Tasks If Not t Is Nothing Then If t.GetField(Application.FieldNameToFieldConstant(FieldName)) = "Yes" Then If t.FreeSlack > 0 Then t.ConstraintType = pjSNET If t.Calendar = "None" Then t.ConstraintDate = Application.DateAdd(t.Start, t.FreeSlack) Else t.ConstraintDate = Application.DateAdd(t.Start, t.FreeSlack, t.CalendarObject) End If CalculateProject L1 = L1 & t.ID & " " & t.Name & " " & t.ConstraintDate & vbCrLf SW1 = True Else L2 = L2 & t.ID & " " & t.Name & vbCrLf SW2 = True End If End If End If Next t GoTo Finish tEHandler: MsgBox ("Failed to impose Zero Free Float Constraints") Exit Sub Finish: CalculateProject If SW1 = True Then MsgBox Prompt:="Imposed Early Start Constraints to remove free float:" & vbCrLf & L1, Title:="ZeroFreeFloat Constraints" If SW2 = True Then MsgBox Prompt:="No free float to remove on tasks: " & vbCrLf & L2, Title:="ZeroFreeFloat Constraints" If SW1 = False And SW2 = False Then MsgBox Prompt:="No tasks marked for ZFF", Title:="ZeroFreeFloat Constraints" End Sub
What is done with the “ZFFImpose” macro is easily undone with the “ZFFRemove” macro shown below. This macro returns all ZFF-flagged tasks to “As Early As Possible” scheduling.
Sub ZFFRemove() ' Macro Coded 31-08-16 10:30 by Thomas Boyle PE PSP PMP. On Error GoTo 0 Dim t As Task Dim L1 As String Dim SW1 As Boolean Dim FieldName As String FieldName = "Flag20" 'FieldName = FindField_Flag("ZFF") If FieldName = "" Then MsgBox Prompt:="No ZFF Flag Field Found", Title:="ZeroFreeFloat Constraints" Exit Sub End If For Each t In ActiveProject.Tasks If Not t Is Nothing Then If t.GetField(Application.FieldNameToFieldConstant(FieldName)) = "Yes" Then If t.ConstraintType = pjSNET Then t.ConstraintType = pjASAP CalculateProject L1 = L1 & t.ID & " " & t.Name & vbCrLf SW1 = True End If End If End If Next t GoTo Finish tEHandler: MsgBox ("Failed to remove Zero Free Float Constraints") Exit Sub Finish: CalculateAll If SW1 = True Then MsgBox Prompt:="Removed Early Start Constraints from designated ZFF tasks:" & vbCrLf & L1, Title:="ZeroFreeFloat Constraints" If SW1 = False Then MsgBox Prompt:="No tasks marked for ZFF", Title:="ZeroFreeFloat Constraints" End Sub
Hello Tom!
Its embarassing that im writing to you in 2020 on an issue that is there from 1998 but here we are.
Im a project planner in charge of a project with about 3000 lines and the project plan is used for financial planning and EVM reporting. All of the bells and whistles, so to speak.
I and even my management are getting pretty frustrated since from the beginning of the project we have stumbled upon ms project constraints way too often than we would like. Still, having primavera floating licenses is not an option.
Anyways, what i wanted to ask is this: why in your opinion it is better to use a milestone with a finish to finish constraint instead of a SF constraint to a task that follows both?
For me the macro is nice but i guess since it uses the “start not sooner than” functionality – then i wouldnt be able to use it for other purposes and i don’t want to limit myself now.
Kind regards,
Alexander
Antwerp, Belgium
Hi Alexander. Thanks for the comment. I don’t fully grasp your proposal to use SF relationship with a milestone, but here’s what I can say: 1) If it could be guaranteed that a milestone always remains a milestone (i.e. zero duration), then its start and finish would always be identical, and there would be no effective difference between SF and FF successor relationships. In MSP, however, no such guarantee can be made – sloppy and/or deceptive status updating practices routinely lead to different start and finish dates for “milestones.” Since here (i.e. “ready for delivery”) only its finish matters, only an FF successor is valid. 2) Looking at the A-B-C example of the article, the novice scheduler is tempted to schedule A just-in-time using B->SF->A. The SF restraint dictates solely that A may not finish before B starts, but what is the impact on B if A is delayed by a month? NONE!, which is clearly wrong. In this case the true logic relationship (FS) between A and B has been sacrificed to just-in-time date manipulation, and total slack throughout the network is unreliable or incorrect! There is a similar discussion of the issue at http://www.planningplanet.com/forums/microsoft-project/691256/alap-constraint-behavior-question. Of course, for those who don’t care about such issues, there is still the frustration of having the just-in-time activity finishing at the start of a day.
Hi Tom,
Thank you so much for these Macro’s.
They worked perfectly, first time.
This is a great solution to an otherwise intractable problem, for me.
NB. It would have taken me forever to gain the knowledge to code this myself.
Thanks again.
Dave Hatch