Reviewing a Schedule You Received: What to Strip Before Import
A schedule arrives from a contractor. The first thing everyone does is open it and look at the dates. The second thing, usually a week later, is discover what else came with it.
An XER or XML project file is not a picture of a schedule. It is a working document that carries the resource dictionary, the rates behind those resources, the risks, the notes, the UDFs, and the names of the people who built it. If the sender did not think about that, none of it was removed.
What a received file tells you about its sender
Before any of the schedule review happens, it is worth knowing what is in the file. Some of it is commercially sensitive to the sender. Some of it is commercially sensitive to you, because you are about to put it in your database.
- Resource and role rates. If the sender cost-loaded the schedule, their rates are in the file, and they will land in your resource dictionary on import.
- Resource names. Real people, or at least the codes that map to them.
- Risk register entries. Contractor risk notes are often more candid than the schedule they sit next to.
- Activity and project notes. Internal commentary that was never meant for a client.
- UDFs and project codes. Their internal coding structure, and sometimes client names from other jobs.
- POBS tables. Seldom useful to you, often large.
- Global calendars and activity codes. The objects that will merge with yours on import.
None of this is a security breach. It is just what the format carries when nobody strips it.
Quality is a different question
This page is about data, not schedule quality. If you want to know whether the schedule itself is sound, that is a DCMA 14 point assessment and a logic review. The schedule review guides cover it properly; this page stays on the data.
Both checks matter, and they answer different questions. Quality asks whether the plan is any good. Data asks what the file exposes and what it will do to your database.
The triage checklist
Work through this before the import, not after. It takes about ten minutes on a normal project file.
1. Open the file without importing it
You need to see the contents before they touch your database. A read-only viewer is enough for this, and it is the only way to look at the resource and cost tables without loading them into P6.
2. Check whether costs are loaded
If the resource rates are populated, decide now whether they belong in your database. Sometimes yes, because you are the one paying. Often no, because the sender's rate card is their business, not yours.
3. List the global objects
Count the calendars and activity codes. Compare the names against what you already have. Anything with the same name and a different meaning is a merge waiting to happen.
4. Look at POBS
If the file is unusually large for the number of activities, POBS is usually why. Removing it makes the import faster and costs you nothing.
5. Read the notes and risks
You are looking for two things: anything confidential that should not be in your database, and anything that changes how you read the schedule.
6. Decide what to keep
Some of what arrives is genuinely useful. Keep the logic, the activities, the relationships, the WBS, the codes that describe the work. Everything that describes the sender's commercial position can go.
What to keep so the schedule still works
There is a floor below which cleaning breaks the file. Remove the wrong things and the import fails, or succeeds with a schedule nobody can read.
- Activities, relationships and the WBS. This is the schedule.
- The calendars the activities actually use, converted to project level rather than deleted.
- Activity codes that carry meaning about the work, not about the sender's internal accounting.
- Baselines, if the contract requires them. Note that an XER export does not include baselines unless the sender added them deliberately, so their absence is usually the format, not the sender.
Doing it without breaking anything
The manual route is to open the XER as text and delete sections, or to import into a scratch database and clean it there. Both work. Both are slow, and both leave you checking whether you got everything.
ScheduleCleaner reads the received file and writes a cleaned copy. You select the categories to remove or convert, the original stays as it arrived, and the copy is what goes into your database. Rates, costs, risks, notes, POBS and resource names can all come out; calendars and activity codes move to project level so they cannot merge with yours.
That copy is also a record. If anyone asks later what you did with the contractor's rates, the answer is that they were never imported.
Try it on the next file you receive, or read how P6 handles an XER on import first if you want the mechanics.
Related reading
Ready to clean your next P6 schedule?
Remove, convert and anonymize sensitive data in XER and XML files before you share them.