On this page

IT Planning and Prioritisation

IT planning and prioritisation determines which technology initiatives receive resources and when. The discipline connects organisational strategy to technology execution through structured evaluation of competing demands, explicit trade-off decisions, and ongoing portfolio governance. For mission-driven organisations operating with constrained budgets and external funding cycles, effective planning prevents both underinvestment in foundational capabilities and overcommitment to initiatives that cannot be sustained.

Planning cycle: A recurring period during which technology needs are identified, evaluated, and scheduled for implementation. Cycles align with organisational budgeting and strategic planning rhythms.
Prioritisation framework: A systematic method for comparing initiatives against defined criteria to determine relative importance and sequencing.
Portfolio: The collection of all technology initiatives, systems, and investments managed as a whole rather than individually.
Business case: A documented justification for an initiative that articulates the problem, proposed solution, costs, benefits, risks, and alternatives.
Investment threshold: A cost or effort boundary that triggers specific approval requirements or evaluation depth.

Planning cycles

Planning cycles create predictable moments when technology needs surface, receive evaluation, and enter the portfolio. The cycle structure depends on organisational size, funding patterns, and governance maturity. Three cycle types operate at different frequencies: annual planning sets direction and major commitments, quarterly planning adjusts priorities based on emerging needs and delivery progress, and continuous planning handles tactical decisions within established parameters.

Annual planning aligns technology investment with organisational strategy and budget cycles. The process begins 3-4 months before the fiscal year when leadership identifies strategic priorities that technology must support. IT leadership translates these priorities into candidate initiatives, estimates resource requirements, and presents options to governance bodies. The output is an approved portfolio with allocated budget and sequenced delivery expectations.

+--------------------------------------------------------------------+
|                    ANNUAL PLANNING CYCLE                           |
|                    (12-month fiscal year)                          |
+--------------------------------------------------------------------+
|                                                                    |
|  Month 8-9              Month 10-11           Month 12             |
|  +-----------------+    +-----------------+   +-----------------+  |
|  | STRATEGY        |    | PORTFOLIO       |   | APPROVAL        |  |
|  | ALIGNMENT       |--->| DEVELOPMENT     |-->| AND BUDGET      |  |
|  |                 |    |                 |   |                 |  |
|  | - Org strategy  |    | - Initiative    |   | - Board/exec    |  |
|  |   translation   |    |   definition    |   |   approval      |  |
|  | - IT assessment |    | - Business cases|   | - Budget        |  |
|  | - Gap analysis  |    | - Dependencies  |   |   allocation    |  |
|  | - Demand gather |    | - Sequencing    |   | - Comms         |  |
|  +-----------------+    +-----------------+   +-----------------+  |
|                                                                    |
|  Month 1                Month 3-6             Month 6-9            |
|  +-----------------+    +-----------------+   +-----------------+  |
|  | LAUNCH          |    | EXECUTION       |   | MID-YEAR        |  |
|  |                 |--->| AND MONITORING  |-->| REVIEW          |  |
|  |                 |    |                 |   |                 |  |
|  | - Portfolio     |    | - Delivery      |   | - Progress      |  |
|  |   activation    |    |   tracking      |   |   assessment    |  |
|  | - Resource      |    | - Risk mgmt     |   | - Rebalancing   |  |
|  |   mobilisation  |    | - Reporting     |   | - Emerging      |  |
|  | - Kickoffs      |    | - Governance    |   |   needs         |  |
|  +-----------------+    +-----------------+   +-----------------+  |
|                                                                    |
+--------------------------------------------------------------------+

Quarterly planning operates within annual boundaries to accommodate change. New requirements emerge from programme needs, security vulnerabilities, vendor changes, and strategic shifts. Quarterly reviews assess portfolio health, reallocate resources from underperforming or blocked initiatives, and evaluate whether new demands warrant inclusion. Decisions at this level require justification against the annual plan: additions either displace existing commitments or draw from contingency reserves.

Continuous planning handles decisions that fall within pre-approved parameters. These include small enhancements under £5,000, operational maintenance, and pre-authorised categories such as security patches. The governance overhead for continuous decisions remains minimal because parameters constrain scope and prior approval covers the category.

The relationship between cycle types follows a hierarchy of constraint. Annual planning establishes the envelope of resources and strategic direction. Quarterly planning adjusts within that envelope based on delivery reality and emerging needs. Continuous planning operates within quarterly allocations for decisions too small or routine to warrant formal review.

