A healthy project schedule is largely predicated on good schedule logic. Acumen Fuse has many logic analyses features for probing and inspecting the integrity of logic in your schedule. Here we take a deeper dive into Acumen Fuse’s logic inspection tools.
Sound logic is important to ensure the reliability of schedule predictions. Acumen has several features to support the quick identification of areas in the schedule that may have insufficient logic. Acumen comes preinstalled with numerous metric groups in S2 // Diagnostics that support inspection of the schedule logic.
Schedule Quality is the default metric group. It contains all the metrics that are the most important to confirm schedule good health. And it has a few metrics specifically geared to check logic. Acumen Fuse’s DCMA 14-Point Metric group, also includes the Defense Contract Management Agency’s (DCMA) 14-Point assessment, which is considered an industry standard. Its metrics also include some logic analyses.
Other helpful metric groups include the Logic metric group and the Lags metric group. Acumen also has an S2 // Logics tab to support detailed logic integrity checks against the schedule. The goal is correct and complete logic. When you have acceptable logic, you should be able to tweak it upstream and see the resulting impact downstream. Good logic is an essential prerequisite for sound Schedule Risk Analysis (SRA).
Schedule Quality and DCMA 14-Point Metric Groups
The Schedule Quality and DCMA 14-Point are considered the gatekeeper metric groups. Before entering more focused metric groups, these two groups are a good starting point for inspecting the condition of your schedule. They also each have a few logic analysis metrics, which is helpful for logic analysis.
In the schedule quality metric group for logic analyses note to the Missing Logic, Logic Density, Number of Lags, Number of Leads, and Merge Hotspot metrics. The Missing Logic metric considers the logic of completed activities, which is an appropriate practice for this metric.
Normally, if the activity is complete it is not a concern because it is too late to do anything about it. But in the case of missing logic inserting logic that is true and more realistic to its successors could push downstream activities and make sure they are in the right spot in the schedule. Particularly, when the successor activity should start later.
Logic Density does not count toward the overall metric passing/failing score but is insightful. The Logic Density metric averages the number of relationships for each activity. Two or more is what you want; and means each task has at least one predecessor and one successor. A high Logic Density value warns of probable redundant logic, which is a negative.
The Number of Lags metric counts the number of tasks that have positive lags. Likewise, the Number of Leads metric tabulates all the negative lags or leads in the schedule. The Merge Hotspot metric flags activities that have many predecessors, these tasks are high risk. Many things must complete on schedule for these merge hotspot activities to commence on time.
Logic analyses in the DCMA 14-Point metric group include Logic, Leads, Lags, SS/FF Relationships, SF relationships, and the Critical Path Test. The Logic metric like the missing logic metric in the Schedule Quality metric group flags tasks missing a predecessor, successor, or both. In the DCMA 14-Point any activity that has a lead is a failed record, no exceptions.
Positive lags are allowable but discouraged. No more than 5% of activities should had positive lags. The SS/FF Relationships metric tabulates the number of SS and FF relationships, where the goal is 90% activities are FS. The idea is you measure what you do not want, e.g., SS and FF relationships, then correct them to achieve what you do want, FS relationships. SF relationships are acceptable but highly undesirable, again, measure what you do not want, SF relationships, and correct to obtain your preferred FS relationship.
Logic and Lag Metric Groups
When inspecting the logic of a schedule, start with the gate keeper metric groups then move on to the logic metric group followed by the lags metric group. Each of these metric groups complements the gate keepers and provides more in-depth knowledge. And these metric groups come preinstalled in Acumen Fuse, so running requires little more effort.
The Logic metric group has a lot of helpful analyses. It breaks up missing logic into a Missing Predecessor metric and Missing Successor Metric. It includes all four schedule relationship types in metrics: SS Predecessor, SF Predecessor, FF Predecessor, and FS Predecessor. It is nice that the Logic metric group has a FS Predecessor metric, so you do not have to back calculate the percentage of required FS relationships, (90% or more). Like the Schedule Quality metric group, the Logic metric group has a Logic Density metric, which we explained previously.
Next comes a Merge Hotspots metric also located in the Schedule Quality metric group. Its sibling metric, Diverge Hotspot, flags any activity that has too many successors. A diverge Hotspot task is a high-risk bottle neck probably because of the significant number of communication threads required at its completion.
The Logic Hotspot metric combines the Merge/Diverge metrics into one tabulated value. Then comes important metrics to help prepare for SRA: Open Start, Open Finish, and Open Ends with Constraints. In Open Start you tied the finish relationships but did not define the start relationships.
Whereas in Open Finish you tied the start relationships but did not define the finish relationships.
And, apparently, Open Ends with Constraints are more agreeable, so they are good to note. A start on or after activity constraint would be appropriate for an Open Start. A finish on or before activity constraint is suitable for an Open Finish.
The Lags metric group sums the number of Lags and the number of Leads, separately. Additionally, it captures the Minimum Lag and Maximum Lag. This can be extremely helpful. Knowing a schedule has leads and the minimum is good information. One may incline to accept a low number of leads for a large, say, 4-thousand activity schedule. But if any of these leads have a yearlong duration (-365-days) minimum lag that makes them a major showstopper even though the number of leads total in the schedule is a miniscule percentage. So, knowing the size of the lag or lead is particularly pertinent information.
Lags were originally designed to represent things that never change their duration. Examples include wait time for approval, paint dry, and concrete cure. But experience demonstrates that paint dry and concrete cure times are highly dependent on the environmental temperature and humidity among other possible factors. If the time of the activity modeled with lag in truth varies it should be modeled as a task to ensure a sound SRA. Further, in SRA you cannot apply risk modeling to lags. It is better, therefore, to convert lags to tasks.
In most scheduling guidelines, leads are highly discouraged if not forbidden. The DCMA 14-Point Assessment prohibits leads. The reason is they are confusing for one, and their predictive nature makes them problematic. In a lead and FS relationship you are commencing a successor activity based on the forecasted future completion of a predecessor activity.
The truth is, your prediction may not become reality, then what do you do? If not true, you may have situations when the successor task finishes before the predecessor task, which makes no sense.
So, leads appear to violate fundamental laws. What would Albert Einstein and the Space Time Continuum theory have to say about leads?
S2 // Logic tab
The S2 // Logic tab is solely geared to inspect schedule logic. It examines all four relationship types. Other logic it looks at are lags and leads. It has several insightful logic checks. Dangling activities from open ends are tabulated. It can nudge an activity and examine its effect on a downstream activity. Further, it can trace forward, backward or forward/backward from any individual activity or trace between two activities. The scheduler can choose to view driving logic only or all logic.
Relationship Types – Group
In the S2 // Logic Relationship Types – group schedulers can review all relationship types in the project. For programs, the logic tab may inspect the relationships that exist between multiple projects. Thus, the logic tab is a great way to review and correct project-to-project links. It also provides nice lists of each relationship type and their percentage weight for the entire schedule. This is good to know when you a trying to confirm that the FS composes 90% of the relationship types. Also, activities in the lists can be grouped by any column header.
Lags and Leads – Group
The activities that have lags (positive) or leads can be listed along with the percentages in the S2 // Logic Lags and Leads – group. This is helpful for confirming that the positive lags in the schedule are 5% or less, as per the DCMA 14-Point Assessment recommendation. Positive lags inhibit the dynamic quality of the schedule and lack sufficient detail.
Scheduling a project is like writing computer code. Software code must be well documented so others can understand how it works. You may have the most efficient and sophisticated software code. Never-the-less if it is not properly documented the computer code does not meet quality standards. It is deficient. Likewise, lags result in lost detail and confusion in schedules.
Leads are problematic, as mentioned previously, because they cause misunderstanding and are predicated on accurate forecasts, which may not come true. Leads also are also susceptible to becoming reverse logic. This is where the successor activity in the FS relationship starts before commencement of the predecessor; not good. What makes the S2 // Logic Lags and Leads – group most informative is that it lists more details about the lag or lead, such as total finish float, lag (duration), and type. And schedulers can publish this data to Microsoft Excel.
Logic Checks – Group
The logic checks – group has several important logic related tests. These include redundancy index, circular logic, open ends, logic on summaries, out of sequence, and reverse logic. The analyses also indicate the positive if no tasks are captured by the logic test.
The Redundancy Index in S2 // Logic looks for redundant logic. Redundant logic occurs when the link in question is superimposed by more detailed links between the same two activities. As an example, a link from task A to task C is made redundant by links from task A to task B and another from task B to task C.
Redundant logic reduces the probability of achieving the schedule goal. This is because the probability of each parallel path in the network logic is multiplied together to arrive at the probability of meeting the schedule end date. So, two parallel paths at a passing 80% probability each, equate to a failing probability for the schedule finish of 64%.
Remove redundant logic to reduce negative impact of probability parallel path multiplication. The exception is when the redundant logic is cost loaded. In this situation it is best to keep the redundant logic to find the schedule budget. The ideal is to make the cost loaded redundant logic a Level of Effort (LOE) activity. LOE activities do not have their own path, and, therefore, do not add an additional path to the schedule probability computation.
Redundant logic in the schedule should be avoided. It also is a common logic deficiency in schedules. The visionary behind Acumen, Dr. Dan Patterson, studied schedule redundancy and concluded that common schedules have approximately 25% redundant logic in their network.
One common source of redundant logic in schedules are planning packages. In Waterfall scheduling planning packages are place holders that are later detailed as more light shines on the respective planning packages’ required efforts. If you neglect to remove the planning packages after schedule detailing, they become redundant logic. So be careful and do not forget to remove the planning packages.
You always want to keep the relationships that make sense and are valuable for the execution of your project. But limit extra relationships. And transform cost loaded redundant logic into LOE activities.
The S2 // Logic Circular Logic check spotlights paths of tasks that loop back on themselves. It is the faulty scenario where two activities are both predecessors and successors of each other. So, a circular link would be a link from A to B and another link from B to A. It is an error that tends to occur on programs made up of multiple projects that have external links to each other. The Circular Logic check can provide confirmation that a multi-project program in fact has no circular links.
The S2 // Logic Open Ends inspection also appears in the Missing Logic metric of the Schedule Quality metric group and in the Logic metric of the DCMA 14-Point metric group. The Open Ends in S2 // Logic provides some additional information about the activities that are missing logic. This includes the number of number of predecessors, number of discrete successors, number of external predecessors, and number of external successors among other variables. Listing external predecessors/successors is helpful when your project is part of a program and may have external links to other projects that are not currently open or imported into Acumen.
Logic on Summaries
This S2 // Logic feature finds deliverables, i.e., Work Breakdown Structure (WBS) elements, that have links. These links are incorrect. You should only connect activities with links, and not WBS elements. The deliverables represent groupings of tasks. Again, tie logic to the actual work efforts in the schedule. Logic on Summaries is only a problem in Microsoft Project. P6 does not allow relationships to connect to WBS elements.
Out of Sequence
The S2 // Logic tab is where schedulers can identify Out of Sequence activities. This occurs during progressing a schedule. The most common Out of Sequence status happens in FS relationships when the successor activity starts before completion of the predecessor activity. It is important to note when progressing tasks that you need the actual dates to specify activity start or finish, simply specifying % complete is not sufficient. In FS Out-of-Sequence activities the predecessor has no actual finish, but the successor has an actual start. In SS Out-of-Sequence tasks the predecessor has no actual start, but the successor has an actual start.
The reverse logic error occurs even before schedule progress in entered. Here, e.g., in the FS relationship, the start of the successor activity begins before the start of the predecessor, which defies logic.
They often are caused by leads. But it could be a start-to-finish (SF) relationship, which looks like a lead. Avoid reverse logic errors at all costs.
Dangling Activities – Group
The Open Ends logic check looks at activities that are missing a predecessor or successor. The Dangling Activities logic check inspects the schedule for:
- Open Start where you tied the activities finish using an FF relationship but did not define an activity start relationship, and for
- Open Finish where you tied the activities start using a SS relationship but did not define an activity finish relationship
An activity may pass the Opens Ends logic check or missing logic metric but fail the Open Start or Open Finish logic check. So, an activity can have both a predecessor and successor and still be a dangling activity. This group is extremely important for SRA. You do not want any open start or open finish activities for SRA. They are not necessarily wrong, but unreliable. A sound SRA is highly dependent on a trustworthy input schedule.
Logic Analysis – Group
The Logic Analysis group allows you to pinpoint key activity-to-activity relationships and primary activities in the schedule. In an ideal world you have one continuous path from beginning to end, and the logic is correct and complete. Use the logic analysis group to inspect the continuity of one activity to another and of important activities in the schedule.
The Logic Analysis – Logic Sensitivity check inspects how reactive a key successor activity is to a predecessor activity in its path. The Logic Sensitivity check thus helps you identify how potential delays affect critical activities or milestones later in the project. In fact, you can determine the impact on the target activity at any given amount of nudge. In this way you can investigate how sensitive an important activity is to an upstream activity in its path.
Below is an example analysis of an activity-to-activity Logic Sensitivity analysis.
The graph plots how many days a respective predecessor activity can delay without causing a postponement of a key target successor activity in its path. So, it:
- Confirms the target is in the predecessor’s path and,
- How sensitive the target is to predecessor delays
This is done by nudging the predecessor task by a material amount, such as 600-days. Note that you nudge an activity in working days (not elapsed days). The Logic Sensitivity graph horizontal is duration variance according to the project calendar, e.g., 5-day calendar. The vertical is the finish date variance in elapsed days, a 7-day calendar. Again, this confirms both the continuity and relevance between the two tasks. If a significant delay in the predecessor has no corresponding delay in the critical successor this warns of possible discontinuities in the schedule.
The DCMA 14-Point metric 12 does the same as logic sensitivity. It selects a random activity and adds 600-days to its remaining duration, then analyzes whether there is any impact on a downstream activity. Your aim in both the Logic Sensitivity analysis and the DCMA 14-Point metric group is to find and/or confirm a continuous path between two tasks and, ideally, through the network.
Logic Trace analyses are available in both S2 // Logic and S2 // Diagnostics. In both the Logic Trace uses two methods to probe for schedule continuity 1) key off one individual activity and 2) investigate pairs of activities. The first method traces paths from a selected activity. It traces the path/paths of activities to and from any given activity. Examples include all activities leading into an important milestone, or all activities on the path from a project sanction (official permission) milestone to the end of the project. The second method confirms schedule continuity between any two tasks of your choosing. It is referred to as a Trace Path.
The Individual Activity Logic Trace has the following options:
- Trace Forward – Traces logic forward starting from a selected activity
- Trace Backward – Traces logic backward starting from a selected activity
- Trace Forward/Backward – Traces logic both forward and backward from a selected activity
It is important to note that the Trace Forward is from the selected activity on downstream through to schedule completion, Trace Backward is from the selected activity on upstream through to the beginning of the schedule, and Trace Forward/Backward is from the selected activity on upstream/downstream to the schedule outer extremities. So, for all three options the Logic Trace is from the selected activity to the outer extremity of the schedule going forward, backward, or both.
Again, Trace Path inspects continuity between any two selected activities. Select the notice to proceed start milestone and project complete finish milestone to confirm one continuous longest path through the entire network. Trace Path also helps program managers investigate logic between projects.
Driving Logic – The driving logic setting uses a float definition (TF <= 0) and not a longest path definition (Critical activities = longest path). The Driving Logic modes are either 1) driving logic or 2) all logic (not). The driving logic setting allows you to capture only those activities that are driving the schedule through to completion. This is relevant for paths from an individual activity and between pairs of activities. Driving Logic only isolates activities that are truly the driving tasks in the schedule.
To activate logic trace in S2 // Logic, click top part of logic trace button, to click-in. To click-out chose another button. To activate the trace in S2 // Diagnostics, run a fuse analysis then left click in the project/snapshot in the upper left corner of the Timeline.
Good logic is a major contributor to a healthy project. Begin your schedule logic inquiry in the S2 // Diagnostics gate keeper metric groups Schedule Quality and DCMA 14-Point. Continue by analyzing the S2 // Diagnostics Logic and Lags metric groups. The Logic metric group provides in-depth analysis of schedule logic, including all four relationship types, hotspots, and open ends. The Lags metric group analyzes both positive lags and leads, and lists the minimum and maximum, which helps to understand the Lag/Lead severity.
S2 // Logic features are pure play Logic analyses. Like the Logic metric group schedulers can review all four relationship types in S2 // Logic. It also duplicates Lags and Leads metrics but collects additional data on flagged tasks. Its Logic Checks analyses, however, are particular to S2 // Logic. It is good to review all Logic Checks and confirm positive outcomes and investigate any problems.
Next the Open Starts and Open Finish Logic Checks are also found in the Logic metric group. The Logic Analysis metrics, Logic Sensitivity and Logic Trace, support probing for schedule continuity. Logic Sensitivity plots activity-to-activity response correlation or relative inertia of a target activity to an upstream activity. No correlation is an indication of schedule path discontinuity or missing logic.
The Logic Trace maps out paths from an individual activity or pairs of activities. Schedulers choose to include all logic or driving logic only to separate out important activities in the network.
The goal in the schedule Logic analysis is complete and correct logic, so that we have confidence in the schedule predictions. You do not want malicious compliance, e.g., tie all (successor) missing logic activities to project complete. The schedule then passes the missing logic metric, but is the linked successor true to the real schedule situation?
Sufficient logic analyses do require input from your technical expert on the project. An understanding of the proposed work is imperative to definitively tell if the schedule logic is complete and correct.
Acumen Fuse Logic analyses do not replace a subject matter expert. But if you are familiar with the work these logic inspection tools help you quickly identify where the schedule is not complete or not correct and requires adjustment. So technical expertise in conjunction with Acumen Fuse logic analyses provide a quick but in-depth and broad spectrum reporting of the schedule logic.