Resource planning records in engineering firms: staffing data and privacy

What do resource planning records show?#

Resource planning records show how an engineering firm matches people to work over time: who was planned on which project, for how many hours, in which phase, and what actually happened. Whether they live in a project accounting system such as Deltek Vantagepoint or BQE CORE or in a planning spreadsheet, these records sit beside timesheets, project budgets and schedules.

The value is in the pattern, not the person. Forecast versus actual hours by phase, reassignments when a project slipped, and the mix of senior and junior roles on different project types all show how professional services work is planned and corrected. AI developers building planning and scheduling agents tend to look for that kind of decision history.

The risk is in the same records. Staffing data is personal data about employees, and it often sits next to pay, leave and performance information in the same system.

Which fields to keep, transform or drop#

The field rule for resource planning data is to keep what describes the work, transform what identifies people or places, and drop what is personal or commercially sensitive. Apply it to every export, including the ones built for internal analysis.

Pseudonymous IDs should be consistent across the whole export, so the same person maps to the same ID on every project, and the key linking IDs to names should stay inside the firm.

Which staffing patterns are worth keeping#

The staffing patterns worth keeping are the ones that show a planning decision and its consequence. A static roster says little. A plan that changed, with the reason and the result, shows how a firm manages capacity.

Each of these patterns survives pseudonymization intact, because none depends on knowing who the individual was. That is a practical test for any field: if the pattern still reads correctly with names removed, the name was never needed.

• 1Forecast versus actual hours by phase and role, showing where estimates ran over or under.
• 2Reassignments after a schedule change, with the project event that triggered them.
• 3Role mix by project type, such as senior review time against production time.
• 4Ramp-up and ramp-down timing around milestones and submissions.
• 5Capacity views used in resourcing meetings, with the decisions taken.

Why named employee data is a risk#

Named employee data is a risk because staffing records reveal more about individuals than they seem to: hours worked, absences, performance pressure and seniority can often be inferred. Privacy and employment laws that may apply depend on where employees live and work, including state privacy laws such as the CCPA in California, and counsel should assess them for each package.

Pseudonymization reduces the risk but does not remove it on its own. In a small office, a role such as the only senior geotechnical engineer is identifiable without a name. Generalize rare roles and small locations, and check for combinations of fields that point to one person.

Free-text fields deserve their own pass. An assignment note saying someone moved off a project for family reasons carries health or family information that should never leave the firm.

Notices, policies and the people involved#

Notices and policies set what employees were told about how their information is used, so review them before scoping staffing data. The employee handbook, any privacy notice for workers and the HR system's terms are the starting documents.

Bring HR in early rather than at sign-off. HR knows which fields hold sensitive information, which employees have special arrangements, and how a question from staff about the project should be answered.

• 1Check what the employee privacy notice says about uses of personnel and timekeeping data.
• 2Confirm whether any employees are covered by collective bargaining agreements.
• 3Identify former employees and independent contractors, whose records may follow different rules.
• 4Agree the pseudonymization method and the list of dropped fields with HR.
• 5Record each decision so it can be explained to staff if they ask.

Illustrative: a staffing history prepared for review#

Illustrative: a fictional engineering firm with transportation and water practices runs resource planning and timesheets in Deltek Vantagepoint. Its COO wants to know whether several years of planning history could sit alongside project review records in a licensing package.

The firm exports plans and actuals by project phase and role, replaces names and employee numbers with stable pseudonymous IDs, bands seniority and merges its small satellite offices into one region. It drops all rates, salaries and leave data and removes assignment notes that mention personal circumstances.

One check changes the plan. The firm's smallest discipline group is so small that even banded seniority points to individuals, so its hours are merged into a broader engineering category before anything else is reviewed.

Counsel reviews the employee privacy notice and the state laws that may apply before the COO approves the field rules. The resulting history shows how the firm staffs bridge and treatment plant projects through each phase without naming anyone.

How SourceX approaches staffing data#

SourceX treats staffing data as sensitive by default. In the Preparation step of the SourceX five-step transaction, names and identifiers are replaced, pay and personal fields are removed, and re-identification checks look at small groups and rare roles.

The privacy record in the SourceX Evidence Packet lists each field's treatment, giving the firm's signer and the licensee one shared field-by-field record of every transformation. The firm approves the field rules before any data leaves its systems.