Aligning Development Resources and Capacity

4.1 Measuring True Development Capacity by Function and Critical Skill Set

Development capacity is the amount of productive work an organization can realistically perform during a defined period with its available people, facilities, equipment, external partners, and other constrained resources. It should not be confused with headcount. A department containing 100 engineers does not have 100 full-time equivalents of project capacity. Some time is required for management, training, technical support, maintenance, recruiting, compliance, customer issues, sustaining work, and other responsibilities. Absences, vacancies, turnover, and onboarding also reduce effective availability.

The first step is to establish gross capacity by function. Identify the people available within product management, research, engineering, quality, regulatory, operations, and other relevant development functions. Translate headcount into productive time for the planning period using realistic assumptions about working days and non-project activities. Avoid imposing one utilization assumption across every function. A laboratory scientist, software engineer, engineering manager, product manager, and quality specialist may have materially different proportions of time available for direct project work.

A useful distinction is between gross capacity, available project capacity, and deployable capacity. Gross capacity represents the theoretical working time of the current workforce. Available project capacity removes predictable non-project demands. Deployable capacity reflects the portion that can actually be assigned to the relevant development portfolio after considering skills, geography, facilities, contractual restrictions, and other constraints. Management decisions should be based primarily on deployable capacity.

Capacity should then be decomposed by critical skill set. This is often where the most important insights emerge. A broad research and development organization may appear comfortably staffed in aggregate while individual programs wait for a handful of specialists. Identify skills that regularly appear on project critical paths, require long training periods, depend heavily on experience, or cannot easily be substituted. Examples include systems architects, safety engineers, verification specialists, regulatory experts, data scientists, clinical specialists, formulation scientists, tooling engineers, and particular software disciplines.

For each critical skill, estimate practical capacity rather than contractual working hours. Relevant deductions may include:

• Leadership and administration: Time required for people management, technical governance, budgeting, recruiting, reporting, and organizational responsibilities.
• Sustaining work: Engineering changes, customer problems, production support, quality investigations, cybersecurity fixes, regulatory updates, and other work required to maintain existing products.
• Capability maintenance: Training, technical communities, laboratory upkeep, method development, documentation, and other activities necessary to preserve the function’s effectiveness.
• Unplanned demand: A realistic allowance for urgent issues that historically consume capacity, particularly in functions that support products already in the market.
• Availability losses: Vacancies, planned leave, turnover, onboarding time, contractor transitions, and other factors that reduce usable capacity during the planning period.

Historical utilization data can help establish these assumptions, but recorded time should be interpreted cautiously. Timesheets may be incomplete, project codes may be inconsistent, and employees may charge work according to financial conventions rather than the activity actually performed. Triangulate time data with manager estimates, project staffing records, workload observations, and historical throughput. The objective is a decision-quality estimate of available capacity, not accounting precision.

Facilities and external resources should be measured in comparable terms where they constrain progress. Test chambers, laboratories, prototype lines, simulation environments, specialized machines, supplier engineering support, clinical sites, or certification facilities may determine throughput more strongly than employee capacity. Measure available slots, operating hours, lead times, and practical utilization. A capacity assessment is complete only when it captures the resources that can materially prevent priority work from progressing.

4.2 Connecting Project Demand to Available Capacity

Once available capacity is understood, project demand must be expressed in the same units, time periods, functions, and skill categories. Annual budgets alone are inadequate because development demand is uneven. A project may require limited engineering effort during concept development, intense specialist involvement during detailed design, substantial test resources during verification, and concentrated operations support before launch. Capacity plans must therefore show when resources are needed, not simply how much a project requires in total.

Begin with the approved or proposed project portfolio and estimate resource requirements by meaningful phase or milestone. For each project, identify the functions and critical skills required, expected effort, start and completion periods, and significant dependencies. Use historical projects of similar type as reference points where detailed estimates do not yet exist. Early-stage opportunities should be estimated using ranges or standard resource envelopes rather than false precision because their scope and technical pathway remain uncertain.

