Choosing which initiatives to fund
Compare the commitments behind each proposal, including the projects already using the same people and systems.
Three proposals using the same systems team
Illustrative portfolio. These proposals and constraints explain the method; they are not client work.
Scroll the comparison to read every column.
| Proposal | Business reason | Evidence available | Decision required |
|---|---|---|---|
| Replace the order system | Maintain order processing before support ends. | Supplier notice; current process and failure records. | Authorize the replacement scope and implementation capacity. |
| Add a distribution channel | Reach a new customer group. | Demand estimate; partner terms still under review. | Fund a limited test before committing to a full launch. |
| Automate management reporting | Reduce manual preparation and reconcile definitions. | Current report inventory; data ownership unresolved. | Confirm definitions and ownership before build funding. |
What approval would commit
A funding request should make the commitment visible. Alongside the objective and proposed budget, include spending already committed, the remaining estimate, and the management or specialist time required. These belong in the comparison even when they do not appear in the project budget.
In the illustrative portfolio above, the system replacement has a supplier deadline. The distribution proposal still needs demand and partner testing. The reporting proposal depends on data ownership. Each needs a different approval; treating all three as ready-to-start investments would conceal those differences.
Compare the basis for each proposal
Agree which criteria matter to this portfolio. A contractual deadline, an operating requirement, and an expected commercial return answer different questions. A score can help organize the comparison, provided the evidence and assumptions remain beside it.
For example, a forecast supported by customer orders gives management a different basis for commitment from an early demand estimate. Show that difference in the recommendation, including any further work needed before funding is released.
The conflict changes the sequence
- Systems team
- The replacement and new channel both need integration work. Confirm which can start with the capacity available.
- Data owners
- Reporting automation depends on agreed definitions. Resolve ownership before scheduling development.
- Management attention
- The same sponsor cannot assume unlimited review capacity. Name the review points each proposal needs.
Test the proposed start dates
Lay the initiatives alongside one another to check their demands on systems access, operating downtime, and specialist staff. A project that fits on its own may conflict with work already authorized. Ask the people responsible for those resources whether the proposed sequence is workable.
If the system replacement takes priority, the channel proposal may still proceed with customer research while its integration work waits. The funding decision should state that limit so the project plan does not assume capacity that has been assigned elsewhere.
A decision includes its conditions
Illustrative decision record, conditional on the evidence above.
- Authorize
- The replacement, once scope, cost and systems capacity are confirmed.
- Limit
- The channel proposal to demand and partner testing. A launch returns for a separate decision.
- Defer
- The reporting build until data owners agree the definitions. Assign an owner to bring it back.
Give deferred work a route back
A deferral needs a reason and someone responsible for resolving it. For the reporting proposal, that might mean agreeing data definitions before returning with a build request. Retain the earlier submission and decision so management can see what changed.
Set the next portfolio review and the conditions that justify an earlier one, such as a lost resource, a revised cost estimate, or a changed dependency.