When submitting a project schedule, your contract may require you to include a baseline schedule narrative. A schedule narrative is a written document that outlines important information about the project. The point of the narrative is to translate information from project managers to stakeholders. These users may have different levels of experience with scheduling. A project manager may be able to look at a Gantt chart and understand everything about the project. However, a stakeholder or owner might not have that level of familiarity. With a schedule narrative, however, project information can be accessible to everyone.

In this article, we will overview how to write a baseline schedule narrative. The following examples all include screenshots from Primavera P6 Professional 23. However, this process will be the same, regardless of scheduling software.

What is a Schedule Narrative?

A schedule narrative is a comprehensive explanation of the project schedule. Presented as a word document, the narrative helps translate information from the project file. Schedule narratives will outline the project’s scope, milestones, critical path, and projections.

Not every project requires a schedule narrative. Typically, your contract will state whether you need to submit a narrative. If a narrative is required, you should prepare one for each schedule submission. This includes not only the baseline schedule, but also updated schedules and time impact evaluations. Each of these different narratives should present different information about the project. For example, the baseline schedule narrative will overview the project plan. On the other hand, status update narratives will overview the work performed thus far.

Baseline Schedule Narrative Requirements

Baseline schedule narratives will have different requirements depending on your contract. The contract specifications will typically outline the information required in the narrative. For example, here are the narrative requirements for Caltrans projects, as of 2026:

On the other hand, USACE projects require different information for their schedule narratives. Here are the narrative requirements for USACE projects, as of 2026:

When writing a narrative, always make sure you’re following the requirements within your contract specs. You can also design your narrative to match your organizational standards – such as by adding a cover page with company colors or images.

However, regardless of contract, most baseline schedule narratives will require the same sets of data. We recommend including at least the following information within your schedule narrative:

Project Summary & Scope

At the top of your narrative, you should include identifying information about the project. Here, it’s recommended to include the Project Name, ID, and Contract Number. Along with these details, you should include some basic information about the project you’ll be submitting. Some important variables to add here could include the date you’re submitting the project, the project filename, and the data date.

In this section, you may also want to summarize the project scope. Here, you would include information such as the project’s goal, location of work, and schedule time frame. Keep this brief – you do not need to outline every aspect of the project. Remember, this narrative will be accompanying the project file. The project file will describe all activities and dates for the schedule. Here, you are simply summarizing this information in a written format.

Milestone Dates

Next, you’ll want to outline the major milestone dates for your project. I like to do this in a table to keep the document well organized. Depending on your project, you may have additional milestones dates, but you should always include at least the following:

• Contract Approval Date: This is the Contract Award date for the project. 
• Start Date: This is typically the Notice to Proceed date. This is the earliest date in which any work will begin, such as submittals or procurement.
• Start of Onsite Work: This is the date in which field work will begin. Typically, this is the first date of the Construction phase, rather than Preconstruction.
• Project Completion Date: This is the date in which the project is currently expected to finish. Typically, this date will match the Contract Completion Date. If these two dates are different, you will want to also add a field for Contract Completion, to show how far ahead or behind your project is. 

For a baseline schedule, your Project Completion Date and your Contract Completion date should be the same. If your Project Completion Date is earlier than your Contract Completion Date, you should add an activity called Float. You’ll want to sequence this activity in between the last activity of work and the project’s completion milestone. Add duration to this activity until your project completion date matches the contract completion date. Essentially, this activity represents any extra time you have in the schedule. You do not need to have any plans to use this float, but it is available if you need it. If issues occur and your project gets delayed, this float activity will give you more leeway.

Schedule Development Process

This is an explanation of how you developed the baseline schedule. In this section, you should include the scheduling methodology used (such as critical path method vs pull planning) and the software utilized (such as MS Project or Primavera P6). 

You may also want to include a screenshot of the scheduling options within the software you’re using. For Primavera P6, this would be the Schedule Options window. In Microsoft Project, this would be the Project Options window.

Schedule Structure

Next, you will give a brief overview of the project’s sequence and structure. This can include information such as how you’ve divided WBS layers, and what types of activities will occur in each one. You may also want to give some information about dependencies, coding, and ID structure. This section can be a bit difficult to write, as you may be working on a very long project. Regardless of project length, however, this should be relatively brief. Try to condense this information into just a few paragraphs if possible.

It’s always a good idea to include screenshots to go along with your explanation. For example, you might include images of the WBS structure or any codes you’ll be using.

Work Restrictions

In this section, you should identify any unusual conditions or restrictions that will affect the project. Generally, this relates to your resources, including labor, equipment, and materials. Here, you would outline factors about your resource usage, such as if you’ll be utilizing multiple shifts or overtime. If your resources represent crews of people, you should note the number of crews available and their max availability. In terms of equipment and materials, you should list any restrictions on availability that may affect the project’s work.

Work Schedule and Calendars

This section should outline the calendars and working periods for your project. If your project is utilizing multiple calendars, you should describe the working periods for each – including hours per day and days per week. 

Along with the working hours, you should also include a list of holidays or non-work dates for the project. I like to display all holidays in a table, and then highlight which holidays will occur within the project’s timeline.

Critical Path

The critical path is the longest sequence of dependent activities within the project. Ultimately, this is the sequence of activities with no float – or no time for delay. These activities determine the project’s overall duration. You can provide a list of critical activities, or take a screenshot of the table with a Critical filter displaying. In Primavera P6, you can get a list of critical activities using the Schedule Log, the Check Schedule Report, or by running a custom report on the project. 

When providing this list, make sure to include both the activity name and the activity ID. It’s also useful to list the total number of critical activities within the project.

Current and Anticipated Delays

In this section, you will list any actual or anticipated delays that may affect the project’s completion. For each delay, you should list the cause of the delay, the impact it will have on the project, and any corrective action that you may take to mitigate it.

If your project has no anticipated delays, you can simply type the following: “There are no anticipated delays for this project at this time.”

Pending Items and Statuses

Here, you should list any pending items – such as permits, change orders, time adjustments, and noncompliance notices. For any of these pending items, make sure to note the current status and anticipated delivery dates. For a baseline schedule, you may not have many pending items – as the project has not yet started. Pending items will typically come about once the project actually begins and you start statusing activities.

If your project has no pending items, you can simply type the following: “There are no pending items for this project at this time.”

Reasons for Early/Late Completion

If your project completion date is late or early compared to the contract completion date, enter that in. Typically, you would need to receive approval for a late completion on a baseline schedule. Here, you should add any documentation related to that late completion approval.

As mentioned earlier, you should try to get your project completion date to match the contract completion date. There is typically no benefit to showing your baseline schedule completing early. Your contract will hold you to this baseline schedule, so you’ll want to show that you’ll be using as much time as you have available for the project. Once the project begins and you start performing status updates, you may actually finish the project early. However, because delays are common, you will not want to assume this in your baseline schedule. Typically, your baseline schedule should show that you are using all days available according to your contract. It is always better for your project to unexpectedly finish early, rather than expanding past the original baseline completion date.

If your project completion date matches the contract completion date, you can enter in the following: “None. This project is expected to complete on the Contract Completion date.” 

Early Completion Date and Float

In this section, you’ll note the early completion date for the project. The early completion date is the earliest date that the project can complete. Along with this date, you’ll note whether or not you’ll be utilizing float. As mentioned earlier, you can add a “Float” activity if your schedule is expected to finish early. This is a better practice than entering in an early completion date – as your contract will hold you to this date. With an activity called “Float”, you can push the project’s completion date to the contract completion date. This will give your project wiggle room, or extra time that you can use if delays occur. Along with noting this float value, you should also state whether you currently have plans to use it – although this typically wouldn’t be the case for a baseline schedule.

Lags