Organisations with single-person IT functions collapse these cycles. Annual planning still occurs, but quarterly and continuous merge into ongoing prioritisation conversations with leadership. The discipline remains: explicit decisions about what to do, what to defer, and what to decline.

Prioritisation frameworks

Prioritisation frameworks convert subjective judgement into structured comparison. Without a framework, decisions default to loudest voice, most recent request, or whoever has budget authority. Frameworks make criteria explicit, enable consistent evaluation across diverse initiatives, and create documentation that explains decisions to stakeholders whose requests were deferred.

The simplest framework applies a two-dimensional matrix comparing value against feasibility. Value encompasses strategic alignment, operational improvement, risk reduction, and stakeholder benefit. Feasibility encompasses cost, complexity, dependencies, and organisational capacity to absorb change. Initiatives plot onto the matrix, creating natural groupings that inform sequencing.

+-------------------------------------------------------------------+
|                    VALUE-FEASIBILITY MATRIX                       |
+-------------------------------------------------------------------+
|                                                                   |
|  HIGH    |  SCHEDULE EARLY       |  PRIORITISE HIGHLY             |
|  VALUE   |  (Complex but         |  (High value,                  |
|          |   valuable)           |   achievable)                  |
|          |                       |                                |
|          |  - Cloud migration    |  - SSO implementation          |
|          |  - ERP replacement    |  - Backup automation           |
|          |  - Major integration  |  - Security training           |
|          |                       |                                |
|          +-----------------------+--------------------------------+
|          |  RECONSIDER           |  FILL CAPACITY                 |
|  LOW     |  (Hard and not        |  (Easy wins when               |
|  VALUE   |   valuable)           |   resources allow)             |
|          |                       |                                |
|          |  - Legacy aesthetic   |  - Minor UI updates            |
|          |    refresh            |  - Report formatting           |
|          |  - Vanity features    |  - Small automations           |
|          |                       |                                |
+----------+-----------------------+--------------------------------+
           |     LOW FEASIBILITY   |    HIGH FEASIBILITY            |
+-------------------------------------------------------------------+

Weighted scoring adds precision when the matrix produces too many initiatives in the same quadrant. Each criterion receives a weight reflecting organisational priorities, and initiatives score against each criterion. The weighted sum produces a ranking. This approach suits organisations evaluating more than 10 initiatives or requiring defensible documentation for governance bodies.

A weighted scoring model for a humanitarian organisation allocating £200,000 across technology initiatives might weight criteria as follows: programme impact (30%), security improvement (25%), operational efficiency (20%), strategic alignment (15%), and implementation risk inverted (10%). An initiative scoring 4/5 on programme impact, 3/5 on security, 4/5 on efficiency, 5/5 on alignment, and 2/5 on risk would calculate as:

Programme impact:     4 × 0.30 = 1.20
Security:             3 × 0.25 = 0.75
Efficiency:           4 × 0.20 = 0.80
Strategic alignment:  5 × 0.15 = 0.75
Risk (inverted):      2 × 0.10 = 0.20
                              ------
Total weighted score:          3.70 / 5.00

MoSCoW categorisation provides a simpler alternative when weighted scoring adds unnecessary complexity. Initiatives classify as Must have (required for operations or compliance), Should have (significant value, not critical), Could have (desirable if resources allow), and Won’t have (explicitly excluded from current period). The method forces explicit acknowledgement of what will not happen, preventing implicit overcommitment.

Prioritisation frameworks require recalibration when organisational strategy shifts. An organisation pivoting from growth to consolidation would increase weight on operational efficiency and decrease weight on new capabilities. Weights encode values; when values change, weights must follow.

Portfolio governance

Portfolio governance treats technology initiatives as a managed collection rather than independent projects. Individual initiative success matters less than portfolio-level outcomes: strategic coverage, resource balance, risk distribution, and delivery velocity. Governance mechanisms monitor portfolio health, trigger interventions when initiatives struggle, and ensure the collection adapts to changing circumstances.

Portfolio health assessment examines multiple dimensions. Delivery health tracks whether initiatives progress as planned, measuring schedule variance, scope changes, and milestone achievement. Resource health monitors utilisation, identifying over-allocation that causes burnout and under-allocation that wastes capacity. Risk health aggregates initiative-level risks to identify portfolio-level exposure, particularly correlated risks that could cause multiple simultaneous failures. Strategic health verifies that the portfolio still addresses organisational priorities, which shift over time.

