The second part of the HCP-Go report called the “Schedule Integrity Analysis Report” contains issues that need to be corrected in the schedule, or at least checked for why they were planned that way.
The list of topics can be seen as a “destructive criticism” list, which explains why there is a problem with the schedule.
This is true only if –
- The schedule contains “traps” for the other party (who receives the schedule), then “catching” these traps is perceived as harsh criticism.
Or
- The schedule was not constructed in a professional manner, while pretending to be one.
In short, the schedule was built in bad faith.
In these situations, any “fault” or “error” in the schedule is harsh criticism and whoever is responsible for the problem is caught in their mistake.
However, if the schedule is built in good faith, with the intention of constructing a feasible timeline for execution, that will be on time, then any glitches in the Gantt will help solve unforeseen problems and thus make sure that the project is finished in a timely manner. In this scenario, the type of criticism is constructive criticism. 😊
When looking for faults in the schedule, you can search for them with the help of manual process. For example, do all the tasks in the schedule have successors?
Yet, there may be problems that are detected only when looking at the paths. For example: successor tasks should always be preceded by their predecessor, correct? Now, what if the predecessor is later than the successor? This problem can’t be found manually in the schedule with hundreds or thousands of tasks!
The advantage of HCP-Go is that all problems and faults can be identified by topic. Each issue is detailed and includes the list of tasks that need to be adjusted. This is how a schedule can be optimized and feasible work plans can be reached!
Assuming that the schedule is constructed in good faith without any “traps” for any party participating in the project execution, then there are two main reasons for errors:
- Human error – In a schedule with hundreds or even thousands of tasks, it’s only natural that mistakes will happen. No one is perfect (certainly I’m not!) and a written schedule can never be perfect. The good thing is that these mistakes are easy to correct.
- Other mistakes don’t just happen. Each one has a reason. Every mistake needs to be investigated and questioned –
- Why was it written like that?
- What was the thought process behind it?
The answers obtained from these questions are interesting and reveal issues to be addressed. Sometimes the problems were hidden within the Gantt itself or other times they were ignored by the people who created the schedule.
Maybe the problems will resolve themselves over time?
Yet, here’s a spoiler – it’ll never happen. A problem that is not taken care of at first when it’s small, only grows over time.
What topics are addressed in HCP-Go “Schedule Integrity” section?
with hundreds of activities.
Do you want to know what happens inside,
and if there are problems, where are they?
If you answered 'YES' - then we have a solution for you!
Section 2.2 Tasks that are not linked to successors.
When a task has no successor, this can have several meanings. We’ll examine all cases, from the easiest to the most difficult:
- This is the final task in the project and there’s no work required after it. If there’s only one like this, then – perfect!
If there are several end tasks like this, and there is no logic between them, i.e., each one can end on its own time, then:
Either there are number of separate projects within the general project. It’s important to analyze each one separately. In HCP-Go, in the third stage, it’s possible to select different tasks as final tasks and thus perform different analyses.
Or you can link them all to the end of project milestone. - There is at least one successor to this task! We’ll connect them and nothing terrible will happen in the schedule. We’ll just add the link and move on.
- There is at least one successor to this task. We’ll link them and the project is delayed… We need to add the link because reality won’t make this tie evident. Then, we’ll try to check how to keep the schedule on track.
- There is at least one successor to this task, but it is not found in the Gantt! Write down the missing tasks and link them.
Note: For tasks without successors, HCP-Go refers to as a path completion. If there many of these, a situation is created in which there are many short paths on the Gantt, and this distorts the whole picture.
Additional Note: It’s very important to link milestones to performance tasks and not to other milestones. For a detailed explanation, click here.
Section 2.3 Start-to-Finish links
Start-to-Finish (SF) links indicate that the successor begins when the predecessor ends. In general, it’s not recommended to use this type of link as it may cause various difficulties when executing the project.
This type of dependency entails mental flexibility: it means that the schedule was thought about from end to beginning. Thought flexibility is a great thing! However, reality moves in one temporal direction and it’s not possible to be flexible with time (except in books or movies!).
The Gantt should reflect reality. Hence, this dependency – Start-to-Finish – should not be on the schedule.
There’s another reason to not use this dependency. If you use the Start-to-Finish link in the schedule, and then update the schedule, you may suddenly manage to get ahead of the tasks preceding this link. This can be a situation where this task, related to the Start-to-Finish process, will suddenly be set for past dates. This will be a serious mistake! The method to avoid this is simply to not use the Start-to-Finish dependency.
Well, why would all scheduling software give the option of the Start-to-Finish dependency? There are probably many reasons that are not related to scheduling.
Analysis Warning: We recommend that all Start-to-Finish dependencies be replaced by Finish-to-Start dependencies, Finish-to-Finish dependencies, or Start-to-Start dependencies.
For more explanations about dependencies (links), click here.
Section 2.4 Tasks with predated successors.
Successor must always follow predecessor.
However, in scheduling, situations arise in which the task that is supposed to follow another one precedes it.
Sound complicated? Of course! Can this situation actually occur in reality? Of course not!
So how does this happen? This happens, for example, when choosing to use negative lags to shorten the schedule.
It’s definitely not advisable to use negative lags since they too (like Start-to-Finish dependencies) describe a work order from future to past, which obviously doesn’t reflect reality.
How can this problem be solved? Change the dependency or change the delay to a positive value, and not a negative one.
Section 2.5 Tasks with Calendar Inconsistencies
The schedule has a specific duration for a task.
The schedule has a calendar.
The schedule has basic settings, such as starting work time, end of day time, how many working hours per day, per week and how many working days per month.
Many times, users change their calendar settings, but don’t alter the basic settings. This way you can create the 25th hour in a day, or add the 13th month of the year, and maybe even miss a month of work in the year.
The HCP-Go checks all the settings and maps discrepancies between the set duration for the task (or its planned duration), and the duration calculated by the basic calendar settings, which are the most powerful settings in the schedule. The difference between the calculated duration and the planned duration is the value of the discrepancy.
A positive mismatch value indicates that the calculated duration is longer than the duration defined for the Gantt tasks. This can be caused by setting vacation days or splitting tasks.
A negative mismatch value must be checked since it indicates that the calculated duration is smaller than the defined duration for the task. This situation can be attributed to:
- a) Use of various different calendars.
b) Use of elapsed timed as edays, eweeks, emonths.
c) Weekends turned into work days.
d) Gap in internal settings in MS Project software.
In cases where all ratio values are the same, this would indicate that there is a discrepancy in the internal settings in MS Project software. For example, there may be a discrepancy between how many working hours are defined per day and how many working hours actually constitute a working day.
If there’s a discrepancy in the internal settings in MS Project software, then you can fix the file by changing the settings in the file (recommended) or change one or more of the following settings:
When running HCP-Go, in Step 3, open the “Project Calendar Settings” section and change the values as defined in the file’s calendar: Non-Workdays Per Week, Workdays Per Month, Begin Work Hour, Begin Lunch Hour, End Lunch Hour, End Work Hour.
For more information, click here.
Section 2.6 Overdue Tasks
All project tasks are reviewed in relation to the date of the project data-date (update). This date is set in HCP-Go in Step 3. The tasks specified in this section include:
a) Compared to the date of the project update, the project tasks were supposed to start, but it was not reported;
or
b) Compared to the date of the project update, the project tasks were supposed to be completed, but no completion was recorded.
What should be done? Correct the percentage of execution for these tasks so the performance progress actually matches reality or change the dates according to reality!
Section 2.7 Summary tasks with link issues
There are several topics in this section:
a) Summary tasks linked to predecessors
b) Summary tasks linked to successors
A summary task is not a task. There are programs that are far-reaching and don’t allow summary tasks to be produced. Summary tasks are formed in various sorting.
Linking a summary task to a successor or a predecessor is not recommended for two reasons:
A. Adding the link causes a sweeping constraint on all tasks found within the summary task. For example, linking a predecessor task to a summary task entails that all tasks in the summary task must start only after the end of the preceding task. This may be true, but in most cases, it’s not. This wastes time in the scheduling.
B. The CPM calculation for finding the critical path is performed against the summary task and not the tasks – thus critical tasks are not marked as critical.
Therefore, the links indicated in these sections should be deleted and linked to tasks within the summary task, and not to the summary task itself.
If you have fixed everything, then the schedule is correct, and you’ll see:
