Mastering Activity Codes in Primavera P6 Schedules for USACE and NAVFAC Contracts: Requirements, Common Pitfalls, and Best Practices

Marty Fuentes
January 13, 2026

This article emphasises the contractual requirement to apply specific activity codes in Primavera P6 schedules for US government projects, particularly under USACE and NAVFAC contracts. USACE typically mandates a comprehensive set of eight activity codes, while NAVFAC may require only a subset. The article highlights the importance of reviewing each project’s specific contract to ensure compliance, noting that exceptions are possible if agreed upon by all parties. It also addresses common pitfalls in activity coding, explains the purpose and benefits of these codes for schedule management, and provides practical guidance for their correct application, ultimately demonstrating their value beyond mere compliance.

Activity Code

One of the requirements to comply with the technical specifications of the schedule submittals in US government projects, such as under USACE (United States Army Corps of Engineers) and NAVFAC (Naval Facilities Engineering Systems Command) contracts, is to have the activities in the Primavera P6 schedule activity coded. This stipulation is normally found in Section 01 32 01.00 10 of USACE contracts and under Section 01 32 17.00 20 of a NAVFAC contract. The full suite of 8 activity codes (Workers per day, Responsible party, Area of work, Modification number, Bid item, Phase of work, Category of work, Feature of work) is generally required in a USACE contract while in a NAVFAC contract, some may only be required, such as the responsibility code and the category code. This is in a general form of the schedule specification and may vary from project-to-project so it’s best to properly check the particular project’s contract requirements. Nonetheless, since the USACE contract is all encompassing that it covers also the relatively minimal requirement of that in the NAVFAC contract, this article will cover the 8 activity codes in the USACE contract.

This article discusses how to correctly use and apply the activity codes in US government-contracted Primavera P6 schedules. At MLR, we had completed a number of schedule reviews and baseline development, that included the correct application of activity codes, that we’re able to compile, and now delightfully sharing through this writing, some of the common pitfalls in activity coding and how to do them the right way. For project scheduling practitioners, it may beg the question the utility of these codes in schedules whether these are unnecessary extra work that don’t have functional value to construction schedules. That doubt is also addressed herein. One thing is certain though, the activity coding needs to be applied as it is a contract requirement. But of course, we don’t want to “blindly” follow written instructions, even prescribed in a contract as exceptions could still be made subject to agreement between contracting parties, that are not useful and competing time and effort against more pressing matters. However, on the contrary, these codes really do prove valuable in controlling and managing schedules as explained later on.

What follows is an explanation of each of the eight (8) activity codes as stipulated in the project contract, their value in the construction schedule, and some of the mistakes normally encountered in administering these requirements, along with the corresponding pointers in doing them the right way!

1. Workers Per Day (WRKP)

What does the contract say: Assign Workers per Day for all field construction or direct work activities. Workers per day is based on the average number of workers expected each day to perform a task for the duration of that activity.

Value: This code is perhaps the most difficult to validate, among the 8 activity codes, from the point of view of the schedule reviewer due to its highly subjective application. An activity could be assigned with one, or two, or whatever WRKP value (as long as it’s not an absurdly huge figure) and the reviewer won’t be able to tell whether that is the correct number, or not, as this is dependent on the skills of the resources, productivity assumed, quantity considered, and even the method considered. This requires a great depth of analysis and heaps of going back and forth between the schedule developer and the reviewer when validating. So, it’s best to tackle the assigned codes at shallow level. However, it’s value should not be undermine. The WRKP is critically important when it comes to assessing the durations proposed by the contractor for variations. As in variation analysis, the baseline schedule is key in assessing whether the proposed durations in the variations (or contract modifications) are reasonable considering the WRKP assigned to similar activities in the existing scope vis-a-vis that proposed to be amended or added. For instance, if wall painting had been assigned with 2 WRKP for 10 days, and a variation order submitted by the contractor, assuming for the same area (if the area is different, calculations could still be made to validate such), had it for 20 days with the same 2 WRKP resource allocation, then the reviewer could simply flag that the duration was not reasonable, and should only be 10 days.

