Allocate requirements across increments and capacity

From priority to use in a specific period

A ranked list can show that a requirement matters without showing the increment in which it can be used. To prepare a baseline, place accepted or deferred requirements on a timeline and relate availability to the intended value. In a fictional financial institution, instruction search might be built on Friday but become usable by the next group only after the agreed preparation. Build completion and available use are distinct events. This separation need not be imposed on every project; the comparison must state which convention its model uses.

In this lesson’s exercises, completion at the end of I1 with use from the next increment means first use in I2. A horizon ending in I3 allows I2 and I3 to count, without adding I4. Unless stated otherwise, requirements are indivisible and work assigned to an increment must fit entirely within it. Also record whether value is earned once or in every usable period. These definitions prevent apparently equivalent proposals from counting different periods, populations or outcomes. Selection remains conditional on the objectives and the mandate of whoever approves the baseline.

Dependencies do not all mean the same thing

An arrow between requirements can represent different rules. “P must be complete before X starts” excludes building P and X in the same increment when each work item occupies its assigned period. “X may be made available only with Y” can permit building and releasing both together. A shared component may be built once and reused by several capabilities, but that does not establish that all can become usable together. State each relationship’s meaning and check for integration or preparation requirements omitted from the model.

Use the user need to define complete sets. If a group needs to identify an instruction and inspect its state, search alone may not deliver the promised capability. Another group may have a different need and be served earlier. The analyst should represent these differences without automatically assigning whole-population value to the first available group. Gradual adoption may also require a temporary capability: retaining two interface contracts while consumers move. Evidence of an existing consumer is analysis input, not a reason to impose the same interface on every future project.

Capacity and funding when they are needed

For each increment, compare required effort with the capacity of the skill able to perform it. If a plan needs two QA days in I1 and only one exists, three spare days in I2 do not make I1 feasible. They may enable a different allocation, provided dependencies and commitments still hold. Likewise, total technician availability does not replace a particular skill when the exercise contract requires a specialist. Allocation needs a commitment of availability, not merely a name in a responsibility matrix.

Separate money from effort. A phase can have sufficient funding without the required people, or technical capacity before funding becomes available. State expressly whether unspent funding carries into the next phase; do not automatically transfer team-days between roles or periods. To explain an infeasible proposal, identify the failing cell and condition. “Resources are missing” is less useful than “I2 needs four validation days, but only two exist and precedence prevents doing the work earlier.” A small counterfactual analysis can show that adding capacity in the wrong period does not remove the constraint.

Compare value within an explicit horizon

Two plans can finish with the same capabilities and produce different forecast value within the horizon. Consider two indivisible work items, A and B, each occupying one increment. Capacity permits one item per increment, use starts in the following increment, and the horizon ends in I3. A yields four value units per usable period and B yields six. Building A in I1 and B in I2 gives 4+4+6=14. Reversing the order gives 6+6+4=16. The calculation adds neither value after I3 nor use during construction.

Value can depend on a window: a capability for a campaign occurring only in I2 does not retain that benefit in I3. It can also depend on a complete set for each group. Confirm when values are additive; do not add two estimates representing the same saving. If comparing costs and benefits in a net score, the exercise must define a common unit and the calculation rule. An effort point does not inherently equal a benefit point. The best calculated result describes a forecast within the model. It does not establish adoption, realized benefit or probability of passing an examination.

Include support and temporary capabilities

Bringing a capability forward can create value earlier and begin consuming support earlier. If the same team contributes to later delivery, recurring load reduces available capacity. Distinguish one-time construction, shared support per period and support specific to each active capability. A shared component should not be built twice in the calculation, but being shared does not remove its maintenance in the periods when it is used. State when each charge starts and ends, including what happens while no capability uses it.

A temporary option may require removal, conversion or support during coexistence. These activities enter only when the case defines them; they must not be invented to favor an answer. When comparing temporary and permanent options, make each one’s functional coverage and useful life explicit. An option with cheaper initial construction can occupy a window needed by another important capability. A preference based on an isolated option can therefore change when the temporal portfolio is considered. The result should explain which requirement is accepted or deferred and the consequence for the objective, without turning a technical preference into a universal rule.

Commitments, reserve and uncertainty without invented compensation

A mandatory commitment should operate as an admissibility condition. If capability C must be usable in I2, a proposal making it available in I3 does not comply merely because it promises more value from another capability. First eliminate or revise proposals failing the conditions; then compare value among admissible ones. A tie does not authorize invented superiority: record the shared criteria and use the decision mandate or an additional agreed criterion when needed.

A reserve also needs a concrete purpose. A conditional need may have a specified period and skill that the plan must be able to absorb. In that case, consuming the reserve with optional work violates the exercise condition even if the favorable scenario has higher value. This establishes no universal reserve percentage. When two capacity scenarios have no probabilities, their average is not automatically a valid forecast. If the rule requires feasibility in both, check both. If it allows deciding after the scenario is observed, a different conditional plan must be designed. Expose the decision rule and consequences rather than calling an option cautious or risky without stating the relevant condition.

Document the proposal before obtaining approval

A baseline proposal should expose each increment’s scope, deferred requirements, dependencies, use conditions and assumptions supporting value. Show at least one plausible alternative and explain why it was not selected. The reason may be missing capacity in a period, lower value within the horizon or violation of a mandatory condition. The table should let another person reconstruct the reasoning without relying on an isolated score.

If no approved baseline exists and a prerequisite is found to be unavailable, correct the proposal using current information. Do not treat the first working version as an authorized commitment. Conversely, managing a change to an approved baseline involves the applicable change-control process and should not be disguised as initial allocation. Agreeing the distribution of requirements does not mean accepting the delivered solution either. Analysis prepares a coherent proposal; approval has its own scope and authority, and solution evaluation needs later evidence. These boundaries help identify the next action and preserve PMI-PBA task framing without attributing more power to the model than it has.

Produce reasoning that can be reviewed

To review a comparison, begin with the contract: periods, capacity, dependencies, value unit, served population and mandatory conditions. Then calculate each proposal’s one-time work in every period-and-skill cell. Add recurring support and reserves where defined. Calculate value from genuinely usable periods only after checking feasibility. Keep the exclusion reason separate from the financial or scoring result; an infeasible proposal can have a high nominal sum.

This lesson’s cases use small sets of proposals so that review is possible. “Best among these proposals” does not prove that no other better plan exists. Claiming an optimum in a finite model requires covering every permitted choice or providing another sufficient demonstration. In professional application, values and capacities are often estimates: identify who confirms them, what remains uncertain and the conditions for revisiting the plan. The exercise produces an explainable decision under stated assumptions. Implementation, actual staff availability, operational acceptance and observed benefits each require their own work and evidence.

Common pitfalls

Sum capacity across different periods; count value before use; confuse an accepted requirement with an already delivered capability; treat every dependency as earlier-period precedence; omit defined support and coexistence; assign whole-population value to one group; claim optimality after comparing only a few proposals.