Why the same schedule gives different dates in P6 and Microsoft Project

A day is a conversion, not a unit

P6 stores durations in hours and converts to days for display using the assigned calendar's own time-period settings, so a "5 day" activity on a 10-hour calendar is 50 hours. Microsoft Project stores durations in minutes and converts typed days using one project-wide setting, Hours per day in the schedule options, regardless of which calendar the task actually follows. That asymmetry is the single biggest source of silent duration drift. Bring a 50-hour activity into an MSP file set to 8 hours per day and it displays as 6.25 days; the dates may still be right, but the duration column no longer says what the P6 file said, and the first person who "tidies" it to a round number has rescheduled the job.

The calendar hierarchies differ too. P6 has global, project and resource calendars, with every activity carrying an explicit calendar assignment, and resource-dependent activities working to their resources' calendars instead. MSP layers a project calendar, optional task calendars, and resource calendars, then schedules resourced work in the intersection of task and resource calendars unless the task is flagged to ignore resource calendars. A P6 task-dependent activity has no equivalent of that intersection behaviour. Add calendar exceptions that translate imperfectly through XML, and two files that look identical in a Gantt view are quietly working different hours.

Progressed schedules recalculate on different philosophies

On a baseline the engines mostly agree. The divergence compounds once actuals go in. P6 exposes the decision as a scheduling option: retained logic, progress override, or actual dates, and the choice governs how out-of-sequence progress is handled. Retained logic still forces remaining work to wait for incomplete predecessors; progress override lets the actual sequence win and schedules remaining work from the data date. On a programme with a few dozen out-of-sequence activities, flipping that one radio button can move the finish by weeks. Every P6 reviewer has seen a submission scheduled with progress override that looked healthier than it was.

MSP has no such switch. It treats actual dates as immovable history and schedules remaining work forward, with behaviour shaped by a different set of options: whether in-progress tasks may split, and the four status-date checkboxes that move completed parts back to the status date and remaining parts forward to it. Leave those unticked, which is the default, and MSP will happily show incomplete work stranded in the past, something P6 corrects at every schedule run against the data date. So the same statused network produces different remaining-work dates for a structural reason, and comparing the two finishes without stating each tool's recalculation settings is comparing answers to different questions.

Duration types and percent complete do not map

MSP's task types are fixed units, fixed duration and fixed work, with effort-driven scheduling deciding whether adding a resource shortens the task. P6's duration types (fixed duration and units, fixed duration and units/time, fixed units, fixed units/time) cover similar ground with different defaults, and P6 adds a second axis MSP lacks: percent complete type. Duration, physical and units percent complete are three different fields in P6, and only one of them drives remaining duration. MSP's percent complete is duration-based and writes actual duration when you type it. Interchange formats map these approximately at best. A resource-loaded programme round-tripped between tools can keep every date and still have its progress mechanics rewired, which surfaces one update cycle later when the percentages stop reconciling.

Float is calendar-dependent, so the same network shows different float

Total float is not a property of the network alone. It is measured in working periods of some calendar, and once a programme mixes calendars the number depends on whose calendar does the measuring. An activity on a 5-day calendar feeding one on a 7-day calendar can legitimately show different float either side of the link. P6 lets you choose how total float is computed (start float, finish float, or the smaller of the two) and, separately, which calendar governs relationship lag: predecessor, successor, 24-hour, or project default. MSP asks neither question; total slack is the smaller of start and finish slack, and lag follows the engine's own rule with no option exposed. Through chains of SS and FF relationships with lags, these choices produce genuinely different float columns from identical logic. The practitioner trap is treating a two-day float discrepancy as a data error and "correcting" the file that was never wrong.

Constraints that look alike behave differently

Type a start date into an auto-scheduled MSP task and you have silently created a Start No Earlier Than constraint. Most of the surprise constraints found in DCMA screens of .mpp files arrived exactly this way, from someone typing dates into the entry table. MSP also defaults to honouring constraint dates over logic, so a constrained task can sit earlier than its predecessors allow without any warning stronger than a small indicator icon.

P6's catalogue is wider and its severities are explicit. Start On and Finish On pin both early and late dates and so zero out float locally; Mandatory Start and Mandatory Finish override network logic outright, which is why most standards treat them as findings rather than tools. There is a project-level Must Finish By that drives the backward pass and manufactures negative float across the whole programme, with no direct MSP equivalent; MSP's Deadline field influences reporting and slack but is a different mechanism. Conversion between the two catalogues is lossy in both directions, and P6 secondary constraints generally do not survive at all. Before comparing dates, diff the constraint inventories, because a dropped or downgraded constraint will move dates while every duration and relationship matches perfectly.

Even "critical" is a setting

The red bars are the first thing a review meeting looks at, and they are computed differently. MSP marks a task critical when total slack is at or below a threshold, zero by default and adjustable in options. P6 offers the same float-threshold definition, but also Longest Path, which traces driving relationships back from the finish and is the more robust choice on multi-calendar programmes where genuine critical work can carry non-zero float. MSP has no longest-path option. Two honest reviewers can therefore disagree about which activities are critical while agreeing on every date in the file. Neither is misreading anything; they are quoting different definitions.

The pre-comparison checklist

Before putting a P6 date next to an MSP date in front of anyone, pin these down and record them alongside the comparison:

• Data date versus status date. Same date, and both files actually rescheduled against it.
• Hours per day. Every P6 calendar's time periods against MSP's single project setting; note any calendar where they differ.
• Calendar assignments. Task calendars, resource-dependent activities, and any MSP tasks flagged to ignore resource calendars.
• Progress recalculation. P6's retained logic, progress override or actual dates; MSP's split and status-date options.
• Float computation. P6's compute-total-float-as and lag-calendar options, and the count of non-FS relationships with lag where they bite.
• Constraint inventory. A field-level diff of constraint types and dates on both sides, including P6 secondary constraints and the Must Finish By date.
• Critical definition. Float threshold or longest path, and the threshold value in both tools.

If a date discrepancy survives that list, it is worth a real investigation. In practice, almost none do.