Estimate Resources: People, Equipment and Capacity
The question usually arrives in its compressed form: how many people do you need? It is asked in good faith, often by somebody assembling a business case, and answering it directly is a mistake, because a headcount is an output of a resource estimate and not an input to one. What the work is, how much of it there is, what has to exist before it can start, and by when the result is needed: those come first, and the number of people falls out of them.
Estimating resources covers everything the work consumes, which on most projects means people, equipment, facilities, environments, licences and specialist capacity in queues somebody else controls. Section 2.6.2 of the PMBOK® Guide Eighth Edition treats this as its own piece of work inside the resource discipline, and separating it from acquiring what you have estimated is the useful part: one is an analysis and the other is a negotiation.
Estimate the work, then the resources
Effort. How much work there is, in person-days or whatever unit suits, independent of who does it or when. This is the number that historical data can genuinely inform, because past projects tell you how long jobs of this kind have taken, and it is the number most likely to be corrupted by pressure, since reducing it looks like efficiency and feels like optimism.
Duration. How long the work will take in calendar time, which depends on how many people can usefully work on it at once. A thirty-day task does not become a ten-day task with three people if the work is sequential or if the three have to agree with each other constantly, and the point at which adding people stops helping is a judgement worth making explicitly.
Availability. What proportion of a working week the people concerned will actually spend on this project. Estimating effort honestly and then assuming full-time availability produces a plan that is wrong by whatever the real figure is, and in a shared organisation that factor is often between a half and a third. Writing the assumption down, by name, is what lets somebody challenge it before it becomes a date.
The resources nobody estimates
Test and staging environments. These are frequently assumed to exist, and they exist in the sense that there is one, shared with four other programmes, with a booking queue. An environment is a resource with a capacity and a lead time, and it belongs in the estimate with a quantity against it.
Equipment with a lead time. Instrumentation, plant, specialist tooling and long-lead parts can dominate a schedule. The estimate has to carry not only what is needed but when it must be ordered, because a twenty-six week lead time discovered in month five is a different project from the one that was planned.
Assurance and approval capacity. Security assurance, safety case review, regulatory submission, design authority sign-off: each is performed by a small team with a queue, and each is a resource the project consumes without owning. Public sector programmes in particular are shaped by these queues, and a plan that treats an assurance gate as a date on a page has estimated none of it.
Licences, data and access. Software licences, data-sharing agreements, security clearances, site inductions. Individually small, collectively capable of holding up a team for weeks, and almost never in the first version of a resource estimate.
A programme office sized from a business case
A government department was replacing a benefits calculation service. The business case carried a delivery figure of thirty-two people, derived from a comparable programme in another department, and the programme office was fitted out accordingly: two desk runs, monitors, the lot, ready for a team that had not yet been estimated from any actual work.
The bottom-up estimate, done properly in month three, put the development and test effort at about twenty-four people at peak. That was the easy part, and it was close enough that nobody worried. What the original figure had not contained at all was the assurance capacity. The service handled personal data at a level requiring formal security assurance, and the department's assurance team could process roughly one major submission a month across all programmes.
The programme needed four submissions across its life. Sequenced against the queue, those four gates added about five months to the plan, and no amount of developer headcount would have shortened it. The first of them arrived in month seven and took eleven weeks, during which a team sized for peak delivery had considerably less to do than it had been funded to do.
What the programme did next was sensible and a year late. The assurance queue was modelled as a resource with a capacity, the submissions were re-sequenced so that two could be combined, and an assurance specialist was seconded into the programme to prepare the packs properly, which cut the review time roughly in half. The desk runs stayed mostly empty until month fourteen, and the chairs stayed in their wrapping, which is as good a physical record of an unexamined estimate as any programme is likely to leave.
Uncertainty, and when to look again
Estimate in ranges early and narrow them deliberately. A single number produced in month one will be treated as a commitment by somebody, and the honest form at that stage is a range with the assumptions attached. What converts a range into a number is information, so it is worth saying which information: when the design is fixed, when the environment strategy is agreed, when the assurance route is confirmed.
Set the re-estimation points in advance. The moment to revisit a resource estimate is when something it depended on becomes known, and naming those moments at the start turns re-estimation into a planned activity instead of an admission. A project that re-estimates only when it is already in trouble has made the exercise a confession, which is why so few teams do it twice.
For a PMP® candidate, the useful reading is that resource estimation derives from the work and includes everything the work consumes, so a situation where a team is fully staffed and still not progressing is worth examining for the resource that was never estimated. A response that adds people to a queue-limited problem makes the position worse. A structured PMP exam preparation course works estimation through situations where the headcount is right and the capacity sits somewhere else entirely.
One question tests this, and it can be answered this week. List everything your next three months of work consumes that your project does not control, and put a lead time or a queue length against each. Anything you cannot fill in is a resource you have assumed rather than estimated, and those are the ones that arrive as surprises with somebody else's name on them.
Interested in going further?
A resource estimate is only as good as the list of things it remembered to include, and the expensive omissions are rarely people. Omega's PMP® Exam Preparation works through estimation where the constraint sits in a queue the project does not own.
Estimating what a project's work will consume is part of the resource material in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A142: The PMBOK 8 Resources Performance Domain: What It Really Covers
A143: People Are Resources, But Not Just Resources
A144: Resource Planning in a World of Shared Teams
A145: Resource Levelling vs Resource Smoothing
A146: Team Agreements: Small Document, Large Effect
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