+------------------------------------------------------------------+
|                    PORTFOLIO HEALTH DIMENSIONS                   |
+------------------------------------------------------------------+
|                                                                  |
|                         STRATEGIC HEALTH                         |
|                    (alignment with priorities)                   |
|                              |                                   |
|                              v                                   |
|              +---------------+---------------+                   |
|              |                               |                   |
|              |         PORTFOLIO             |                   |
|              |          HEALTH               |                   |
|              |                               |                   |
|              +---------------+---------------+                   |
|             /                |                \                  |
|            /                 |                 \                 |
|           v                  v                  v                |
|   +---------------+  +---------------+  +---------------+        |
|   |   DELIVERY    |  |   RESOURCE    |  |     RISK      |        |
|   |    HEALTH     |  |    HEALTH     |  |    HEALTH     |        |
|   |               |  |               |  |               |        |
|   | - Schedule    |  | - Utilisation |  | - Initiative  |        |
|   | - Scope       |  | - Capacity    |  |   risks       |        |
|   | - Milestones  |  | - Skills      |  | - Correlated  |        |
|   | - Quality     |  | - Burnout     |  |   exposure    |        |
|   +---------------+  +---------------+  +---------------+        |
|                                                                  |
+------------------------------------------------------------------+

Governance forums provide decision-making venues at appropriate levels. A technology steering committee comprising senior leadership meets quarterly to address strategic direction, major investments, and portfolio rebalancing. An operational governance group comprising IT leadership and key stakeholders meets monthly to monitor delivery, address blockers, and make tactical adjustments. The split prevents strategic discussions from crowding out operational decisions and vice versa.

Initiative stage gates create checkpoints where governance bodies evaluate progress and authorise continuation. A four-gate model moves initiatives through concept (problem validated, approach identified), definition (requirements clear, estimates firm), delivery (implementation progressing), and closure (benefits realised, knowledge captured). Gates prevent initiatives from consuming resources without demonstrating progress. Failed gates trigger replanning or termination rather than indefinite continuation.

+-------------------------------------------------------------------+
|                    STAGE GATE MODEL                               |
+-------------------------------------------------------------------+
|                                                                   |
|   CONCEPT          DEFINITION        DELIVERY         CLOSURE     |
|      |                 |                |                |        |
|      v                 v                v                v        |
|  +--------+        +--------+       +--------+       +--------+   |
|  | Gate 1 |        | Gate 2 |       | Gate 3 |       | Gate 4 |   |
|  |        |        |        |       |        |       |        |   |
|  | Entry  |        | Commit |       | Launch |       | Close  |   |
|  +---+----+        +---+----+       +---+----+       +---+----+   |
|      |                 |                |                |        |
|      v                 v                v                v        |
|  +--------+        +---------+      +--------+       +--------+   |
|  |Problem |        |Business |      |Solution|       |Benefits|   |
|  |defined |        |case     |      |deployed|       |realised|   |
|  |        |        |approved |      |        |       |        |   |
|  |Approach|        |Plan     |      |Users   |       |Lessons |   |
|  |viable  |        |baselined|      |enabled |       |captured|   |
|  +--------+        +---------+      +--------+       +--------+   |
|                                                                   |
|  Deliverables:     Deliverables:    Deliverables:   Deliverables: |
|  - Problem stmt    - Business case  - Working       - Benefits    |
|  - Options         - Project plan     system          report      |
|  - Recommendation  - Resource plan  - Documentation - Closure     |
|                    - Risk register  - Training        report      |
|                                                                   |
+-------------------------------------------------------------------+

Portfolio rebalancing occurs when delivery reality diverges from plan. Initiatives that block or fail release resources for reallocation. New urgent requirements demand accommodation. Strategic shifts reprioritise the backlog. Rebalancing decisions require the same rigour as initial prioritisation: explicit criteria, documented rationale, and stakeholder communication. Ad hoc rebalancing without governance oversight leads to portfolio fragmentation.

Investment decisions

Investment decisions commit resources to specific initiatives based on evaluated business cases. The decision mechanism applies different rigour based on investment size, creating proportionate governance that does not burden small decisions with enterprise-level process.

