PAUMS (Project Allocation & Utilization Management System) is an executive-grade system that converts raw timesheets and allocation data into auditable monthly utilization snapshots.
No. PAUMS consumes timesheets but does not replace or manage time entry. It is an analytics and reporting system.
Executives, delivery leaders, finance teams, TPMO, and audit teams.
A Monthly Snapshot is an immutable record of utilization for a specific month.
To ensure auditability, consistency, and executive trust. All dashboards and exports read from snapshots only.
Dry Run validates files, checks dates, detects errors, and shows impact without modifying the database.
Execute deletes the target month's snapshot & allocations, ingests new data, and rebuilds the snapshot.
Yes — but only for the target year and month. Other months remain untouched.
APAC timesheets are uploaded during the monthly upload process via CSV.
Staging temporarily loads APAC data, validates it, and prepares it for commit.
EMEA uses allocation percentages instead of timesheets. Utilization is inferred from FTE allocation.
No. The system normalizes allocations and rejects values above 1.0.
Utilization = Utilized Hours ÷ Available Hours × 100
This can happen due to overtime or incorrect timesheets. PAUMS flags but does not silently cap data.
It recalculates employee- and org-level metrics from raw data and stores them permanently.
The dashboard will show no data for that month until rebuilt.
No. It only deletes derived snapshot data, not raw timesheets or allocations.
Yes — for the target month only.
The transaction is rolled back and existing data remains intact.
Yes. All numbers can be traced back to source data via snapshots.
Yes. If you upload only APAC data for a month, EMEA allocations remain unchanged unless explicitly deleted.
Yes. Snapshot rebuild will infer utilization for EMEA and keep existing APAC timesheets.
No snapshot exists → dashboard shows no data for that month.
Yes, only for the selected year & month.
Yes. PAUMS supports safe historical reprocessing.
Yes. Uploading only one region is supported.
To prevent accidental deletion of production snapshots.
No. Zero writes occur.
Yes, by using Dry Run or deleting snapshots temporarily.
No. PAUMS is designed for single monthly execution to avoid data locks.
timesheets, emea_allocations, employees, projects
monthly_snapshot only
Yes, if: No source data exists, Invalid month/year, Database lock timeout
No. Each month is independent.
No. They are system-generated.
To guarantee consistency and audit safety.
No. Raw data remains untouched.
Yes, safely, without touching raw data.
To ensure fast, predictable, and consistent reporting.
Yes. Running it twice produces the same result.
During APAC upload commit phase.
Yes, based on employee + date.
Yes. PAUMS does not cap reality; it flags anomalies.
Only if reflected in timesheets.
No. It relies on recorded time.
It may be excluded from the target month.
Yes, by re-uploading that month.
Yes, for the same month only.
Yes. PAUMS supports mixed-region logic.
Upload is rejected or flagged in Dry Run.
Allocation % × Available Hours.
It is normalized or rejected.
Yes. Allocations are stored by year & month.
No. Allocation-driven model.
Yes, but contributes no utilization.
Yes, but capped at 1.0 per employee.
Only reflected after re-upload.
Yes, if missing.
Yes, during upload if not found.
No. Hierarchy is reporting-only.
Standard monthly capacity (e.g., 184).
Actual worked or inferred hours.
Subset of utilized hours mapped to billable work.
Non-billable organizational work.
Yes: Available − Utilized.
Yes, in overtime scenarios.
Yes. Utilized = Billable + TPMO.
Yes, to 2 decimal places.
Derived from employee snapshots.
By design — integrity rule.
FastAPI APIs, monthly_snapshot, Vanilla JS.
Missing snapshot or JS load failure.
No. Snapshot-driven.
Yes, employee → project.
Charts show empty state.
Yes, from API metadata.
Yes.
No.
Yes (CSV/PDF planned).
Read-only friendly.
No. SQL-first, explicit control.
Predictable locking, enterprise-grade.
Long transactions + delete + insert in one session.
Batch inserts + shorter transactions.
Yes, selectively.
Yes (READ COMMITTED).
Yes, snapshot model scales well.
Architecture-ready, single-tenant now.
Yes (DB-level).
Yes. Changes are rare and controlled.
Yes. Snapshots ensure traceability.
Yes, by deleting snapshots.
Yes, unless explicitly re-uploaded.
Yes, deterministically.
Yes: Timesheets/Allocations → Snapshot → Dashboard.
Yes — no live recalculation risk.
Daily micromanagement.
Monthly executive reporting.
Yes (future extension).
Immutable snapshots + deterministic math + enterprise safety.