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.
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).
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.
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.
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 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.
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.
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.
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.
c80f0f1006