Moreover, with extra efforts in analyzing the schedule, the WRKP also provides a good indication of the correct sequencing of works from the spatial point of view, such as, you could not possibly place 100 workers in a limited, say, 10 m² (108 sqft) workspace.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	While it’s not explicitly cited to assign an activity code on all activities, it is always a good scheduling practice, for better control and management of the schedule, to assign an activity code on each single activity. This also avoids misinterpreting the uncoded activities to have been incidentally missed out in the coding process. For activities that don’t require a WRKP, a “0 worker per day” code can be assigned.
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Including indirect labor resources in the worker per day count.	The WRKP code is associated only for the average count of direct field construction workforce (i.e., carpenter, pipefitter, laborer, etc.). It should not include in the count the administrative, support, and project management staffs (i.e., project manager, scheduler, timekeeper, supervisors, etc.).
4	Assigning a worker on non-construction activities, such as preparation of pre-construction submittals, subcon procurement process, design development, and the like.	As previously mentioned, WRKP code pertains to direct construction workers. Non-construction activities are mostly done by project support staffs and therefore should be coded with “0 worker per day.”
5	Assigning a worker on activity under the responsibility of the client/principal/government, such as submittals review and approval, pre-final and final inspections, and the like.	These activities are not under the responsibility, and not performed, by the contractor, hence, should be assigned with a 0 worker per day code.
6	Assigning a worker on milestone and WBS summary types of activities.	Milestones don’t have a duration, hence, there should be no work and workers associated with this type of activities. Similarly, WBS summary is not a task-related activity and should not be assigned by a worker. For these types of activities, 0 worker per day should be the correct code.

2. Responsible Party (RESP)

What does the contract say: Assign responsibility code for all activities to the Prime Contractor, Subcontractor(s) or Government agency(ies) responsible for performing the activity.

a. Activities coded with a Government Responsibility code include, but are not limited to: Government approvals, Government design reviews, environmental permit approvals by State regulators, Government Furnished Property/Equipment (GFP) and Notice to Proceed (NTP) for phasing requirements.

b. Activities cannot have more than one Responsibility Code. Examples of acceptable activity code values are: DOR (for the designer of record); ELEC (for the electrical subcontractor); MECH (for the mechanical subcontractor); and GOVT (for USACE).

Value: This code is especially valuable in providing vital information across various stakeholders the activities that they are responsible for. In the process, key team members would be able to plan ahead their tasks and resources so as to complete associated deliverables within the planned timeframe. For the project’s general contractor, the RESP code is invaluable in narrowing down, for instance, the activities the each of its subcontractors should know about. There might be situations where different subcontractors, or suppliers, would need to perform similar tasks (i.e., paint works under multiple subcon), and the RESP coding delineates the activities which one needs to do over the other. On the Government side, knowing the activities it is responsible for, project engineers and QA/QC personnel would be made available on time to inspect and/or test completed works for payment validations and to allow the subsequent activities to proceed, thus, avoid impeding the pipeline of works due to delays in releasing some key hold points. These are some of the applications of the RESP coding in facilitating project planning and progress. Further to this and on the forensic analysis of schedules, the RESP code is one of the elements that’s looked at in attributing the activity delays – that is, under whose responsibility the activity is, therefore, the delay should be attributed to that party (unless, of course, the delay was caused by a weather event).

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	As spelled out in the specs, all activities should be RESP coded. However, there might be activities wherein RESP codes don’t apply. In this case, a RESP code, such as “Not Applicable” could be created, thereafter, assign to them. This ensures that all activities would be coded and thus avoids the misinterpretations of the uncoded ones to have been incidentally missed out in the coding process.
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Creating and using the RESP code to mean a different thing, such as the scope, or type of work (demolition, landscaping, geotech, as shown on Figure 2).	This is by far the most common mistake in how RESP code is utilized – to provide information on the type, or scope of work, rather that the responsible party. For project planners, there’s some sort of inclination to do this considering the importance of those details pertinent to the activity. But those would, and should, be covered by the other code, the Feature of Work, or FOW. Moreover, the type of work could be included in the code details without losing the responsibility information by structuring the code definition such as “type of work (subcon/supplier name)” (see Figure 3).
4	Not assigning the activity codes to the correct party.	It’s inherent that the project planner should have a great understanding of the schedule, including the entities responsible in executing the activities, to correctly assign codes.
5	Assigning most of the activities to subcons/suppliers leaving less to the general contractor.	The project’s general contractor should be wary of this as most contracts require it to perform much of the work scope itself, as measured by the certain percentage of the value of work, and not to subcontract.

3. Area of Work (AREA)

