The client asks for the schedule. Not a status report — the file, so their planner can look at it properly. It is a reasonable request, you have nothing to hide, and you attach it.
Along with the dates you have just sent them the name of every person on the project, which of them is an employee and which a contractor, how many hours each one is booked for, and — if the plan is costed — what each of them is worth per day.
A plan is a personnel file that happens to have dates on it
Nobody builds it that way on purpose. It accumulates. A resource gets a full name because that is how you tell two Andreas apart. A subcontractor gets its company name because the procurement code means nothing to anyone. Day rates arrive because someone wanted the cost curve to be real. Six months later the file carries a small HR database, and the file is what people ask for.
The uncomfortable part is that the recipient does not need any of it. What they need is the shape: how much work sits where, which weeks are overloaded, whether the specialist they are waiting for is booked solid until March. That question has nothing to do with anybody’s surname.
The distribution survives, the identities do not
There is a setting that does exactly that, and nothing else: it lets you anonymise resource names while the plan itself stays intact. Obfuscate Resource Names renames every resource in the copy to its own identifier — RES-0001, RES-0002, and so on, numbered from the resource ID already in the plan.
The assignments are not touched. Every hour, every booking and every date stays attached to the resource it was attached to before, which is the whole point: rename the label and the workload chart keeps its exact shape.
What the other side can still do with that file: read the critical path, see that one resource carries 320 hours while another carries 70, check whether their own delivery lands in a week you already have booked out. What they can no longer do is learn that the 320 hours belong to Mario Rossi, or that you brought in ACME Consulting for the commissioning.
It is worth being precise about what this is and is not. Anonymising resource names removes the identities from the file; it does not make a plan unrecognisable to someone who already knows your organisation. If four resources appear and your recipient knows you have exactly four people on the job, arithmetic will do the rest. Obfuscation is a reasonable measure against the ordinary risk — a file forwarded, archived, or opened by someone it was never meant for — not a guarantee against a determined reader. Where the file is processed matters just as much: what a plan carries about the people in it.
The option that deletes what you meant to show
There is a detail here worth knowing before you tick boxes, because two of them overlap.
Reset Financial Data (Costs, Work, Baselines) takes precedence over renaming. When it is on, resources are not renamed — they are removed from the plan altogether, which is the only way to be sure no rate, no cost and no name survives anywhere in the file. And the label means what it says: work and percentages are zeroed too. The dates hold — tasks are switched to fixed duration first, so the bars do not collapse — but the effort behind them is gone, and the recipient gets a schedule of tasks with nobody on them and no hours in them.
That is the right answer sometimes. If the file is going to a public tender, an insurer or a court, less is better and the workload is not their business. But if the reason you are sending the plan is precisely so somebody can look at the resource loading, that one checkbox will quietly delete the thing you meant to show, and the run will report success.
So the two useful combinations are:
- Names out, workload in — tick Obfuscate Resource Names, leave Reset Financial Data alone. The recipient sees the distribution against anonymous IDs.
- Everything out — tick Reset Financial Data. No people, no rates, no hours. A pure schedule of dates.
Both are legitimate. Choosing between them is the actual decision, and it is easier to make when you know what each one costs you.
The pool it refuses to touch
One case stops the job instead of processing it. If the plan is connected to a shared resource pool, the run is blocked, the pool is named on screen, and you are asked to disconnect the project by hand before trying again.
The reasoning is not caution for its own sake. A plan attached to a pool does not own its resources: it borrows them from a file that other projects are using at the same time. An obfuscation routine that followed the link would be renaming your colleagues’ live resource list — in every plan connected to it. Refusing is the only safe behaviour, and being told which pool is in the way is what lets you fix it in a minute.
What lands on the other side
The original file is never modified. The result is written next to it as <name>_Cleaned.mpp, and the report at the end counts what was actually done, resources included — so “it ran” and “it changed something” are two different claims you can check. With every option switched off the run does not start at all: a copy identical to the original, reported as a success, is worse than no copy.
Microsoft Project does have to be installed, because the file is opened through it — but in a hidden instance of its own. Your own Project session is never touched, and nothing leaves the machine: there is no service, no upload, no account. For a monthly pack of plans there is a batch mode that does the same work without the window.
Then you attach the copy instead of the file, and the schedule you send answers the question that was asked, and only that one.
GanttShield prepares a Microsoft Project plan for someone outside the team: it renames resources and tasks, clears notes, resets costs and work, and can strip the dependency links while keeping the dates — writing a separate clean copy and leaving the original untouched. Everything runs on your own machine. Version 1.1.1, with a 15-day trial that needs no key.
#MicrosoftProject #DataProtection #ProjectManagement #PMO #GanttShield