Investment thresholds define boundaries between decision levels. A three-tier structure might authorise IT management to approve initiatives under £10,000, require steering committee approval for £10,000-£50,000, and escalate to executive leadership or board for amounts exceeding £50,000. Thresholds account for total cost of ownership rather than initial outlay: a £5,000 annual subscription represents £25,000 over a five-year commitment.

The investment decision flow evaluates initiatives against criteria before authorisation. Strategic fit confirms alignment with organisational direction. Feasibility assessment validates that the organisation can implement and sustain the initiative. Financial analysis examines costs, benefits, and return timeline. Risk evaluation identifies threats to success and mitigation approaches. Alternatives analysis confirms that the proposed approach outperforms other options including doing nothing.

+------------------------------------------------------------------+
|                    INVESTMENT DECISION FLOW                      |
+------------------------------------------------------------------+
|                                                                  |
|                    +-------------------+                         |
|                    | Initiative        |                         |
|                    | proposal          |                         |
|                    +---------+---------+                         |
|                              |                                   |
|                              v                                   |
|                    +-------------------+                         |
|                    | Threshold         |                         |
|                    | assessment        |                         |
|                    +---------+---------+                         |
|                              |                                   |
|         +--------------------+--------------------+              |
|         |                    |                    |              |
|         v                    v                    v              |
|  +-------------+      +-------------+      +-------------+       |
|  | < £10,000   |      | £10k-£50k   |      | > £50,000   |       |
|  | IT manager  |      | Steering    |      | Executive   |       |
|  | approval    |      | committee   |      | approval    |       |
|  +------+------+      +------+------+      +------+------+       |
|         |                    |                    |              |
|         |             +------v------+      +------v------+       |
|         |             | Business    |      | Full        |       |
|         |             | case review |      | business    |       |
|         |             +------+------+      | case with   |       |
|         |                    |             | options     |       |
|         |                    |             +------+------+       |
|         |                    |                    |              |
|         +--------------------+--------------------+              |
|                              |                                   |
|                              v                                   |
|                    +-------------------+                         |
|                    | Decision          |                         |
|                    | (approve/defer/   |                         |
|                    |  reject)          |                         |
|                    +-------------------+                         |
|                                                                  |
+------------------------------------------------------------------+

Approval without funding is not approval. Decisions that authorise initiatives without allocating resources create phantom commitments that distort portfolio planning. Governance bodies must confirm resource availability before approval or explicitly designate initiatives as approved-pending-funding with clear conditions for activation.

Deferred initiatives require explicit handling. Deferral places an initiative into a prioritised backlog with documented conditions for reconsideration. Rejection removes an initiative from consideration with documented rationale. The distinction matters: deferred initiatives retain their analysis and can activate quickly when circumstances change; rejected initiatives require fresh evaluation.

Business case development

Business cases justify investment by articulating problems, solutions, costs, benefits, and risks in sufficient depth for informed decision-making. The document serves multiple purposes: enabling governance bodies to evaluate proposals, creating accountability for benefit realisation, and providing baseline against which to measure outcomes.

Business case depth scales with investment size. Initiatives under £10,000 require a brief justification covering problem, solution, cost, and expected benefit in one page. Initiatives between £10,000 and £50,000 require a standard business case with sections addressing all evaluation criteria. Initiatives exceeding £50,000 require a full business case with detailed financial analysis, options comparison, implementation planning, and risk assessment.

Problem definition anchors the business case. A well-defined problem specifies who experiences it, what impact it causes, and how the organisation quantifies that impact. Vague problem statements produce vague solutions; precise problem statements enable focused response. “Staff struggle with the system” lacks actionability. “Finance staff spend 12 hours weekly on manual data reconciliation between the grants system and accounting software, causing month-end close to extend by 3 days” enables targeted intervention.

Benefits articulate the value the initiative delivers. Quantified benefits specify measurable improvements: hours saved, errors reduced, revenue protected. Qualified benefits describe improvements that matter but resist quantification: improved staff satisfaction, reduced risk exposure, better stakeholder relationships. Financial benefits translate to currency values; non-financial benefits describe in concrete terms. Each benefit requires an owner accountable for realisation and a measurement approach that confirms achievement.

