Moving Schedules Between P6, MS Project, and Everything Else

Sooner or later you'll have to move a schedule from one tool to another: the owner wants P6, your team uses Microsoft Project, a sub sends an Excel bar chart, a consultant needs the file to run an analysis. The import button usually works. The problem is that it works quietly when things went wrong, too. This post covers which formats to use, what tends to break in translation, and a verification routine that catches the problems before somebody bases a claim on them.

The formats

A few practical notes:

• Prefer .xer or P6 XML out of P6, and MSPDI XML out of MS Project. These carry logic, calendars, and progress. P6 .xer files explained goes into the .xer structure.
• .mpp is a closed binary format. Many non-Microsoft tools can't read it, or read it partially. If you're sending a Project schedule to anything other than Project, save as XML first.
• A PDF is not a deliverable for analysis. You can't check logic, float, or constraints from a picture. If a spec requires native files, a PDF doesn't satisfy it.
• Excel loses most of the schedule. It can carry IDs, names, durations, dates, and maybe a predecessor column. It doesn't carry calendars or scheduling options. See Excel schedules for when that's acceptable.

What breaks in translation

P6 and MS Project both do CPM, both support FS, SS, FF, and SF relationships with lags, and both handle calendars, constraints, and progress. They don't do these the same way. The differences are where conversions go wrong.

Calendars

This is the most common silent failure. Holidays may not come across. Work weeks may map to a default. Hours per day may differ: P6 stores durations in hours and converts to days using each calendar's hours per day, and if the receiving tool assumes a different value, every duration shifts. A 10-hour-day calendar read as 8 hours makes a 5-day activity look like 6.25 days.

After any conversion, open the calendars and check the work week, hours per day, and a few known holidays.

Lags

In P6, a lag is measured on a calendar chosen by a scheduling option (for example, the successor's calendar or a 24-hour calendar). In MS Project, a lag can be in working days, elapsed days, or a percentage of the predecessor's duration. A 7-elapsed-day concrete cure lag that turns into 7 working days on a five-day calendar stretches to about nine calendar days. Percentage lags have no direct P6 equivalent and get converted to fixed values. Check every lag that represents something real. Lags and leads covers why they deserve scrutiny anyway.

Constraints

P6 allows a primary and a secondary constraint on an activity. MS Project allows one constraint per task. Constraint type names don't map one-to-one. And MS Project quietly adds "Start No Earlier Than" constraints when someone types a start date onto a task, which then travels into P6 as a real constraint. After import, list every constrained activity and make sure each one was intended. See schedule constraints.

Summary tasks and activity types

MS Project summary tasks are rolled-up tasks that can carry their own relationships. P6 WBS nodes can't hold logic. A link to a summary task in Project has to go somewhere when it arrives in P6: it may be dropped, or the converting tool may push it down to child activities. Either way the logic changes.

P6 has activity types that Project doesn't, such as level of effort and WBS summary activities. These usually arrive as ordinary tasks, sometimes with odd durations.

Progress and scheduling options

P6 has a project-level choice between retained logic and progress override for out-of-sequence progress. MS Project handles in-progress work through its own options. The same statused schedule can calculate a different finish in each tool for this reason alone. Retained logic vs. progress override explains the difference.

Percent complete is another mismatch. P6 has duration, physical, and units percent complete types. Project has percent complete, percent work complete, and physical percent complete. The numbers may come across, but they may not mean the same thing on the other side.

Float and critical path

Both tools calculate total float, but the definition of "critical" is a setting. P6 can flag critical by total float threshold or by longest path. MS Project uses a slack threshold, zero by default. With multiple calendars, constraints, or open ends, the two can disagree about which activities are critical.

Baselines

MS Project stores baselines inside the project file: the main baseline plus up to ten more. P6 stores each baseline as a separate project. Converting from Project to P6 may bring baseline dates as fields but not as a usable P6 baseline project. Converting from P6 to Project usually brings no baseline unless you export it separately. See baselines and re-baselining.

Codes and custom fields

P6 activity codes, MS Project custom fields and outline codes, and other tools' tags don't map neatly. Expect to rebuild layouts and filters, and to spot-check that codes landed on the right activities.

A verification routine

Don't trust a converted schedule until it passes these checks. Write the results down; if the schedule ever matters in a dispute, you'll want to show the conversion was checked.

1. Count activities. Same number in source and destination, by activity type if you can. Summary tasks will account for differences; explain them.
2. Count relationships. Same number, by type (FS, SS, FF, SF). A drop usually means links to summary tasks or to external projects were lost.
3. Check the data date. Same in both.
4. Recalculate and compare the finish. Schedule the converted file and compare the project finish and key milestones to the source. They should match to the day.
5. Compare float on a sample. Pick ten activities across the schedule: some critical, some with a lot of float. Compare total float. If they differ, find out why before you go further.
6. Compare the critical path. Trace the driving path in both. Same activities, same order.
7. Check calendars. Work week, hours per day, holidays.
8. List constraints. Same constraints on the same activities, with the same dates.
9. Check lags. Filter to relationships with lags and compare values and units.
10. Spot-check progress. A few in-progress activities: actual start, remaining duration, percent complete.

A short record of the checks might look like this:

Source:       Contractor update, P6, data date end of week 32
Destination:  Converted copy, data date end of week 32

Check                         Source    Destination   Match
Activities                    1,184     1,184         Yes
Relationships                 1,652     1,649         No: 3 links to external project dropped
Project finish                Week 81   Week 81       Yes
Substantial Completion float  -6d       -6d           Yes
Calendars                     3         3             Yes, holidays verified
Constraints                   14        14            Yes

The three dropped links aren't a reason to stop, but they need a note: which activities lost them, and whether those activities now have open ends that change their float.

Practical advice

• Convert once. Every round trip loses something. Pick the tool of record and keep the master there.
• Clean before you export. Remove unused calendars, fix open ends, delete stray constraints. A clean source converts more cleanly.
• Send a PDF with every native file, so the receiver can see what you saw and compare.
• Ask what the receiver will use it for. A consultant running a forensic analysis needs a different level of fidelity than an owner's rep who wants to look at the bars.
• For MS Project files, send XML. schedule.construction, for example, imports P6 .xer, MS Project XML (MSPDI), and Excel, but not native .mpp yet, which is typical of tools outside Microsoft's own.

Key takeaways

• Use .xer or P6 XML out of P6, and MSPDI XML out of MS Project. PDFs and spreadsheets aren't full schedules.
• Calendars, lags, constraints, summary-task logic, and progress settings are where conversions go wrong, usually silently.
• Verify every conversion: activity and relationship counts, data date, recalculated finish, float on a sample, critical path, calendars, constraints, lags.
• Write down the verification results. They matter if the schedule ends up in a dispute.
• Keep one tool of record and avoid round trips.