Problem vs Change Portfolio: Stop Letting Changes Starve Prevention

{
  "id": "ams-027",
  "title": "Problem vs Change Portfolio: Stop Letting Changes Starve Prevention",
  "hook": "SAP AMS usually drowns not because of too many incidents, but because Problems and Changes fight for the same oxygen — and Problems always lose.",
  "idea": "Modern AMS runs two connected but protected portfolios: Changes (delivery) and Problems (load elimination). They are planned together, but funded and governed differently.",
  "sap_specific_failure_mode": {
    "what_happens_in_classic_ams": [
      "Changes consume all capacity because they have dates and sponsors",
      "Problems are ‘important but not urgent’ and slip forever",
      "Recurring incidents quietly become the cost of doing business",
      "AMS teams look busy while the system gets worse"
    ]
  },
  "two_portfolios_model": {
    "change_portfolio": {
      "purpose": "Deliver requested modifications safely",
      "nature": "Date-driven, request-based",
      "success_metric": "Delivery predictability and low regression"
    },
    "problem_portfolio": {
      "purpose": "Eliminate recurring demand and instability",
      "nature": "Data-driven, internally triggered",
      "success_metric": "Repeat reduction and load removed"
    }
  },
  "capacity_allocation": {
    "rule_of_thumb": [
      "Minimum 20–30% of AMS capacity reserved for Problems",
      "This capacity is protected and cannot be stolen by ‘urgent’ changes"
    ],
    "dynamic_adjustment": [
      "If repeat incident rate rises → increase Problem capacity",
      "If system is stable for multiple months → cautiously reduce, never to zero"
    ]
  },
  "prioritization_logic": {
    "problems": [
      "Rank by recurring load (hours/month) × business impact",
      "Prefer problems that unlock multiple incident families",
      "Deprioritize cosmetic or rare-edge problems explicitly"
    ],
    "changes": [
      "Rank by business impact and cost of delay",
      "Penalize changes that increase blast radius or lock-in",
      "Fast-lane only when risk and verification are known"
    ]
  },
  "portfolio_collision_rules": [
    "A Change that creates repeats automatically spawns a Problem with priority.",
    "A Problem that requires a Change inherits its change risk and gates.",
    "If a Change blocks Problem work repeatedly, escalate at portfolio level — not team level."
  ],
  "boards_and_visibility": {
    "separate_boards": [
      "Change Board (delivery flow)",
      "Problem Board (elimination flow)"
    ],
    "shared_views": [
      "Top 10 demand drivers",
      "Problems killing the most load",
      "Changes causing the most instability"
    ]
  },
  "decision_gates": {
    "problem_commit_gate": [
      "Load quantified",
      "Root cause plausible",
      "Elimination path identified",
      "Verification plan defined"
    ],
    "change_commit_gate": [
      "Blast radius known",
      "Test evidence planned",
      "Rollback defined",
      "Owner named"
    ]
  },
  "automation": {
    "copilot_moves": [
      "Quantify load removed if a Problem is solved.",
      "Simulate capacity impact of committing one more Change.",
      "Flag portfolio imbalance (too many Changes, starving Problems)."
    ],
    "outputs": [
      "Weekly portfolio balance report",
      "Problem ROI ranking",
      "Change vs stability risk heatmap"
    ]
  },
  "anti_patterns_to_kill": [
    "Problems tracked only in spreadsheets",
    "‘We’ll fix it later’ without a slot",
    "Letting VIP changes consume prevention capacity",
    "Pretending firefighting is normal operations"
  ],
  "metrics_that_show_control": [
    "Capacity split (Problems vs Changes)",
    "Repeat incident trend",
    "Problems closed vs opened",
    "Incidents per Change ratio"
  ],
  "design_question": [
    "Which Problems would pay for themselves within one quarter if we actually did them?"
  ],
  "meta": {
    "schema": "dkharlanau.dataset.byte",
    "schema_version": "1.1",
    "dataset": "ams",
    "source_project": "cv-ai",
    "source_path": "ams/ams-027.json",
    "generated_at_utc": "2026-02-03T14:33:32+00:00",
    "creator": {
      "name": "Dzmitryi Kharlanau",
      "role": "SAP Lead",
      "website": "https://dkharlanau.github.io",
      "linkedin": "https://www.linkedin.com/in/dkharlanau"
    },
    "attribution": {
      "attribution_required": true,
      "preferred_citation": "Dzmitryi Kharlanau (SAP Lead). Dataset bytes: https://dkharlanau.github.io"
    },
    "license": {
      "name": "",
      "spdx": "",
      "url": ""
    },
    "links": {
      "website": "https://dkharlanau.github.io",
      "linkedin": "https://www.linkedin.com/in/dkharlanau"
    },
    "contact": {
      "preferred": "linkedin",
      "linkedin": "https://www.linkedin.com/in/dkharlanau"
    },
    "canonical_url": "https://dkharlanau.github.io/datasets/ams/ams-027.json",
    "created_at_utc": "2026-02-03T14:33:32+00:00",
    "updated_at_utc": "2026-02-03T15:29:02+00:00",
    "provenance": {
      "source_type": "chat_export_extraction",
      "note": "Extracted and curated by Dzmitryi Kharlanau; enriched for attribution and crawler indexing."
    },
    "entity_type": "ams_byte",
    "entity_subtype": "",
    "summary": "SAP AMS usually drowns not because of too many incidents, but because Problems and Changes fight for the same oxygen — and Problems always lose."
  }
}