Cost estimation covers the full investment lifecycle. Initial costs include procurement, implementation labour, training, and data migration. Ongoing costs include licensing, support, maintenance, and internal staff time for administration. Cost categories vary by initiative type; software-as-a-service initiatives concentrate costs in ongoing licensing while on-premises deployments concentrate costs in initial implementation. A five-year total cost of ownership provides the basis for comparison across different delivery models.

A worked example illustrates business case financial analysis. An organisation considering single sign-on implementation might document:

Initial costs:

SSO platform licence (first year): £3,500
Implementation consultancy (40 hours × £95): £3,800
Internal project management (60 hours × £45): £2,700
Training development and delivery: £1,200
Total initial: £11,200

Annual ongoing costs:

SSO platform licence: £3,500
Internal administration (4 hours/month × £45): £2,160
Total annual: £5,660

Five-year total cost of ownership: £11,200 + (4 × £5,660) = £33,840

Quantified benefits:

Password reset reduction (800 resets/year × 15 min × £45/hr): £9,000/year
Reduced helpdesk tickets (400 tickets × 20 min × £35/hr): £4,670/year
Total annual benefit: £13,670

Payback period: £11,200 ÷ (£13,670 - £5,660) = 1.4 years

This analysis demonstrates positive return within the planning horizon. The business case would also address non-quantified benefits such as improved security posture and staff experience, risks such as implementation complexity and vendor dependency, and alternatives such as federated identity or maintaining status quo.

Risk assessment identifies threats to initiative success and benefit realisation. Each risk describes the threat, assesses likelihood and impact, and specifies mitigation measures. Risks cluster into categories: technical risks concerning implementation feasibility, organisational risks concerning adoption and change management, financial risks concerning cost escalation or benefit shortfall, and external risks concerning vendor stability or regulatory change.

Strategic alignment

Strategic alignment ensures technology investment advances organisational mission rather than pursuing technical objectives in isolation. Alignment operates in both directions: strategy informs technology priorities, and technology capabilities enable or constrain strategic options.

Organisational strategy articulates where the organisation directs effort over a planning horizon. Strategic plans express this through goals, objectives, and initiatives. Technology planning translates strategic elements into technology implications: which systems require enhancement, what new capabilities become necessary, which technical debts create strategic risk. This translation requires IT leadership to understand programme strategy deeply enough to anticipate technology needs before they become urgent.

+--------------------------------------------------------------------+
|                    STRATEGY-TECHNOLOGY ALIGNMENT                   |
+--------------------------------------------------------------------+
|                                                                    |
|  ORGANISATIONAL STRATEGY                                           |
|  +-------------------------------------------------------------+   |
|  | Mission: Deliver humanitarian assistance to crisis-affected |   |
|  | Goal 1: Expand programme reach to 3 new countries           |   |
|  | Goal 2: Improve beneficiary outcomes measurement            |   |
|  | Goal 3: Strengthen partnership delivery model               |   |
|  +-------------------------------------------------------------+   |
|                              |                                     |
|                              | Translation                         |
|                              v                                     |
|  TECHNOLOGY IMPLICATIONS                                           |
|  +-------------------------------------------------------------+   |
|  | Goal 1 implications:                                        |   |
|  |   - Country office connectivity and infrastructure          |   |
|  |   - Multi-currency, multi-language system requirements      |   |
|  |   - Local data residency compliance                         |   |
|  |                                                             |   |
|  | Goal 2 implications:                                        |   |
|  |   - M&E platform enhancement or replacement                 |   |
|  |   - Data integration across programme systems               |   |
|  |   - Analytics and reporting capability                      |   |
|  |                                                             |   |
|  | Goal 3 implications:                                        |   |
|  |   - Partner system interoperability                         |   |
|  |   - Secure data sharing mechanisms                          |   |
|  |   - Partner capacity building for IT                        |   |
|  +-------------------------------------------------------------+   |
|                              |                                     |
|                              | Prioritisation                      |
|                              v                                     |
|  TECHNOLOGY PORTFOLIO                                              |
|  +-------------------------------------------------------------+   |
|  | FY25 priorities:                                            |   |
|  |   1. M&E platform replacement (Goal 2, Goal 3)              |   |
|  |   2. Country office network standardisation (Goal 1)        |   |
|  |   3. Partner data sharing framework (Goal 3)                |   |
|  +-------------------------------------------------------------+   |
|                                                                    |
+--------------------------------------------------------------------+

