Right-Sized Framework™

Chapter 6 · Plan

Don't Wander — Plan with Purpose

Think slow, act fast. Front-load the unknowns, then execute with momentum.

Step InsideTake the AssessmentJump to References
Plan phase flow: Vision and Value Thesis → User Stories, Use Cases, L0/L1 Requirements → System Concept and Block Diagram, Interfaces (ICD) → SRR and CoDR in 30 days.

Step Inside

The plan phase engineers uncertainty out of everything downstream.

The plan phase sets direction and confirms product-market fit before design begins — it settles the why and the how before the what. Done well, it engineers the uncertainty out of everything downstream.

Two blueprints make the case. The Empire State Building was built on paper many times before the first rivet: scope frozen early, design decomposed into repeatable units, a logistics plan that turned a skyscraper into an assembly line. It finished ahead of schedule and under budget — in the Great Depression — because variability had been engineered out. The Sydney Opera House began with a gorgeous concept but broke ground before the hard engineering was solved; scope moved, interfaces shifted, and the final cost ran more than ten times the budget.

The lesson isn't daring versus caution — it's where daring belongs: concentrate learning and decisions at the front end, then exploit that clarity with speed.

A right-sized plan phase produces:

  • Traceable requirements — vision → user stories → use cases → layered L0/L1/L2, each with testable acceptance criteria
  • Visible system architecture — a block diagram of fewer than ~10 subsystems, with interfaces defined in an ICD
  • Milestone-driven story map and roadmap — dependencies, decision clocks, and long-lead items identified
  • Owned risk-and-opportunity posture — named, scored, and actively worked
  • Clean reviews — SRR and CoDR with explicit entry and exit criteria

Risk & Opportunity strategies at a glance: Risks → Avoid · Transfer · Mitigate · Accept. Opportunities → Exploit · Share · Enhance · Accept.

"Failing to plan is planning to fail." — Benjamin Franklin

The question for your project: are you still building on paper, or already pouring concrete?

Action Plan

Launching Your Plan Phase

Four steps to get started

  1. Create your first block diagram.
    A simple visual overview aligns everyone on what you're building and how the major subsystems fit together. Fewer than ten boxes is a feature, not a limitation.
  2. Label the interconnects.
    Clarify how subsystems communicate — informationally and mechanically — to reduce integration surprises later. Capture these in an Interface Control Document (ICD).
  3. Download the SRD, SRR, ICD, Risk Register, and other templates at the RSF Framers Community and customize them for your team. Turn ideas into an executable plan with living documents tailored to your project's needs.
  4. Get some AI — it's a 10xer.
    Check out the resources at rightsizedframework.com. Let AI handle tedious documentation so your team can focus on high-value thinking and problem-solving.
Block diagram example — subsystems with defined interfaces, signal conditioning, and wireless interface layers.
Agile planning wall — colorful sticky notes organized on a grid, representing story mapping and milestone planning in action.

Directed Tools and Templates

Plan smarter, not harder.

Start with the Plan Hub for requirements and templates, then use the Review Hub to set your SRR and CoDR entry/exit criteria. The SE Hub provides systems architecture and interface guidance.

Self-Assessment

Plan-Phase Readiness

Planning is where teams either build momentum or quietly lock in delays. This assessment scores the five disciplines of a right-sized plan phase separately, so you can see which one is strongest — and which one is quietly putting your timeline at risk. Answer honestly; it's a mirror, not a report card.

1 = Never true · 2 = Rarely · 3 = Sometimes · 4 = Often · 5 = Consistently — answer honestly. This is a mirror, not a report card.

Requirements & Traceability Total possible: 20

1. We translate our vision into user stories, use cases, and layered (L0–L2) requirements.

2. Every acceptance criterion is testable and measurable (e.g., Given–When–Then with quantitative thresholds).

3. We maintain traceability from user need through requirement to test.

4. We treat requirements as living artifacts and manage them in purpose-built tools, not spreadsheets.

Conceptual Design & System Architecture Total possible: 20

5. We have a simple block diagram (fewer than ~10 major subsystems) that everyone can point to.

6. Every subsystem traces to a user story or use case — no nice-to-haves that add cost without value.

7. We define interfaces early (informational and mechanical) and capture them in an interface control document.

8. We favor proven, standard interfaces over custom ones to reduce integration risk.

Project Planning & Story Mapping Total possible: 20

9. Our plan is milestone-driven, with dependencies, long-lead items, and resources identified.

10. We use a story map organized by user outcomes, sliced into minimal releasable increments.

11. Major decisions have clear owners and "decision clocks" — dates by which they must be made.

12. We protect the timeline with a technology cutoff and MVP discipline; new ideas go to "Gen 2."

Risk & Opportunity Management Total possible: 20

13. We identify risks and opportunities early using IF–THEN, scored for probability and consequence.

14. Every risk has a chosen strategy (avoid, transfer, mitigate, or accept) and a named owner.

15. We treat opportunities with the same discipline as risks (exploit, share, enhance, or accept).

16. We review the R&O register on a regular cadence and disposition each item (act, track, or retire).

Reviews & Readiness (SRR / CoDR) Total possible: 20

17. We hold an SRR to confirm requirements are well-defined, feasible, and traceable before design.

18. We hold a CoDR to confirm the system concept, key trades, and verification approach.

19. Our major reviews have explicit entry and exit criteria, and decisions get owners.

20. Reviews turn plan-phase hypotheses into a committed direction the whole team shares.

References & Further Study

Go Deeper