145% or 62%: Which Number Goes to Leadership
Vertex's nine-person design team supports four concurrent client projects, each with its own project manager. Every PM schedules independently and assigns named designers to every task at 100% allocation because 'that's who we'd like on it.' The Resource Manager opens the Workload Balancer filtered to the Design team and sees one senior designer at 145% next month. That designer says she is fine, and two of the PMs point out she appears on only three tasks. Separately, a portfolio dashboard shows the design team at 62% utilization for the quarter. The Resource Manager must decide by Friday whether to approve a six-week contractor or re-sequence work, and needs a number she can defend in a leadership review.
1. Explain how 145% and 62% can both be 'true' and describe how you would establish one defensible figure.
Read the worked answer
They are answers to different questions, computed over different windows.
- 145% is a next-month peak at user level. The Workload Balancer is summing planned hours from task assignments over that date range against the user's schedule and comparing to available hours. A single overlapping fortnight produces a peak figure.
- 62% is a quarter-long average at team level. Averaging nine people over thirteen weeks flattens every peak; a team can be simultaneously 145% in one role in one month and 62% across the quarter.
Neither is wrong, and quoting either to leadership alone is misleading.
The defensible approach:
- Pick the decision's window. A contractor decision is about the next six weeks, so use the six-week window, not the quarter.
- Pick the level that matches the constraint. Designers are not interchangeable if one is the only brand specialist; report by job role and by named user, side by side.
- Reconcile before escalating. Open the Workload Balancer, list the specific tasks generating the peak, and confirm with the designer and PMs which are real versus 100%-because-default. A senior designer 'appearing on three tasks' can still be 145% if two of them run in the same week.
- State planned versus available explicitly. Utilization claims should always carry the window, the level, and the source (planned hours from assignments).
The 100% default is the root defect: when every assignment is 100%, the system cannot distinguish a two-hour review from a two-week build, and the peak number is partly an artifact of that habit.
2. What would you change in how the PMs assign work so this ambiguity stops recurring, and what is the risk of changing it?
Read the worked answer
Change the assignment default from 'who we'd like' to 'what the work needs.'
- Assign by job role for planning, name only when the person is genuinely committed. Role-level assignments let the Resource Planner and the Workload Balancer resolve capacity across the team instead of pretending three named people are the only candidates.
- Set planned hours per task from an effort estimate, not from a percentage. Percentage allocation is a statement about a person's calendar; planned hours are a statement about the work. Only the latter aggregates usefully.
- Restrict hard allocations to work that truly blocks - kickoff, final review - and let the rest float.
- Use a resource pool so the Resource Manager can plan the team's work without asking each PM for a project list.
The risk, and why it must be managed: PMs will lose the illusion of control, and some will respond by continuing to name people in task descriptions while leaving assignments as roles - recreating the problem in text. Adoption has to be checked, not assumed. Second risk: converting assignments mid-flight can make already-committed work look unstaffed and alarm stakeholders, so run the change at a project boundary or announce it with the reporting shift. Third: role assignment is only useful if job roles and schedules are current, so audit role assignments and user schedules before turning it on.