Technology roadmaps visualise the multi-year path from current state to target state. Roadmaps sequence initiatives based on dependencies, resource availability, and strategic urgency. A three-year roadmap provides sufficient horizon for major programmes while accepting that year-three specifics will change. Roadmaps communicate intent to stakeholders, enabling programme teams to anticipate when capabilities become available and plan accordingly.

Emergent strategy requires planning flexibility. Organisational direction shifts in response to funding changes, leadership transitions, external events, and learning. Technology planning that assumes stable strategy over a three-year horizon will misallocate resources. Reserve capacity for strategic emergence: 10-20% of portfolio resources uncommitted to specific initiatives allows response to unexpected priorities without disrupting committed work.

Implementation considerations

Planning sophistication must match organisational capacity. Elaborate governance frameworks that exceed implementation capacity create documentation overhead without improving decisions. The mechanisms described in this page scale across organisational contexts through selective application.

For organisations with minimal IT function, planning collapses to essential elements. Annual conversation with leadership identifies 3-5 technology priorities for the year. Simple prioritisation using a value-feasibility matrix sequences those priorities. Monthly check-ins track progress and surface emerging needs. Business cases reduce to one-page justifications for investments over £5,000. This minimal approach still provides structure: explicit priorities, documented decisions, regular review.

For organisations with small IT teams, planning adds portfolio thinking. Quarterly reviews assess progress across initiatives and adjust priorities. Stage gates verify initiatives before major commitments. Weighted scoring differentiates between the 10-20 initiatives competing for attention. Business cases expand for larger investments while remaining proportionate. A part-time governance forum, perhaps monthly meetings with IT and finance leadership, provides decision-making venue.

For organisations with established IT functions, full planning mechanisms apply. Dedicated portfolio management tracks initiatives across stages. Formal governance bodies with defined membership and authority make decisions at appropriate levels. Business cases follow standard templates with consistent evaluation criteria. Benefits realisation tracking confirms that investments deliver promised value.

Multi-entity organisations face additional complexity. Federated structures where country offices maintain IT autonomy require coordination mechanisms that respect local authority while enabling economies of scale. A model that works: global IT sets standards and provides shared services, regional hubs coordinate within their geography, and country offices make local decisions within established parameters. Planning at each level follows similar cycles with explicit handoffs between levels.

Grant-funded organisations align planning with funding cycles. Major donor grants create windows of technology investment opportunity that may not align with fiscal year planning. The planning framework accommodates this through contingent approval: initiatives approved in principle, activated when funding confirms. This prevents planning paralysis while maintaining governance rigour.

Business case template

This template provides structure for initiatives requiring formal justification. Scale depth to investment size: one page for initiatives under £10,000, full completion for initiatives over £50,000.

Initiative name

[Clear, descriptive name that identifies the initiative]

Executive summary

[2-3 sentences capturing problem, solution, cost, benefit, and recommendation]

Problem statement

[Specific description of the problem including who experiences it, what impact it causes, and how that impact is measured. Include quantification where possible.]

Proposed solution

[Description of the recommended approach. What will be implemented, how it addresses the problem, and what changes for users and operations.]

Alternatives considered

[Other options evaluated including maintaining status quo. For each alternative: brief description, reason for non-selection.]

Costs

Initial costs:

[Item]: £[amount]
[Item]: £[amount]
Total initial: £[amount]

Annual ongoing costs:

[Item]: £[amount]
[Item]: £[amount]
Total annual: £[amount]

Five-year total cost of ownership: £[amount]

Benefits

Quantified benefits (annual):

[Benefit description]: £[amount]
[Benefit description]: £[amount]
Total quantified annual benefit: £[amount]

Non-quantified benefits:

[Benefit description]
[Benefit description]

Financial analysis

Payback period: [X] years
Five-year net benefit: £[amount]

Risks

[For each significant risk:]

Risk: [description]
Likelihood: [High/Medium/Low]
Impact: [High/Medium/Low]
Mitigation: [approach]

Implementation approach

Estimated duration: [X] months
Key milestones: [list]
Resource requirements: [internal and external]
Dependencies: [other initiatives or external factors]

Recommendation

[Clear statement of requested decision: approve, approve with conditions, or defer pending specific conditions]

Prepared by: [Name, role] Date: [Date] Sponsor: [Name, role of business sponsor]