Relationship lag, or lag, is a waiting period between two activities in a relationship. Lag is the number of days of downtime between the finish of the predecessor activity and the start of the successor activity. Adding lag to activities is typically allowed and often required. For example, you might have limited resource availability, preventing you from going immediately from one task to the next. Your contract will usually note how much lag is acceptable within the project. As a best practice, you should use positive lag on less than 5% of your activity relationships. You should not use negative lag at all – most contracts will prohibit it.

In this section, you should list all activities with lag, along with an explanation of why you’re using it. You can either type out a list of activities, or you can include a screenshot of the Lags section of the Check Schedule Report.

If your project is not utilizing any lag, you can just enter in “This project is not utilizing lag on any activities.”

Constraints

In this section, you should list any activities that are utilizing constraints. Constraints help control when an activity can start or finish. They either enforce a specific date to the activity (hard constraints), or they set boundaries on when the activity will perform (soft constraints). Constraints are useful to model real-world situations, such as worksite restrictions. Like lag, contracts will state what constraint types are acceptable, and how often you can use them. It’s a scheduling best practice to only use soft constraints (Start On/Finish On) on less than 10% of activities. Hard constraints (Mandatory Start/Finish) are typically not allowed.

If you are utilizing any constraints, you would want to list the activities using them here. You should list the constraint type used, the constraint date, and the reason for using the constraint. You can either type out a list of activities, or you can include a screenshot of the Constraints section of the Check Schedule Report.

If your project is not using constraints, you can enter in the following: “This project is not utilizing constraints on any activities.”

Resource Allocations

If you’re working on a cost-loaded project, you should also include information about resource allocation. Here, you should overview how you are optimizing resources across the project’s timeline. If you are dealing with overallocation, you’ll want to include information about it – such as why it occurred and how you plan to mitigate it. Typically, you’ll deal with this by either hiring additional resources or by offering overtime work. If you utilized resource leveling to optimize resource allocation, you should also note that here.

Along with a short written explanation, it may be a good idea to include screenshots of your units and costs over time. In a program like Primavera P6, you can access histograms of this data using the Activity Usage Profile. Here, you can use the Activity Usage Profile Options window to switch between viewing cost and unit values. I would recommend including a screenshot of each of these histograms individually. This will give a clear picture of how you’re utilizing resources across the project’s duration.

Additional Information

Lastly, you should include any additional information necessary to describe the project schedule. Remember, the point of the baseline schedule narrative is to provide necessary information about the project. The idea is that someone without access to the project file should understand how the project will progress. Here, you should add any imperative information not noted in the previous sections to paint a clear picture of the project plan.

Summary

There are many requirements to getting a baseline construction schedule approved. Your contract should list everything required – but you will often need to submit a project file, a PDF printout, and a schedule narrative. A baseline schedule narrative is a written document that overviews the project plan. You can think of the narrative as a translator between the project schedule and the stakeholders. As a scheduler, it may be very clear to you how the project will go from the project file – but this won’t be the case for everyone reviewing the schedule. With the schedule narrative, you can outline important information about the project. Using the guidelines outlined above, you should be able to create a clear picture of the project plan. However, every project is different, and different contracts require different schedule narratives. Always remember to review your contract for a full list of schedule narrative requirements.

Looking for a baseline schedule narrative template? You can download the template we used in this article here.

Need assistance writing a schedule narrative? Here at Taradigm, we have years of experience with all aspects of CPM scheduling. We can assist you with baseline schedules, status updates, and delay claims. If you would like help with your baseline schedule or schedule narrative, contact us here.

If you have any comments, questions or suggestions, please use the comment section on the bottom of this page. Don’t forget to subscribe to our blog to get more CPM scheduling tips & tricks directly in your inbox!

Lauren Hecker is a CPM Scheduler with experience in Oracle Primavera Cloud. Primavera P6, and Microsoft Project. She teaches both onsite and virtual scheduling courses. To see her next open enrollment course, please visit our calendar. To schedule an onsite or custom course, please contact us!