What does the contract say: Assign Work Area code to activities based upon the work area in which the activity occurs. Define work areas based on resource constraints or space constraints that would preclude a resource, such as a particular trade or craft work crew from working in more than one work area at a time due to restraints on resources or space. Examples of Work Area Coding include different areas within a floor of a building, different floors within a building, and different buildings within a complex of buildings. Activities cannot have more than one Work Area Code.

Not all activities are required to be Work Area coded. A lack of Work Area coding indicates the activity is not resource or space constrained.

Value: AREA code is telling of the location of where the activity occurs. While the activity description provides the “what,” the AREA code gives the “where” part of it. Although some activities indicate both information in their description, such as “paint wall at 2^nd floor mechanical room,” the AREA coding leverage a consistent approach in labelling the location aspect of activities. Coupled with the WRKP code, and with further data synthesis and analysis, the AREA code supports for having a robust schedule by ensuring realistic work sequencing considering the resource-space constraints.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	While it’s not explicitly cited to assign an activity code on all activities, it is always a good scheduling practice, for better control and management of the schedule, to assign an activity code on each single activity. This also avoids misinterpreting the uncoded activities to have been incidentally missed out in the coding process. For activities that don’t require an AREA, a “Not Applicable” code could be created and assigned on them. Other approach is to create a generic AREA code such as “building”, “parking,” or “site.”
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Creating and using the AREA code to mean a different thing, such as the scope, or type of work (site demolition, submittals, pre-construction, as shown on Figure 4).	While for uninitiated planners (albeit this could happen to anyone, including the seasoned ones), it might not be difficult to get swayed of using the AREA coding, other than it’s spatial intent, such as the area of expertise, or area/type of work, one key thing to remember so as done properly – keep in mind the purpose of the AREA coding. AREA is intended to understand, and thereby, leverage that information, the spatial constraints that activities impose in the totality of the schedule so as to properly sequence the works, including the considerations of the space, or area, limitations.
4	Not assigning the activities to the correct party.	It’s inherent that the project planner should have a great understanding of the schedule, including the location of where the activities are to be done, to correctly assign codes.
5	Incorrectly assigning the AREA code “for” its location, and not “on” its location.	The best way to explain this is by illustration. Consider activities described as “BIM design at 2nd floor” and “Deliver rebars for 2nd floor.” In most cases, these activities would be assigned with a “2nd floor” AREA code. This is incorrect. Again, AREA is “on” the location of the activity, and not where it is “for.” While both activities are for the 2nd floor, they are not to be done on the 2nd floor. Hence, the correct AREA code should be “not applicable” or a generic “building” code, and not “2nd floor building A,” for instance.

4. Modification Number (MODF)

What does the contract say: Assign a Modification Number Code to any activity or sequence of activities added to the schedule as a result of a Contract Modification, when approved by Contracting Officer. Key all Code values to the Government’s modification numbering system. An activity can have only one Modification Number Code.

Value: MODF code is especially important in schedule forensic analyses. For activities that have been added during the course of the schedule updating, for instance, the MODF code provides that information whether they have been added due to an executed proposal, variation, contract modification, change order, or, simply, because they were missed during the baseline development, hence, needed to be added, or detailed/broken-down. Likewise, for activities that have been deleted (not completely removed from the schedule but annotated in the activity description with, say, the word “deleted”), the MODF code is telling of the reason for such whether it was due to a modification in the contract or not. With those details, time impact to the project completion of the added and omitted activities would be ascertained whether they are excusable, or non-excusable delays/gains.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	While it’s not explicitly cited to assign an activity code on all activities, it is always a good scheduling practice, for better control and management of the schedule, to assign an activity code on each single activity. This also avoids misinterpreting the uncoded activities to have been incidentally missed out in the coding process. For activities that are part of the original scope, a MODF activity code such as BL (Baseline) could be added. On the other hand, activities that were introduced into the schedule as part of the variations could be coded by their approved RFP (Request for Proposal) reference (see sample activity code structure on Figure 5).
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Adding modification activities from NOT yet approved changes.	While proposed changes, or variations, are yet to be approved, activities associated with them should not be added into the current, or periodically updated schedules (the monthly updates). These proposals are assessed separately from the monthly schedule updates. Only when the contracting parties have agreed with the proposal that these modifications be added into the monthly updates, and thereabout, the contract completion date may be adjusted. If these activities were added prematurely into the schedule and impacted the forecasted completion date, then, assessment of the delays would be complicated and that instead of the delays being excusable (caused by the client/owner), they might be classified as non-excusable (caused by the contractor), therefore, could be claimed for time and/or cost adjustments.

