Oracle Project Management Cloud 2026 Implementation Professional study materials
Oracle Project Management Cloud 2026 Implementation Professional study resources

Utilization Report That Disagrees With the Timesheet

Oracle Project Management Cloud 2026 Implementation Professional · Put your knowledge to work in context.

All case studies

Utilization Report That Disagrees With the Timesheet

Brightline Advisory has 300 consultants organized into 12 resource pools. Two pools use a resource format of Job and the other ten use Person. For Q1 the resource utilization dashboard reports 68 percent firm-wide, while the finance team's own analysis of posted timecards against standard capacity shows 82 percent. Separately, project managers have been booking people directly: the implementation left resource request auto-approval switched on, so 240 of the 310 Q1 requests were never reviewed by a resource manager, and two consultants were double-booked at 130 percent in March. The Project Performance dashboard has also shown identical figures for three weeks with a small "data may be stale" indicator, and the PMO cannot find September's cost adjustments anywhere in it.

1. Reconcile the 68 percent and 82 percent utilization figures. What would you examine and how should the resource formats be set up?

Read the worked answer

Treat this as a numerator/denominator reconciliation before assuming either number is wrong.

Denominator - capacity. Capacity comes from standard working hours on the resource calendar and the person's FTE, not from hours actually worked. If the two Job-formatted pools have no individual FTE or calendar, their capacity is either defaulted, averaged or missing, and the firm-wide percentage is distorted. Check standard working hours per calendar, whether part-time calendars exist, and whether the FTE is carried consistently.

Numerator - what counts as utilized. The dashboard typically works from assignments (scheduled hours), while finance measured posted timecard hours. The 14-point gap is very often the set of people who worked on client work without a project assignment, or whose assignment was cancelled and never re-created - they show as idle to the dashboard but productive in the timecard data. Also check whether soft bookings count, whether only primary assignments are counted, and whether internal, training or business-development time is excluded from the numerator but still consuming capacity.

Resource formats. Use Person format for any pool whose members have an individual utilization target, individual rate or individual skills - the person is the resource and capacity is person-specific. Use Job format for generic, interchangeable demand that is filled later by a resource manager; job-level capacity is an aggregate and will never reconcile to individual timesheets. Given Brightline measures individual utilization, the two Job pools should be re-examined: either convert them to Person, or consciously exclude them from person-level utilization reporting.

Action: pick one definition of utilization, document it (scheduled hours or actual hours, which assignment types count), drive the dashboard from that definition, and stop reporting two figures. Then fix the assignment discipline so hours worked always exist on an assignment.

2. What are the consequences of leaving resource request auto-approval on, and how would you redesign the request and approval configuration?

Read the worked answer

Consequences observed: 240 of 310 requests were booked without the resource manager ever seeing the demand, and two consultants were booked at 130 percent in March. Auto-approval converts a request straight into a booking, so the pool owner loses the two things a resource manager exists for: arbitrating conflicting demand across projects and protecting individual capacity. Double bookings, last-minute substitutions and unforecastable utilization all follow.

Redesign:

  1. Turn auto-approval off for pools where the resource manager owns capacity; if some volume must stay frictionless, restrict auto-approval to internal or low-value requests, not client commitments.
  2. Route requests to the resource manager of the requested pool, not to the project manager, and make the resource manager the approver of the resulting booking.
  3. Enforce capacity rules: block or escalate a booking that takes a person above the configured overbooking tolerance, and make the tolerance explicit rather than incidental.
  4. Distinguish soft and hard bookings deliberately. A request should produce a soft booking; only the resource manager's approval should create a hard booking that the person and the project can plan against.
  5. Define what happens to the 240 auto-approved bookings: review the ones still in the future, confirm or reject them, and resolve the 130 percent overbookings before the affected month.
  6. Keep the approval workflow's turnaround visible; teams route around approvals that are slow, which is often the real reason auto-approval was left on in the first place.

3. Why is the Project Performance dashboard frozen and missing September's adjustments, and what would you configure so the PMO can rely on it?

Read the worked answer

Why it is frozen. Project performance reporting reads from a summarized snapshot of project cost, budget, commitment and forecast data, populated by a scheduled process rather than queried live from transactions. If that summarization process has not run - because it was never scheduled, it failed, or someone stopped it - the dashboard keeps displaying the last successful snapshot, which is exactly what the stale indicator is telling you. Three weeks of identical figures is the signature of a job that is not running.

Why September's adjustments are missing. Cost adjustments appear only after two things have happened: the adjustment has been distributed so it exists as processed project cost, and the summarization that follows it has run. An adjustment distributed after the last summarization run is invisible to the dashboard. It is also possible the adjustment was never distributed and is sitting unprocessed, so check the unprocessed expenditure items before blaming the snapshot.

Configuration to make it dependable:

  1. Schedule the summarization process with a frequency that matches decision-making (typically nightly during the close, less often otherwise) and align it with the cost distribution schedule so it always runs after distribution, never before.
  2. Decide between incremental and full refresh: incremental for routine runs, full refresh after structural changes such as new tasks, reorganizations or hierarchy changes, which incremental refreshes handle badly.
  3. Monitor the job - alert on failure and on a last-run timestamp older than the expected interval, rather than relying on a user noticing.
  4. Publish the snapshot timestamp on the dashboard itself, and put the summarization run into the month-end close checklist after cost distribution and before reporting.
  5. Separately, confirm which summary or subject area the PMO should be using for adjustments; some real-time cost reporting reads unsummarized data and will show what the summarized dashboard cannot.