← Full mapCurated public summary
Index
Entry 03PUBLIC HANDBOOK

How to start a project

Journey from problem and capabilities through discovery, ADR, architecture, Golden Flows, sprint, execution, evidence, and learning.

Source & authority

Public explanation

PUBLIC HANDBOOK
Based on
Human Handbook 03 — How to start a project
Related normative sources
  • NORMATIVE SOURCEStandard · Development Methodology
  • NORMATIVE SOURCEStandard · Solution Discovery Gate
  • NORMATIVE SOURCEStandard · Existing Solution Assessment
Authority
Public explanation — NON-NORMATIVE
Summary

Journey from problem and capabilities through discovery, ADR, architecture, Golden Flows, sprint, execution, evidence, and learning.

Starting a project in DCP Flow means reducing uncertainty before accelerating execution. The same journey applies to a new solution or the adoption of an existing system.

From need to decision

Define the problem and required capabilities first. Then run Solution Discovery, compare real alternatives, and record through an ADR why ADOPT, CONFIGURE, INTEGRATE, EXTEND, or BUILD is appropriate.

Key points
  • Problem and scope.
  • Capability Matrix.
  • Solution Discovery.
  • Decision ADR.

From decision to first sprint

Once direction is set, choose architecture and Blueprint, identify Golden Flows and risks, and create a sprint with verifiable outcomes. Execution produces evidence for acceptance and learning.

Key points
  • Architecture and boundaries.
  • Golden Flows.
  • Execution Contract and handoffs.
  • Evidence and Human Acceptance.

New and existing projects start differently

A new project can begin with the problem and outcome before architecture is consolidated. An existing project already carries code, users, runtime, debt, and prior decisions; DCP Flow starts by reconstructing Project Truth and separating what is merely different from what is actually wrong. Adopting the methodology does not mean rewriting working software for visual technical uniformity.

Key points
  • New: problem → outcome → capabilities.
  • Existing: audit → Project Truth → material gaps.
  • Different does not mean incorrect.
  • Prefer incremental improvement over ceremonial rewrites.

From capabilities to a defensible decision

After the problem is understood, capabilities are separated into MUST, SHOULD, and COULD. When a material capability may exist as SaaS, an open-source product, or a reusable component, Solution Discovery applies. Decisions that change architecture, dependency, future cost, security, or licensing are captured in an ADR before selecting the applicable Blueprint and Standards.

Key points
  • MUST / SHOULD / COULD.
  • Solution Discovery for material capabilities.
  • ADR for decisions that need durable memory.
  • Blueprint follows the real technology-family decision.

Golden Flow, sprint, execution, and learning closure

Before work becomes a task list, define the end-to-end journey that proves value. The sprint fixes a verifiable outcome, scope, non-goals, evidence, and Definition of Done. An Execution Contract or handoff limits what an agent must interpret; audit and Quality Gates then verify the result, and the retrospective decides whether learning stays local or deserves promotion into reusable knowledge.

Key points
  • Golden Flow before accumulating tasks.
  • Sprint = verifiable outcome.
  • Execution Contract reduces improvisation.
  • Audit → acceptance → learning.
Contextual glossary+
ADR

Record of a material architecture decision, its context, and rationale.

Golden Flow

Critical end-to-end journey that must work and produce verifiable evidence.

Project Truth

Durable, verifiable project state that should prevail over temporary memory or assumptions.

Solution Discovery

Process of investigating real alternatives and proportionally evaluating ADOPT → CONFIGURE → INTEGRATE → EXTEND → BUILD before a material decision.