General Schedule Observations

Introduction

The General schedule observations section in xerPlanner reviews five aspects that help assess the structural quality of the analyzed file:

• Activity ID structure;
• Activity ID standardization;
• existence of a start milestone and a finish milestone;
• Activity Code assignment;
• existence of a project-level Must Finish By date.

These observations do not always represent errors. In many cases, they work as warnings or improvement opportunities. Their purpose is to provide context before reviewing the detailed findings in the report.

Activity ID structure

The Activity ID is the unique identifier assigned to each activity in Primavera P6. Although it can technically be a simple number or a basic combination of letters and numbers, a good practice is for its structure to provide additional information about the activity.

For example, an identifier such as A21 distinguishes one activity from another, but it does not provide much context. In contrast, an identifier such as C2100M3000 may suggest a more informative structure: C could represent construction, 2100 could identify an area, M could represent the mechanical discipline, and 3000 could be a sequential number within that group.

xerPlanner cannot know with certainty what each component of the Activity ID means. What it does is observe whether the identifiers appear to have a sufficiently rich structure to provide additional information. For this reason, this observation should be interpreted as an approximate quality assessment, not as an absolute validation of the project standard.

A well-structured Activity ID helps the reviewer understand the schedule more quickly. It allows phases, areas, disciplines, or work packages to be identified without relying exclusively on the activity name, additional codes, or visual groupings.

Activity ID standardization

Having informative Activity IDs is important, but they should also follow a consistent pattern. Standardization makes identifiers easier to read, compare, and audit.

For example, if construction activities follow a format such as letter-area-discipline-sequence number, similar activities should maintain a similar structure. Not every activity type needs to use exactly the same pattern, but there should be consistency within each group.

Tasks may have a different structure from milestones, and that can be completely valid. What matters is that tasks are consistent with each other and that milestones also follow a recognizable logic.

Lack of standardization can create confusion, make bulk reviews more difficult, and give the impression of disorder. A consistent structure supports filtering, searching, analysis, and control processes, while also reflecting a more professional schedule setup.

Start and finish milestones

A well-structured schedule should have a single start milestone and a single finish milestone. The start milestone represents the point from which the first project activities are released, while the finish milestone represents the point into which the final activities converge.

This does not mean that the project must have only one practical starting or ending activity. It means that the logic network should be organized so that there is a formal start node and a formal finish node. The first activities should flow from the start milestone, and the last activities should converge into the finish milestone.

xerPlanner reviews whether these milestones exist and whether they actually perform their logical function. In some cases, it may detect activities or milestones that appear to be intended as the project start or finish, but do not fully meet that role. For example, a start milestone may exist, but another activity may also start without depending on that milestone. In that case, the milestone is not acting as the only starting point of the network.

This review is important because it supports the interpretation of other analyses in the report. If a formal start milestone exists, it is reasonable for it to have no predecessors. Similarly, if a formal finish milestone exists, it is reasonable for it to have no successors. For this reason, xerPlanner uses this general observation as a reference for other schedule logic analyses.

Activity Code assignment

Activity Codes allow activities to be classified according to criteria that are relevant for project control, such as area, discipline, phase, contract, responsible party, system, location, or other attributes. When they are well defined and properly assigned, they make it easier to group, filter, and analyze the schedule.

A good practice is for every Activity Code that exists in the schedule to have a value assigned to each activity. If a specific value does not apply to an activity, it is preferable to create and assign a value such as “Not applicable” or “Does not apply”.

This avoids a common ambiguity: when an activity appears as No Code, it is not possible to know whether the value was omitted by mistake or whether it truly did not apply. When an explicit value such as “Not applicable” is used, it is clear that the decision was intentional.

If the schedule has no Activity Codes, xerPlanner also reports it. In that case, there is no assignment to review, but the observation is still useful because it indicates that the schedule is not using this classification tool.

Project-level Must Finish By date

Primavera P6 allows a Must Finish By date to be defined at project level. This date acts as a mandatory condition on the overall project finish and may influence the calculation of the critical path, float, and schedule feasibility.

This observation is different from the analysis of hard constraints applied to specific activities. A constraint on an activity directly affects that activity and its logic chain. A project-level Must Finish By date, on the other hand, pressures the entire project finish and may generate negative float when the project logic does not allow that date to be achieved.

Using a Must Finish By date temporarily can be useful during analysis. For example, it can help evaluate which paths would need to be compressed to achieve a specific target date. However, it is not recommended to leave this date as part of the official deterministic control schedule or include it in a baseline without a clear justification.

If the schedule cannot logically finish by the Must Finish By date, keeping that condition means accepting from the beginning that the plan is not feasible under its current conditions. For this reason, xerPlanner reports whether this date exists and shows what it is, so the user can decide whether it should be kept, removed, or documented.

How to interpret these observations

General observations should not be read as a list of automatic errors. Their function is to provide early signals about the structural quality of the schedule.

A schedule can be technically calculable and still have weaknesses in its identifiers, milestones, codes, or mandatory dates. These weaknesses may not prevent the file from being used, but they can make it harder to review, understand, audit, or defend technically.

For this reason, this section should be understood as a contextual review. It helps answer questions such as:

• Do Activity IDs provide useful information?
• Is there consistency in the coding structure?
• Does the schedule have a clearly defined logical start and finish?
• Do Activity Codes allow all activities to be classified?
• Is there a Must Finish By date that may be affecting the project calculation?

Answering these questions helps interpret the rest of the report more effectively.

Conclusion

General schedule observations help evaluate structural aspects that are often overlooked in a traditional review. Activity ID structure and standardization, start and finish milestones, Activity Code assignment, and the existence of a Must Finish By date directly influence schedule clarity, traceability, and credibility.

These observations are not intended to replace detailed analyses of logic, constraints, float, or resources. Their value lies in providing an overall view of file quality and helping the user understand the technical context of the schedule before reviewing specific findings.