Research and Prototyping Phase of the Systems Development Lifecycle (SDLC)

Defines the second IF4IT SDLC phase, in which the enterprise investigates material uncertainty, tests assumptions, evaluates options, and develops evidence before committing to a detailed plan, acquisition, Design, or Build path.

Purpose

The Research and Prototyping phase converts uncertain assumptions into explicit questions and usable evidence. It protects the enterprise from premature commitments by testing feasibility, desirability, viability, operability, integration, data, supplier, Security, Privacy, accessibility, safety, and supportability concerns while change remains relatively inexpensive.

Typical Inputs

Inputs may include the authorized Intake record, strategic outcomes, preliminary scope, stakeholder needs, current-state information, known constraints, initial Risks, Architecture principles, market information, supplier options, technology hypotheses, data samples, Incidents, Technical Debt, obsolescence concerns, and unresolved questions from earlier work.

Core Activities

Define the research questions, assumptions, success and stop criteria, timebox, owner, participants, Environments, data protections, and evidence plan. Perform targeted market research, technical spikes, simulations, proofs of concept, prototypes, user research, supplier demonstrations, integration experiments, data profiling, threat exploration, and operational feasibility analysis as applicable.

Prototype Governance

Classify each prototype as disposable, evolutionary, or reusable. Record its limitations and prevent experimental code, credentials, data, dependencies, or supplier arrangements from becoming an unmanaged Production baseline. Any prototype proposed for continued use must enter controlled Design, Build, Verification, Validation, and operational-readiness work.

Outputs and Evidence

Outputs may include research findings, experiment records, prototype results, option comparisons, feasibility assessments, updated Risks and assumptions, supplier findings, Architecture implications, cost and schedule ranges, recommended direction, rejected alternatives, and a traceable decision package.

Decision and Exit Criteria

Exit requires sufficient evidence for an authorized decision, explicit treatment of remaining uncertainty, ownership of follow-up actions, updated scope and Risks, and a clear route into Planning, Requirements Capture, acquisition, an existing Product backlog, additional research, deferral, or closure.

Application Across Solution Types and Methods

Custom-Built Solutions may emphasize technical spikes, Architecture options, and reusable components. Acquired Solutions may emphasize market capability, supplier viability, contractual constraints, integration, data portability, and operating model fit. Composite Solutions should test component interactions and responsibility boundaries. Agile research may occur through spikes or discovery iterations; Waterfall and Hybrid work may use a distinct feasibility stage.

Crawl-Walk-Run Maturity

At Crawl maturity, timebox research, name the decision, record findings, and prevent uncontrolled prototype promotion. At Walk maturity, standardize experiment templates, evidence, Architecture participation, supplier evaluation, and handoffs. At Run maturity, reuse enterprise knowledge, test assets, sandboxes, telemetry, and automated experimentation while measuring research value and prediction quality.

Common Antipatterns

Enterprises should avoid allowing a disposable prototype to become the Production baseline. Experimental code, credentials, or data that were never meant to be permanent can quietly become an unmanaged Production dependency when a promising prototype is extended rather than rebuilt through controlled Design, Build, and Verification.

Connections to Related IF4IT Practices and Inventories

Apply the IF4IT Enterprise Model, Enterprise Capability Models, and the Capabilities Inventory and Attributes so this chapter’s decisions and responsibilities stay tied to enterprise structure, capability ownership, and measurable business outcomes. Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to connect the decisions and responsibilities addressed in this chapter to governed technology choices, platform lifecycle, and environment controls.

Govern Release scope, environment progression, deployment evidence, cutover, rollback, and closure using Release Management guidance, IT Operating Environments Best Practices, and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology.

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.