Demand estimates should distinguish committed work from potential work. Committed demand comes from programs leadership has authorized and expects the organization to deliver. Conditional demand represents projects that may proceed if specified evidence is obtained. Proposed demand consists of opportunities competing for future capacity. Keeping these categories separate allows executives to understand the consequences of approving additional work. If committed projects already consume the practical capacity of a critical discipline, starting another program requires a trade-off rather than an assumption that the function will absorb it.

The capacity model should connect projects to resources through time. A simple monthly or quarterly matrix is often sufficient. Rows can represent functions or scarce skills, columns can represent periods, and project-level requirements can roll up into total demand. Compare this demand directly with deployable capacity. Highlight periods where requirements exceed supply and periods where significant capacity is unused. The resulting view makes resource feasibility visible before schedule commitments are finalized.

Five practices materially improve the quality of demand estimates:

1. Use project archetypes. Create reference staffing patterns for recurring types of development work, such as new platforms, major product introductions, line extensions, software releases, regulatory changes, or customer-specific variants.
2. Estimate by stage. Reflect how resource intensity changes across discovery, design, development, verification, industrialization, and launch rather than spreading total effort evenly across the schedule.
3. Expose critical skills. Break broad functional demand into specialized capabilities when aggregate totals would conceal bottlenecks.
4. Include non-portfolio work. Incorporate sustaining engineering, customer requests, compliance work, technical debt, production support, and other recurring demands that compete for the same resources.
5. Model uncertainty. Use ranges or scenarios for programs whose timing, technical pathway, or probability of continuation remains uncertain.

Demand and capacity should be reconciled before project schedules become commitments. If a program plan assumes six specialist engineers during a quarter when only three are practically available, the organization has several choices: change the schedule, change project scope, shift resources, obtain external capacity, develop substitute skills, or deprioritize another project. What management should not do is accept both the project schedule and the conflicting capacity plan and leave the discrepancy for teams to resolve informally.

Joint ventures should distinguish capacity controlled directly by the venture from capacity promised by parent companies or external partners. A parent may agree in principle to supply engineering resources but retain the right to redirect individuals toward its own priorities. The capacity model should therefore specify the quantity, timing, capability, and firmness of resource commitments. Where access is uncertain, model it as conditional rather than treating it as guaranteed supply.

4.3 Identifying Overcommitment, Bottleneck Resources, and Hidden Work

Overcommitment occurs when the organization has authorized more work than its practical capacity can execute within the expected schedules. It is one of the most common causes of slow product development because its effects can initially be difficult to see. Teams start new projects, executives believe the portfolio is moving, and functions attempt to satisfy competing requests by spreading people thinly. The consequence is not simply that everyone becomes busier. Work progresses more slowly because employees switch among projects, queues grow at constrained resources, decisions wait for overloaded experts, and milestone dates become increasingly unreliable.

Aggregate utilization can conceal this condition. An engineering organization may report 85 percent utilization while a critical specialist group faces demand equivalent to 150 percent of capacity. Because the specialist group limits the rate at which multiple projects can advance, system performance will be constrained regardless of unused capacity elsewhere. Bottleneck analysis should therefore focus on resources whose availability determines project flow, not solely on the largest functions or highest-cost resources.

Useful indicators of overcommitment include growing work in process, declining staffing per active project, increasing milestone slippage, frequent reprioritization, longer queues for specialist reviews or testing, repeated requests for overtime, and a widening gap between planned and actual resource assignments. Managers may also describe large numbers of people as “shared” across projects without being able to state how their time is divided. These patterns often justify focused engineering productivity improvement work because the apparent productivity problem may originate in portfolio loading, resource fragmentation, or workflow design rather than individual effort.

Hidden work deserves particular scrutiny. Development organizations routinely perform activities that consume significant capacity but are poorly represented in portfolio systems. Examples include customer escalations, production troubleshooting, engineering change requests, field failures, internal technical initiatives, small product modifications, technical debt, supplier problems, compliance activities, cybersecurity remediation, executive requests, and experiments conducted before formal project approval. Individually these demands may appear modest; collectively they can explain a large portion of the difference between theoretical and actual project capacity.

A practical hidden-work assessment can classify demand into four categories:

• Approved portfolio work: Formally governed development programs with explicit objectives, schedules, and resource commitments.
• Sustaining work: Recurring activities necessary to support existing products, customers, operations, quality, and regulatory obligations.
• Unplanned work: Failures, urgent requests, escalations, and unforeseen events that require immediate or near-term technical attention.
• Unofficial development work: Projects, experiments, prototypes, or enhancements consuming meaningful capacity without explicit portfolio approval.

Measure these categories through a combination of time data, interviews, resource-manager estimates, ticketing systems, engineering-change records, and sample observations. The objective is not to eliminate legitimate hidden work by declaring it unauthorized. Much sustaining and unplanned work is essential. The purpose is to make its resource implications visible so portfolio capacity is not repeatedly planned as though such work does not exist.

Bottlenecks should also be examined dynamically. A resource can be unconstrained today and become critical when several projects reach the same stage simultaneously. Plot demand by period and identify synchronization risks. Three major programs entering verification in the same quarter can overwhelm a test organization even if annual demand appears manageable. Similar peaks can occur around regulatory submissions, tooling release, manufacturing trials, cybersecurity testing, commercial launch preparation, or architecture reviews.

The diagnostic should end with a short list of constraints that materially affect portfolio throughput. Distinguish chronic structural bottlenecks from temporary peaks. Structural shortages may require hiring, capability development, automation, outsourcing, or process redesign. Temporary conflicts may be solved through sequencing or short-term external capacity. This distinction prevents organizations from permanently expanding resources to address a short-lived peak or repeatedly relying on temporary workarounds for a persistent structural gap.

4.4 Reallocating Resources Across Priority Programs and Resolving Capacity Gaps

Once priorities, demand, and constraints are visible, management must reconcile the portfolio with actual capacity. This is where resource planning becomes a leadership decision rather than an analytical exercise. If demand exceeds supply, every credible solution has a consequence: some work moves later, receives less scope, loses resources, or stops; additional capacity is obtained; or productivity improves sufficiently to close the gap. Leaders should make these consequences explicit rather than leaving functions to absorb conflicting commitments.

Resource reallocation should begin with the portfolio priorities established in Chapter 3. Compare actual staffing with stated priority. High-priority projects should normally receive the capacity required to execute their approved plans before discretionary lower-priority work is staffed. Where this is not true, investigate why. Common causes include historical ownership, functional leaders protecting established teams, specialist skills being tied to legacy products, geographical constraints, customer escalations, or executives making informal requests outside the portfolio process.

Reallocation is not simply moving names between spreadsheets. Technical expertise can be deeply specific to a product architecture, code base, scientific domain, manufacturing process, regulatory context, or customer application. Transitioning an employee may require knowledge transfer, training, access, or time to become productive. Resource plans should distinguish immediately fungible capacity from capacity that can be redeployed only after a transition period. Otherwise executives may approve resource transfers that exist administratively but do not improve near-term execution.

When a material capacity gap remains, management has several levers:

1. Reduce demand. Stop, pause, defer, or narrow lower-priority projects so scarce capacity can move to work with greater strategic or economic value.
2. Change sequencing. Adjust project schedules so peaks in demand for constrained skills or facilities occur at different times.
3. Redeploy internal resources. Shift appropriately skilled people from lower-priority work, adjacent functions, locations, or business units while accounting for transition requirements.
4. Add external capacity. Use contractors, engineering partners, specialist laboratories, suppliers, or consultants where work can be transferred without unacceptable integration, quality, confidentiality, or knowledge-retention risk.
5. Build structural capacity. Hire, train, automate, redesign roles, simplify processes, or invest in facilities when the shortage is expected to persist and the capability is strategically important.

External resources are most effective when the work can be bounded clearly and the required interfaces can be managed. They may be particularly useful for temporary demand peaks, specialized analyses, testing, software development, technical documentation, program management, or capability gaps that would take too long to fill internally. They are less attractive where critical architectural knowledge, proprietary learning, or continuous cross-functional interaction makes outsourcing cumbersome. Cost comparisons should include onboarding, coordination, rework, and knowledge-transfer requirements rather than hourly rates alone.

Structural gaps require a broader operating-model perspective. If the same resource conflict recurs every planning cycle, repeated expediting will not solve it. Management may need to change role definitions, organizational ownership, make-versus-buy choices, capability locations, decision rights, or workforce composition. In such circumstances, R&D operating model design can address how capabilities should be organized and accessed rather than merely redistributing current staff among projects.

