Planning Phase of the Systems Development Lifecycle (SDLC)

Defines the third IF4IT SDLC phase, in which the enterprise turns an authorized lifecycle candidate and available research evidence into a proportionate, resourced, sequenced, and governable plan for delivery and operation.

Purpose

The Planning phase establishes how the enterprise will achieve the intended outcome and govern the work. It connects strategy and research to Requirements Capture, Design, acquisition, Build, Verification, Validation, transition, operations, and retirement obligations without pretending that all future information is already known.

Typical Inputs

Inputs may include the authorized Intake decision, research and prototype evidence, stakeholder outcomes, preliminary scope, Product or Service roadmaps, Architecture direction, sourcing options, estimates, constraints, dependencies, Risks, regulatory and contractual obligations, supplier information, portfolio priorities, and available capacity.

Core Activities

Define scope and exclusions; outcomes and success measures; accountable owners and decision authorities; delivery and sourcing approach; Release and iteration structure; milestones and dependencies; resource, funding, procurement, and supplier needs; applicable phases and Environments; Requirements, Architecture, Security, Privacy, Data, accessibility, Safety, V&V, training, operations, support, recovery, and retirement planning; and the change-control approach.

Create the SDLC Utilization Profile

Planning should produce or update the Release-specific SDLC Utilization Profile. The profile identifies applicable phases, Activities, Artifacts, evidence, Environments, gates, roles, tailoring decisions, deferred obligations, exceptions, and assurance intensity so that the lifecycle path is explicit rather than assumed.

Plan Releases and Incremental Outcomes

Decompose the intended change into coherent Releases or Release Iterations that can be built, acquired, verified, validated, deployed, supported, and measured. Sequencing should consider dependencies, migration, coexistence, backward compatibility, data, supplier lead times, training, operational capacity, rollback, and retirement of displaced capabilities.

Outputs and Evidence

Outputs may include an integrated lifecycle plan, approved SDLC Utilization Profile, Product or Project plan, Release roadmap, estimates, funding and resource commitments, sourcing and procurement plan, Environment plan, assurance and test strategy, Risk register, dependency map, communication and stakeholder plan, operational-transition plan, and planning baseline.

Decision and Exit Criteria

Exit requires enough planning confidence to authorize the next work, named ownership, available or conditionally committed resources, governed uncertainty, explicit dependencies and Risks, an approved lifecycle path, and alignment between intended outcomes, schedule, cost, scope, sourcing, and operational obligations.

Application Across Solution Types and Methods

Custom-Built planning emphasizes engineering capacity, Architecture, components, integration, testing, and technical delivery. Acquired-Solution planning emphasizes evaluation, contracting, supplier lead times, configuration, data migration, integration, acceptance, and exit rights. Composite planning must coordinate both. Waterfall may baseline a more complete plan earlier; Agile and Hybrid approaches progressively elaborate it.

Crawl-Walk-Run Maturity

At Crawl maturity, maintain an approved scope, owner, milestones, resources, Risks, Release approach, and SDLC Utilization Profile. At Walk maturity, integrate portfolio, Product, Architecture, supplier, Environment, assurance, and operational plans. At Run maturity, use connected planning data, scenario analysis, predictive measures, and continuous replanning based on evidence and outcomes.

Common Antipatterns

Enterprises should avoid skipping or compressing Planning under schedule pressure. Treating Planning as overhead to cut when a deadline looms leaves scope, dependencies, and Risk implicitly undefined instead of explicitly and deliberately reduced, which tends to surface as rework or missed dependencies later in the Release.

Connections to Related IF4IT Practices and Inventories

Use the Designing, Building, and Maintaining Comprehensive and Usable Enterprise Capability Models guidance and the Capabilities Inventory and Attributes to connect proposed work to capability gaps, strategic outcomes, affected value streams, and investment priorities. Apply Application Portfolio Management (APM) Best Practices and consult the Applications Inventory and Attributes when evaluating reuse, modernization, acquisition, investment priority, ownership, and portfolio dependencies.

Connect this practice to Release Management guidance, IT Operating Environments Best Practices, and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology, which together govern Release scope, environment progression, deployment evidence, cutover, rollback, and closure.

Apply Technical Debt Management Best Practices and the Technical Debt Inventory and Attributes to identify, qualify, record, prioritize, remediate, accept, and periodically reassess intentional, inherited, emergent, and deferred lifecycle obligations.