5. Bid Item (BIDI)

What does the contract say: Assign a Bid Item Code to all activities using the Contract Line Item Schedule (CLIN) to which the activity belongs, even when an activity is not cost loaded. An activity can have only one BIDI Code.

Value: US Government projects require the schedule to be used for payment applications by earned value management, hence, the necessity of the schedule to be cost-loaded – that alone tells all the importance of the BIDI activity coding in the schedule.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	As spelled out in the specs, all activities should be BIDI coded even there are no costs associated with them.
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Not using a resource for cost allocations.	The practice of cost loading activities by expenses, or by direct cost assignment on activities, and not using a resource is normally conducted by planners relatively new to this planning/scheduling profession. While the total costs would reflect the same using either the expenses or that by a resource, what’s missed out, and this is vital in cost analysis, is the time distribution of costs that could readily be viewed in, and extracted from, the Primavera P6 if the cost allocation was made by the resource assignment method. The time-based distribution of costs is handy in generating s-curves and assessing the, well, allocation of costs as a function of time. While level of effort and work summary types of activities could be cost-loaded, milestones should not have be cost-loaded as they don’t have durations.
4	Cost-loading milestone-type activities.	While level of effort and work summary types of activities could be cost-loaded, milestones should not have be cost-loaded as they don’t have durations.
5	Cost-loading activities under the responsibility of the project client/owner.	Activities that are to be performed by the contractor, and its subcontractors and contracted service providers, should only be the ones to be cost-loaded. Hence, the planner should investigate this with the aid of the RESP code. Example of this activity could be removal of existing stockpiles for the site facilities of the contractor wherein this activity is to be done by the project client/owner. However, there could be exceptions to this wherein the preparation of a certain document (by the contractor) is split-cost-loaded with its approval (by the project owner/client). The split, whether at 50/50, or 40/60, could be arranged and agreed by the contracting parties prior to finalizing the cost allocations.
6	Front-loading the cost allocations.	Examples of front-loaded costings are: associating costs to the material’s procurement that are substantially greater than its installations/construction, or using a cost-curve that is not uniform/linear that would introduce more cost weights at the front-end. Since the schedule is used for payment claims, the cost allocations need to be reasonable.
7	Odd overall cost-distributions (s-curve).	While cost loading is made on activities, the overall project cost summed up from these activities could be visually inspected in the s-curve. Ideally, cost distributions should take the shape of a bell (bell-shape curve). “Odd” cash flow means having irregular peaks-and-troughs in the generated histogram. This is indicative of the activities not sequenced by the appropriate efforts needed to complete them.
8	Total cost-loaded does not equal to the project value.	It’s essential that the total amount of the project equates to the contractual value. Each contract line item should be reviewed to ensure that it aligns with the agreed amount, and thereabout, alignment with the overall contract value. See Figure 6 for a sample of contract line items for BIDI coding.

6. Phase of Work (PHAS)

What does the contract say: Assign Phase of Work Code to all activities. Examples of phase of work are design phase, procurement phase, construction phase, commissioning phase, and closeout phase. Each activity can have only one Phase of Work code.

a. Code proposed fast track design and construction phases proposed to allow filtering and organizing the schedule by fast-track design and construction packages.

b. If the contract specifies phasing with separately defined performance periods, identify a Phase Code to allow filtering and organizing the schedule accordingly.

Value: Having a PHAS-coded schedule allows for a convenient way of synthesizing and analyzing it by filtering and organizing the activities by stages, or phases of work. Used with the Feature of Work (FOW) codes, major MEP installation works, for instance, say, an AHU, could be vetted that the schedule contains all relevant flows from its procurement, installation/construction, commissioning, and up to its documentations for the closeout phase.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	As spelled out in the specs, all activities should be PHAS coded.
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Creating codes that are not referring to project phases.	Construction projects generally have discrete phases (i.e., pre-construction, design, construction, commissioning, closeout). It’s important that codes be defined based on the commonly known project phases. As shown on Figure 7, not all the codes described refer to a project.
4	Incorrectly assigning activity codes.	Planners need to understand the delineation of works between phases to allow for correct application of the codes. A correct PHAS code structure is depicted on Figure 8. Mistakes normally take place in assigning whether an activity is under the construction, commissioning, or the closeout phase. The way to easily understand this is that when project elements are being constructed/installed, that constitutes construction. When an equipment undergoes start-up and testing, that’s part of the commissioning. Final inspections, punchouts, and final cleaning, including documents, are part of the closeout phase.