Resource decisions should also preserve organizational resilience. Planning every critical skill at 100 percent theoretical utilization leaves no capacity for learning, failure resolution, urgent customer issues, or technical uncertainty. In development environments, some buffer is economically valuable. The appropriate level depends on variability and the cost of delay. Resources supporting unpredictable workloads generally require greater flexibility than teams executing stable, repeatable work.

Joint ventures require special attention to parent-provided resources. Reallocation may require approvals outside the venture, and parents may assign different priorities to shared people or facilities. Resource agreements should specify required capabilities, expected availability, service levels, decision rights when demand conflicts arise, and mechanisms for obtaining incremental capacity. When these provisions are unclear, apparent development-capacity problems can become governance disputes precisely when projects face critical milestones.

4.5 Development Capacity Model and Resource Allocation Template

A development capacity model should give leaders a forward-looking view of whether the approved portfolio can be executed with the resources expected to be available. It need not be a sophisticated optimization system. A transparent spreadsheet or planning application that connects projects, stages, resource requirements, and available capacity can be more useful than a complex model whose assumptions are understood by only a few analysts. The model should support decisions, scenario testing, and regular portfolio reviews.

The model should contain four linked components. The first is a capacity table showing deployable resources by function, critical skill, location where relevant, and period. The second is a project demand table showing required capacity by project, stage, skill, and period. The third is a gap analysis that calculates demand minus available capacity and highlights material shortages or unused capacity. The fourth is a scenario layer that allows leaders to test changes in project timing, priorities, staffing, external support, or hiring assumptions.

Capacity assumptions should be explicit. For each function or skill group, record current headcount, vacancies, expected hires or departures, working-time assumptions, non-project requirements, sustaining-work allowances, and resulting deployable capacity. Where external resources are included, distinguish contracted capacity from capacity that is merely expected to be available. Record major facilities separately when their utilization limits project throughput.

The resource-allocation template should connect each priority project to a realistic staffing commitment. Useful fields include:

• Project and priority: Project name, portfolio category, priority level, accountable leader, and approved development stage.
• Required resources: Planned effort by function and critical skill for each monthly or quarterly period.
• Committed resources: Named or quantified capacity actually assigned, including internal and external sources.
• Resource gap: The difference between requirements and commitments, with the timing and project milestone affected.
• Resolution action: The agreed response, such as reassignment, external support, schedule change, scope reduction, hiring, or project reprioritization.
• Decision ownership: The leader accountable for resolving the gap and the date by which the decision must be made.

The model should support several scenarios rather than a single deterministic forecast. A base case can represent the approved portfolio and expected staffing. An upside case can show the capacity required if conditional projects succeed or additional opportunities are approved. A constrained case can test vacancies, delayed hiring, supplier limitations, or other shortages. Scenario analysis is particularly useful for long-lead capabilities because it shows leaders where decisions must be made before the resource need becomes urgent.

Capacity reviews should occur at the same cadence as meaningful portfolio decisions. Updating the model monthly may be appropriate for fast-moving software or engineering environments, while quarterly updates may be sufficient for longer-cycle development organizations. The model should also be refreshed when a major project is accelerated, stopped, significantly delayed, or materially rescoped because each of these decisions changes the availability of resources elsewhere in the portfolio.

Management should track forecast accuracy over time. Compare planned resource demand with actual use, investigate systematic differences, and improve project archetypes and assumptions. If teams consistently underestimate verification effort or sustaining engineering consumes more capacity than planned every quarter, update the model rather than treating each variance as exceptional. A capacity model becomes increasingly valuable as the organization learns which assumptions are dependable and where uncertainty must remain explicit.

The executive output should remain concise: major resource gaps, affected priority programs, bottleneck skills, proposed resolution, and required decisions. Detailed staffing plans belong with functional and project leaders. At the portfolio level, the essential test is whether the combination of development commitments can actually be delivered with the capacity available. When priorities, schedules, and resources are reconciled in one fact base, executives can make launch commitments with greater confidence and development teams can focus on completing priority work rather than continuously renegotiating which project receives their attention.