All guides

The Push method

Project Architecture

A prescriptive outline for organising a Push project: the stages, the documents each stage produces, and how they fit together.

Updated Sep 11, 20264 min read
push
documentation
delivery
governance

The manifesto is deliberately non-prescriptive. Teams still ask for a starting shape, so this page gives one: a portal or wiki structure that follows a project from idea to operation. Treat it as scaffolding. Keep the parts that earn their place and drop the rest.

Every heading below is a page or folder in the project's own documentation. The order is the order the work happens in.

  • Welcome introduces the project and gives visitors a map of everything else.
  • Solution Guide describes the solution as a whole, with a Solution Exception Guide for anything that deviates from the standard approach.
  • Initiate is where the project starts. An Idea Brief states the idea and its objectives. EPICs set the high-level goals and break down into Features.
  • Design captures business processes, user stories, technical designs, decision records and the solution design (including reporting and non-functionals), plus the test strategy and the environments needed.
  • Build and Test are where the solution is made and proven. Each stage records its own environments, and Test also holds plans and reports.
  • Release prepares the solution for use: quality plan and road map, work instructions, operational handover, the releases themselves (pre-release, 1.0) and a go-live readiness checklist.
  • Governance covers how the project is run: meetings, risks, acceptance criteria, definition of done, ways of working, submissions, reports, retrospectives, planning, standards, principles and patterns, reviews, and who is responsible for keeping records.
  • Resources, Glossary, Guides and Feedback and Questions hold the supporting material: templates and tools, definitions of terms, onboarding guides, and a place for visitors to ask questions.
  • Welcome Page: the first page visitors see, with an overview of the project and navigation to every other section.
  • Solution Guide: a detailed overview of the solution and its components, including known exceptions and limitations.
    • Solution Exception Guide
  • Initiate: the early stages, from idea brief to EPICs and features.
    • Idea Brief
    • EPICs
      • Features
        • Feature 1, 2, 3…
  • Design: business processes, user stories, technical designs, decision records and the overall solution design, with sub-sections for reporting, non-functionals, test strategy and environments.
    • Business Processes
    • User Stories
    • Technical Designs
    • Decision Records1
    • Solution Design
      • Reporting
      • Non-Functionals
    • Test Strategy
    • Environments
  • Build: setup and configuration of the build environments.
    • Environments
  • Test: test plans, reports and environments.
    • Plans
    • Reports
    • Environments
  • Release: release plans, quality plans, road maps, work instructions, operational handover and go-live readiness.
    • Plans
      • Quality Plan
      • Road Map
    • Work Instructions
    • Operational Handover
    • Releases
      • Pre-release
      • 1.0
    • Go-Live Readiness
      • Checklists
  • Governance: how the project is managed.
    • Meetings
    • Risks
    • Acceptance Criteria
    • Definition of Done
    • Ways of Working
    • Submissions
    • Reports
    • Retrospectives
    • Planning
    • Standards
    • Principles and Patterns
    • Reviews
    • Records Keeping Responsibility
      • Requirements
      • Information Exchange
      • Auditing of Data Access
  • Resources: templates, tools and other relevant material.
  • Glossary: definitions of the technical terms and jargon used throughout the project.
  • Guides: guides and tutorials, starting with onboarding.
  • Feedback and Questions: a place for visitors to give feedback or ask questions.

Releases follow Semantic Versioning 2.0.0:2

  • MAJOR for breaking changes
  • MINOR for added functionality that stays backwards-compatible
  • PATCH for backwards-compatible bug fixes

Example: 1.2.3-prerelease+build.

Footnotes🔗

  1. The decision-record format is from Nygard, M. (2011). Documenting architecture decisions. cognitect.com ↩

  2. Preston-Werner, T. Semantic Versioning 2.0.0. semver.org ↩

Project Architecture | Push Manifesto · Push Manifesto