7. Category of Work (CATW)

What does the contract say: Assign a Category of Work Code to all activities. Category of Work Codes include, but are not limited to design, design submittal, design reviews, review conferences, permits, construction submittal, procurement, fabrication, weather sensitive installation, non-weather sensitive installation, start-up, and testing activities. Each activity can have no more than one Category of Work Code.

Value: CATW codes are essentially a further breakdown of the PHAS codes. Thus, CATW codes add convenience in filtering and organizing activities for a more thorough way of building up and reviewing construction schedules. For activities impacted by adverse weather, for instance, the CATW “weather-sensitive installation” and the “non-weather-sensitive installation” facilitate the correct calendar assignment by ensuring that the code and the type of calendar used on activity do align. Filters could be applied to further dissect the procurement PHAS into its components by the fabrication and the delivery CATW.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	As spelled out in the specs, all activities should be CATW coded.
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Defining codes that are not category of work.	The schedule specifications provide sample of what could be used in the CATW coding. As shown on Figure 9, what have been defined under the CATW activity codes were not in line with how CATW should be described.
4	Incorrectly assigning activity codes.	Figure 10 shows a sample of a correctly structured CATW coding. Bear in mind, however, that it’s one thing to define correct CATW codes, and it’s another to correctly assign them on activities. Hence, it’s only prudent that the planner understands what he/she had defined for the CATW codes for their propel applications. For instance, there might be gray areas on what constitute “testing & turnover” versus “quality management.” The planner should, therefore, not create too many CATW codes that their definitions overlap. A fine balance of what’s just enough and what’s too much should be exercised.
5	Assigning a weather calendar on a “non-weather-sensitive” CATW activity, and vice-versa.	Perhaps, this is the most common mistake made in schedules that the calendar assigned doesn’t align with the CATW assigned. These codes are there as a way also to check and validate each other’s assigned codes (i.e., can’t have a construction PHAS and have a delivery CATW), as well as other activity properties, such as the associated calendar, for a robust construction schedule.

8. Feature of Work (FOW)

What does the contract say: Assign a Feature of Work Code to appropriate activities based on the Definable Feature of Work to which the activity belongs based on the approved QC plan.

Definable Feature of Work is defined in Section 01 45 00 QUALITY CONTROL. An activity can have only one Feature of Work Code.

Value: FOW codes help ensure that the full scope of works, as prescribed in the project specifications, has been built into, or included in, in construction schedule. The completeness of the schedule, therefore, could be vetted against the FOW coding.

Common mistakes and how coding should be done the right way:

#	Common Mistakes	Doing It The Right Way
1	Not assigning a code to all activities.	While it’s not explicitly cited to assign an activity code on all activities, it is always a good scheduling practice, for better control and management of the schedule, to assign an activity code on each single activity. This also avoids misinterpreting the uncoded activities to have been incidentally missed out in the coding process. For activities that don’t have an applicable FOW reference, a “not applicable” code could be created to accommodate these.
2	Creating the code at Global level.	To be specific to the project, and such that changes to the code would not incidentally affect other projects, the code should be defined at Project level.
3	Not referencing the code value and/or description against the specifications.	The definable features of work can be found in the project specifications. In there, the section number could be found and could be used to cross-reference the defined FOW codes. Not aligning the Primavera codes with that in the project documents would render cross-checking the project scoping difficult and the FOW codes useless. Figure 11 shows the correct way of structuring the FOW codes.
4	Ambiguous/Unclear FOW codes.	As shown on Figure 12, codes have been described by the division number. While the division referencing might be correct, it would be difficult, however, to understand what work it encompassed that would just render the FOW futile in dissecting schedules. Hence, it would best to include a clear work description in the FOW codes as done on Figure 11.
5	Not including in the FOW codes the division or section number.	Similarly, not including the division or section number would make it difficult to validate the provided and assigned FOW against the applicable specifications, as show on Figure 13. It is worthwhile, therefore, that both the division, or section, number and a clear description be included in the FOW codes.

OTHER RECENT BLOGS

Stakeholder management with prioritization grid.

Managing Project Stakeholders

Stakeholders play a critical role in the success or failure of a project. They have expectations that need to be satisfied for it to succeed. Poor management of stakeholders may lead to its disaster.

Marty Fuentes November 25, 2020