Define the Purpose, Inputs, Activities, Roles, Outputs, Evidence, and Gates for Every SDLC Phase

This chapter establishes the minimum outcome-oriented operating model for every phase.

Best Practice: Apply Complete Phase Definition

Every phase should define purpose, intended outcomes, applicability, boundaries, starting conditions, entry criteria, inputs, dependencies, Activities, roles, stakeholders, decision rights, outputs, Artifacts, documentation, evidence, Gates, exit criteria, Environments, baselines, records, Technical Debt, tailoring, exceptions, metrics, and adjacent-phase relationships.

Benefits: Defining entry criteria, exit criteria, and adjacent-phase relationships together, not just a phase’s internal activities, means practitioners know exactly when a phase is ready to begin and what condition it needs to reach before the next phase can meaningfully start.

Best Practice: Apply Outcome Orientation

Purpose explains why the phase exists. Activities perform work. Outputs are produced information or technical content. Outcomes are the meaningful conditions achieved. A phase should close because outcomes are sufficiently demonstrated, not because a date arrived or a document was submitted.

Benefits: Requiring a phase to close because its outcomes were demonstrated, not because a date arrived, is what keeps schedule pressure from quietly substituting a calendar milestone for the actual condition the phase was supposed to achieve. This distinction is often the difference between genuine readiness and an administrative formality.

Best Practice: Preserve Evidence and Readiness

Evidence should support a specific claim or decision and be attributable to scope, version, baseline, Environment, work, and reviewer. Gates should identify authority, criteria, evidence, participants, outcomes, escalation, and decision record. Unresolved obligations may transfer only when visible, owned, authorized, and traceable.

Benefits: Requiring evidence to be attributable to a specific scope, version, and reviewer means a Gate decision rests on something a later reviewer can actually verify, rather than a general sense that things seemed fine at the time.

Best Practice: Apply Enterprise Knowledge and Records

Each phase should publish required or improved documentation to the Enterprise Document Repository, update applicable authoritative inventories and systems, and define phase-specific Technical Debt responsibilities. Consistent phase structures improve search, reporting, onboarding, automation, and AI analysis.

Benefits: Publishing documentation and updating inventories as part of each phase’s own definition, rather than as a separate afterthought, means enterprise knowledge accumulates naturally as work progresses instead of requiring a dedicated cleanup effort that competes with the next Release’s priorities.

Example

For the Design Phase of a customer portal, the purpose is to define an implementable solution that satisfies approved requirements and constraints. Inputs include requirements, Non-Functional Requirements (NFRs), architecture standards, data classifications, and risk findings. Activities include solution design, threat modeling, accessibility design, and integration specification. Roles include the solution architect, security architect, data owner, Product Owner, and engineering lead. Outputs include architecture diagrams, decisions, interface specifications, and updated risks. Evidence is reviewed at the Design gate, which approves progression, requires conditions, or returns the Release for rework.

Best Practice: Advance Maturity Deliberately for Define the Purpose, Inputs, Activities, Roles, Outputs, Evidence, and Gates for Every SDLC Phase

At Crawl maturity, define each phase’s essential purpose, entry and exit criteria, and minimum evidence, even if recorded in a simple shared document. At Walk maturity, publish complete phase definitions covering all required elements, reviewed and maintained by named phase owners. At Run maturity, maintain phase definitions through structured metadata that automation and Gate tooling can reference directly, keeping Gate criteria and phase definitions from silently drifting apart.

Benefits: Starting with essential entry and exit criteria at Crawl maturity ensures the most consequence-bearing gaps get closed first. Publishing complete phase definitions at Walk maturity gives every practitioner the same reference regardless of who they ask. Maintaining structured, tooling-referenced metadata at Run maturity keeps automated Gates enforcing criteria that actually match the current, approved phase definition.

Best Practice: Avoid Common Antipatterns in Define the Purpose, Inputs, Activities, Roles, Outputs, Evidence, and Gates for Every SDLC Phase

Enterprises should avoid closing a phase because a date arrived rather than because outcomes were demonstrated. A phase’s exit criteria exist to confirm real, demonstrated outcomes; treating a scheduled date or a submitted document as sufficient to close the phase lets the underlying purpose go unmet while the calendar milestone is satisfied.

Benefits: Avoiding this antipattern keeps phase closure meaningful. It ensures a phase actually achieved what it was meant to achieve, not just that its allotted time expired.

Connections to Related IF4IT Practices and Inventories

Use the IF4IT Enterprise Model and the Data and Information Inventory and Attributes to treat SDLC artifacts, evidence, metadata, and relationships as governed knowledge assets rather than disconnected documents. Keep this chapter’s decisions and responsibilities connected to enterprise structure, capability ownership, and measurable business outcomes through the IF4IT Enterprise Model, Enterprise Capability Models, and the Capabilities Inventory and Attributes.

Apply the Non-Functional Requirements (NFRs) Framework for Software Systems so quality expectations stay connected to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance.

Use Release Management guidance alongside IT Operating Environments Best Practices and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology to govern how Release scope, environment progression, deployment evidence, cutover, rollback, and closure are actually managed.