Lifecycle Adoption

Overview

This skill guides incremental CMMI adoption on existing projects without halting development. Whether you're starting a new project with CMMI from day one or retrofitting practices onto a 5-year-old codebase, this skill provides strategies for:

• Parallel tracks adoption: New work follows new process, legacy code exempt
• Retrofitting existing systems: Adding traceability, CM, testing, and metrics to running projects
• Change management: Overcoming team resistance and executive skepticism
• Right-sizing practices: Scaling from 2-person teams to large organizations
• Managing transitions: Tool migrations, process changes, audit preparation

Reference: See docs/sdlc-prescription-cmmi-levels-2-4.md Section 9 (Adoption Guide) for complete policy.

When to Use This Skill

Use this skill when:

• Starting new project: Bootstrapping CMMI Level 2/3/4 from day one
• Mid-project adoption: Adding CMMI to active development without stopping
• Audit preparation: Retrofitting traceability/documentation for upcoming compliance review
• Tool migration: Changing platforms (GitHub ↔ Azure DevOps) while maintaining compliance
• Team resistance: Developers push back on "process overhead"
• Executive skepticism: Need to demonstrate ROI for CMMI investment

What This Skill Covers

High-Level Guidance:

• The Parallel Tracks Strategy (don't stop development)
• Incremental vs. Big Bang Adoption
• Quick Wins vs. Foundational Practices
• Team Size Adaptations (2 developers to 50+)

Reference Sheets (On-Demand):

1. Maturity Assessment - Gap analysis, current state mapping, prioritization
2. Incremental Adoption Roadmap - Phased rollout, pilot projects, scaling strategies
3. Retrofitting Requirements - Adding traceability to existing features
4. Retrofitting Configuration Management - Adopting branching strategies mid-project
5. Retrofitting Quality Practices - Adding tests and reviews to legacy code
6. Retrofitting Measurement - Establishing baselines without historical data
7. Managing the Transition - Parallel operations, migration strategies, preserving compliance
8. Change Management - Team buy-in, executive sponsorship, demonstrating value

---

High-Level Guidance

The Parallel Tracks Strategy

The Core Principle: You don't need to stop development to adopt CMMI. Use parallel tracks:

┌─────────────────────────────────────────────────────────┐
│ NEW FEATURES (Follow New Process)                       │
│ - Requirements tracked in issues                        │
│ - ADRs for design decisions                            │
│ - PR reviews required                                   │
│ - Test coverage enforced                                │
│ - Full CMMI compliance                                  │
└─────────────────────────────────────────────────────────┘
                           │
                           │ Parallel Development
                           │
┌─────────────────────────────────────────────────────────┐
│ EXISTING CODE (Exempt from Retrofit)                    │
│ - Legacy code untouched unless modified                │
│ - Bug fixes follow minimal process                     │
│ - Critical paths retrofitted selectively               │
│ - No "rewrite everything" required                     │
└─────────────────────────────────────────────────────────┘

Timeline: 2-3 months to full adoption for typical team (5-10 developers)

Benefits:

• ✅ Development velocity maintained
• ✅ Team learns gradually (not overwhelmed)
• ✅ Quick wins demonstrate value
• ✅ Audit trail created going forward

Anti-Pattern: "Big Bang Adoption" - Trying to go from Level 1 to Level 3 overnight. Result: Development freeze, team revolt, incomplete implementation.

Incremental vs. Big Bang Adoption

| Aspect | Big Bang (❌ Anti-Pattern) | Incremental (✅ Recommended) | |--------|---------------------------|------------------------------| | Timeline | "We're Level 3 starting Monday!" | 2-3 month phased rollout | | Development | Freeze while implementing | Parallel tracks, continuous shipping | | Team reaction | Overwhelm, resistance | Gradual learning, buy-in | | Risk | High (all-or-nothing) | Low (course corrections possible) | | First milestone | Full compliance | Quick wins (branch protection, PR reviews) |

Why Big Bang Fails:

1. Cognitive overload: 11 process areas, 100+ practices = team paralysis
2. Business pressure: "Why aren't we shipping?" within 2 weeks
3. Incomplete implementation: Rushing leads to cargo cult compliance (checklist theater)
4. No feedback loop: Can't learn what works for your team context

Incremental Approach:

1. Week 1-2: Quick wins (branch protection, PR templates, issue tracking)
2. Week 3-4: Foundation (CM workflow, basic traceability)
3. Week 5-8: Quality practices (test coverage, peer reviews, ADRs)
4. Week 9-12: Measurement (metrics collection, baselines)
5. Month 4+: Refinement (Level 3 enhancements, continuous improvement)

Quick Wins vs. Foundational Practices

Quick Wins (implement first - immediate value):

| Practice | Time to Implement | Value | |----------|------------------|-------| | Branch protection rules | 30 minutes | Prevents force pushes, lost work | | PR review requirement | 1 hour | Catches bugs before merge | | Issue templates | 2 hours | Structured requirement capture | | CI/CD basic pipeline | 1 day | Automated testing, faster feedback | | ADR template | 1 hour | Decision documentation starts |

Foundational Practices (implement second - enables maturity):

| Practice | Time to Implement | Enables | |----------|------------------|---------| | Requirements traceability | 1-2 weeks | Audit trail, impact analysis | | Branching workflow (GitFlow/Trunk) | 1 week + training | Release management, parallel dev | | Test coverage baseline | 2-3 weeks | Quality metrics, regression prevention | | Metrics collection | 2-4 weeks | Baselines, trend analysis, process improvement | | Risk register | 1 week | Proactive risk management |

Strategy: Lead with quick wins to demonstrate value, then invest in foundations while team is bought in.

Team Size Adaptations

2-3 Person Team (Minimal Viable CMMI):

• Target: Level 2 (Managed)
• REQM: GitHub Issues as requirements
• CM: Feature branches + PR review (both review each other)
• VER: Automated tests only, no formal test plan
• Documentation: Minimal (ADRs for major decisions, no formal specs)
• Effort: 5% of project time on process

4-10 Person Team (Sweet Spot):

• Target: Level 3 (Defined)
• REQM: Work items with acceptance criteria, RTM via tool
• CM: GitFlow or GitHub Flow, 2 reviewers required
• VER: Test coverage >80%, formal peer review checklist
• Documentation: Standard templates, comprehensive ADRs
• Effort: 10-15% of project time on process

11-30 Person Team (Organizational Standard):

• Target: Level 3 → Level 4
• REQM: Requirements templates, formal elicitation
• CM: Branching strategy document, release management
• VER: Test plans (IEEE 829), defect density tracking
• Documentation: Architecture review board, design reviews
• Effort: 15-20% of project time on process

30+ Person Team (Full CMMI):

• Target: Level 4 (Quantitatively Managed)
• All Level 3 practices +
• Metrics: Statistical process control, baselines, prediction models
• Roles: Dedicated process owner, metrics analyst
• Effort: 20-25% of project time on process

Small Team Enforcement (2-4 Person Teams)

Problem: Small teams lack independent oversight (no tech lead, no manager, no external review). Under deadline pressure, teams can exploit this to appear compliant while avoiding actual work.

Solution: See Enforcement Mechanisms #16-20 (Small Team Enforcement section) for detailed enforcement strategies including:

• External review requirement
• Written requirements mandate
• ADR timing verification
• Solo emergency protocol
• Admin bypass audit

These mechanisms require external verification (advisor, consultant, or automation) since small teams cannot self-police.

When NOT to Retrofit Everything

Selective Retrofitting Principle: Not all legacy code needs full CMMI compliance.

DO retrofit:

• ✅ Critical path features (security, payment processing, data integrity)
• ✅ High-change areas (frequent bugs, ongoing development)
• ✅ Audit-required components (regulated functionality)
• ✅ New features (all new work follows new process)

DON'T retrofit:

• ❌ Stable, low-risk code (hasn't changed in 6+ months)
• ❌ Deprecated features (scheduled for removal)
• ❌ Prototypes and throwaway code
• ❌ Well-tested legacy code with no known issues

Risk-Based Decision Matrix:

High Change Frequency │ RETROFIT    │ RETROFIT    │
                      │ (Full)      │ (Selective) │
─────────────────────┼─────────────┼─────────────┤
Low Change Frequency  │ RETROFIT    │ EXEMPT      │
                      │ (Critical)  │             │
                      └─────────────┴─────────────┘
                        High Risk     Low Risk

Example: 100 features shipped over 2 years

• 10 critical features (payment, auth, data sync) → Full retrofit (requirements, tests, ADRs)
• 30 active features (ongoing development) → Selective retrofit (traceability only)
• 60 stable features (no changes in 6+ months) → Exempt (document as legacy)

Time savings: Retrofitting 40 features instead of 100 = 60% effort reduction

CRITICAL: Exemption List Approval Gate

Enforcement: CTO or security officer MUST approve exemption list before Week 4. This prevents managers from classifying everything as "low risk" to avoid retrofit work.

Approval requirements:

• [ ] Exemption list documented with rationale (feature name, why exempt, risk assessment)
• [ ] For each exempted feature: Must justify BOTH "low change frequency" AND "low risk"
• [ ] If feature handles ANY of these → Cannot be exempt without security officer approval:
  • Protected Health Information (PHI) / Personally Identifiable Information (PII)
  • Authentication or authorization
  • Payment processing
  • Audit logging
  • Encryption/decryption
• [ ] CTO sign-off required if >80% of features classified as "exempt"

Red flags requiring escalation to executive sponsor:

• 80% of features labeled "exempt" → Gaming detected

• All authentication features labeled "low risk" → Security misunderstanding
• Features with known vulnerabilities labeled "exempt" → Compliance violation

Accountability:

• Team lead must present exemption list with evidence to CTO in Week 4 review
• CTO spot-checks 10 random "exempt" features to verify classification accuracy
• If classification gaming detected → Restart with proper risk assessment

Example compliant exemption:

Feature: Legacy report generator (reports.py)
- Last changed: 18 months ago
- Risk: Low (read-only, no PII, no auth)
- Change frequency: Zero changes in 12+ months
- Status: EXEMPT (approved by CTO 2026-01-24)

Example non-compliant exemption:

Feature: User login endpoint (auth.py)
- Risk claimed: "Low"
- Reality: HIGH (authentication is always high risk)
- Status: CANNOT EXEMPT (handles auth → must retrofit)

Common Objections and Responses

Objection 1: "CMMI will slow us down"

Response:

• Acknowledge: "Poorly implemented process DOES slow teams down. Let's avoid that."
• Show lightweight Level 2 approach (not bureaucracy)
• Quick wins demonstrate value: "Branch protection prevented 3 lost-work incidents this month"
• Data: Teams with code review find bugs 60% faster than those without (Microsoft Research)

Objection 2: "We're too small for CMMI"

Response:

• Level 2 works for 2-person teams (see Team Size Adaptations above)
• GitHub Issues + PR reviews + ADRs = minimal overhead, maximum audit trail
• Automation reduces burden (GitHub Actions, not manual checklists)
• Small teams benefit MORE from process (no redundancy to catch errors)

Objection 3: "We're agile, CMMI is waterfall"

Response:

• CMMI is methodology-agnostic (works with Scrum, Kanban, XP)
• Map CMMI to sprints: REQM in planning, VER in reviews, VAL in demos
• User stories = requirements, ADRs = design, sprint retro = process improvement
• See prescription Section 6.2 for Agile workflow mapping

Objection 4: "It's too late to change mid-project"

Response:

• Parallel tracks mean you don't change existing code
• New features follow new process starting TODAY
• Retrofitting is selective (critical paths only)
• 2-3 month transition is feasible even on 2-year-old projects

Objection 5: "We don't have time for this"

Response:

• Time pressure is exactly why you need process (reduce rework, catch bugs early)
• Quick wins (branch protection, PR reviews) take <1 day to implement
• ROI calculation: 1 hour of code review saves 5 hours of debugging (industry average)
• Audit failure costs MORE time than incremental adoption

Red Flags: Thoughts That Mean "STOP"

If you or the user are thinking these thoughts, STOP and reconsider:

| Thought | Reality | What to Do Instead | |---------|---------|-------------------| | "Let's do a big bang rollout" | 95% failure rate for big bang CMMI adoption | Use parallel tracks: new work follows new process, old code exempt | | "We'll retrofit everything before starting new work" | Analysis paralysis, development freeze | Selective retrofit (30% critical features), parallel new development | | "We're too small for CMMI" | 2-person teams can do Level 2 in 1 week | Show team size adaptation table (Level 2 = minimal viable) | | "CMMI = waterfall, we're agile" | CMMI is methodology-agnostic | Map CMMI to sprint ceremonies (RD in planning, VER in review) | | "Let's wait until the project is done" | Post-hoc compliance is 10x harder | Start now with parallel tracks, minimal disruption | | "We need perfect compliance from day one" | Perfectionism kills adoption | Incremental: 30% → 50% → 70% compliance over 3 months | | "Process first, then demonstrate value" | Team will revolt before seeing benefits | Quick wins first (branch protection Day 1), then deeper practices | | "Everyone must follow the same process" | One-size-fits-all fails | Tailoring by team size, risk, and domain | | "We'll add tests after the feature is done" | "Later" = never | Require tests for all new code NOW, retrofit selectively | | "Management just needs to mandate it" | Top-down mandates create cargo cult compliance | Involve team in process design, demonstrate value, then enforce |

Rationalization Table

Common rationalizations that undermine adoption (and how to counter them):

| Rationalization | Pattern | Counter | |----------------|---------|---------| | "Just this once we'll skip [practice]" | Slippery slope | "Just this once" becomes "every time". Enforce consistently from Day 1. | | "We're in a hurry, no time for [practice]" | Time pressure override | "Hurry is why we NEED process. Skipping reviews = 5x more debugging time later." | | "This feature is too small for [practice]" | Scope minimization | "Small changes cause big bugs. All features follow process, no exceptions." | | "The process is slowing us down" | Productivity panic | "Initial 10% slowdown, long-term 30% speedup. Measure before/after." | | "We already do code review informally" | Informal = good enough | "Informal = inconsistent. 8 of last 10 PRs had no review (check GitHub)." | | "Our team is experienced, we don't make mistakes" | Overconfidence | "Last month: 12 production bugs. Experience ≠ infallibility." | | "We'll fix the process later" | Procrastination | "Process debt compounds like technical debt. Fix now or pay 10x later." | | "The audit is months away" | Distant deadline | "Process takes 2-3 months to stabilize. Start now or fail audit." | | "Let's use our own process, not CMMI" | Not invented here | "Your process likely duplicates CMMI. Map it, fill gaps, save time." | | "We need to finish this sprint first" | Perpetual deferral | "Every sprint will have 'just one more thing'. Parallel tracks start TODAY." | | "This is too bureaucratic" | Fear of overhead | "Level 2 = branch protection + PR template. That's not bureaucracy." | | "Our old process worked fine" | Status quo bias | "13 bugs last quarter, 45% of time on rework. That's not 'fine'." |

How to use this table:

• When user or team member says a rationalization, identify the pattern
• Respond with the counter (data-driven, not defensive)
• Redirect to the appropriate reference sheet for concrete guidance

Enforcement Mechanisms

Purpose: Prevent common loophole exploits discovered through TDD adversarial testing. These 19 mechanisms close rationalizations teams use under pressure.

Organization:

• Adoption & Progression (#1-5): Emergency bypass, progression gates, workshops, parallel tracks, early adopters
• Requirements & Design (#6-10): Depth, validation, coverage, traceability, discovery
• Code Review (#11-12): Risk assessment, quality standards
• Small Teams (#13-17): External review, written docs, timing, emergencies, admin access
• Git Security (#18-19): Fork attacks, branch protection

---

Adoption & Progression

1. Emergency Bypass Process

Prevents: "Just this once" excuse for skipping process

Enforcement:

• Emergency hotfixes STILL require 1 reviewer (4-hour async SLA)
• Tag commit emergency-bypass
• Post-hoc documentation within 24 hours
• Monthly review: >2/month = process problem

Red flag: >2 emergencies/month

2. Progression Gates (Consolidated)

Prevents: Eternal quick-wins loop, permanent plateau

Enforcement:

• Week 2: Quick wins complete (branch protection, templates, 1+ bug caught)
• Week 4: Foundations started (50% traceability, 3+ ADRs, workflow documented)
• Week 8: Quality active (test coverage >60%, 100% PRs reviewed)
• Week 12: Measurement established (dashboard live, baselines calculated)
• Gate failure → CTO intervention required

Red flag: Still at quick wins in Month 3 → escalate

3. Workshop Quality Standards

Prevents: Workshop theater (checkbox attendance without engagement)

Enforcement:

• 70% active participation (documented contributions)
• 2+ alternative approaches documented
• Post-workshop survey (70% comprehension, 50% buy-in)
• Artifacts: attendance, brainstorm notes, voting results
• CTO reviews artifacts Week 2

Red flag: <50% felt they could influence → repeat workshop

4. Parallel Tracks Deadline

Prevents: Indefinite legacy exemption

Enforcement:

• Hard cutoff Month 2: ALL new work follows process
• Bug fix = <50 LOC change only
• Tech lead classifies work (not self-reported)
• Monthly audit: >50% "legacy" in Month 3 = gaming

Red flag: Work started Week 7 claimed as "legacy"

5. Early Adopter Credibility

Prevents: Junior dev pilot theater

Enforcement:

• 1 year tenure required

• Team validates influence ("Who do you respect?")
• Scaling metrics: Week 4 (2-3 people), Week 8 (50%), Week 12 (80%)
• CTO reviews Month 2

Red flag: Pilot confined to 1-2 people Week 8

---

Requirements & Design

6. Requirement Depth Standards

Prevents: Shallow requirements speed run

Enforcement:

• 6-12 requirements per moderate feature minimum
• Tech lead reviews 20% sample
• Reject if average <5 requirements/feature
• Time calibration: 4-8 hours per feature (not negotiable)

Red flag: 5+ feature retrofits per day

7. Stakeholder Validation Enforcement

Prevents: "Pending validation" indefinite deferral

Enforcement:

• 3 documented contact attempts required
• Escalation path to executive
• NO "pending" acceptable for audits
• Proxy validation allowed with documentation

Red flag: >10% "pending" at Week 4

8. Level 2 vs 3 Coverage Clarification

Prevents: 30% escape hatch abuse

Enforcement:

• Determine audit level Week 0 (ask auditor)
• Level 2: 30-40% of CRITICAL features
• Level 3: 80-100% of ALL features
• Auditor decides scope, not PM

Red flag: PM unilaterally claims "Level 2"

9. Tool-Based RTM Requirement

Prevents: Spreadsheet escape hatch at Level 3

Enforcement:

• Level 2: Spreadsheet acceptable
• Level 3: GitHub/ADO required (not spreadsheet)
• Migration timeline: Weeks 1-2 spreadsheet, Weeks 3-4 migrate, Week 5+ tool only

Red flag: Spreadsheet still used Month 2 for Level 3

10. Dark Matter Feature Detection

Prevents: Hiding undocumented features from audit

Enforcement:

• 4-way verification: code analysis, routes, UI audit, stakeholder memory
• Cross-validate lists for discrepancies
• External reviewer spot-checks 10 random code sections

Red flag: Feature count suspiciously low for LOC

---

Code Review

11. Risk Assessment Authority

Prevents: Risk-labeling game (self-declaring "low risk")

Enforcement:

• Objective criteria: PII/Money/Auth = HIGH (non-negotiable)
• 2-person sign-off required for risk classification
• Security team approval to downgrade

Red flag: >80% features labeled "low risk"

12. Review Quality Standards

Prevents: Rubber-stamp theater

Enforcement:

• Minimum 5 min per 100 LOC
• Substantive comment required (not just "LGTM")
• <2 min reviews flagged
• Monthly audit: 10% spot-check

• 20% rubber stamps → lose approval privileges 1 month

Red flag: 100% compliance, 0 bugs caught for 4+ weeks

---

Small Team Enforcement (2-4 person teams)

13. External Review Requirement

Prevents: Rubber-stamp between friends

Enforcement:

• Quarterly external review (10% of PRs)
• Automation BLOCKS <5 min/100 LOC reviews
• Monthly self-audit required

Accountability: External reviewer reports to executive

14. Written Requirements Mandate

Prevents: Verbal-only work

Enforcement:

• Issue MUST exist BEFORE PR created
• Timestamp verification (Issue date < PR date)
• GitHub Action blocks PRs without linked issue

Red flag: >20% Issues created within 1 hour of PR

15. ADR Timing Verification

Prevents: Backdating architectural decisions

Enforcement:

• ADR commit MUST precede implementation commits
• Git timestamp verification (automated check)
• Limit: 2 retroactive ADRs/quarter

Verification: git log --format=%ai -- docs/adr/ vs implementation commits

16. Solo Emergency Protocol

Prevents: Skipping review when partner unavailable

Enforcement:

• Preferred: 4-hour async review (phone acceptable)
• If truly solo: merge with emergency-solo tag, external review within 48 hours
• Limit: 1 solo emergency/quarter

Red flag: >4 solo emergencies/year

17. Admin Bypass Audit

Prevents: GitHub admin bypass enabled

Enforcement:

• Weekly GitHub Action verifies "enforce_admins=true"
• Screenshot required for quarterly review
• Separation of duties: external admin OR weekly automation

Verification: gh api repos/{owner}/{repo}/branches/main/protection | jq '.enforce_admins.enabled'

---

Git Workflow Security

18. Fork Security Configuration

Prevents: Fork-based bypass attack

Enforcement:

• GitHub: "Restrict who can push to matching branches" enabled
• "Require linear history" enabled
• Weekly audit for force-push attempts
• Monthly manual audit of protection changes

Red flag: Multiple failed force-push attempts

19. Emergency Hotfix Enforcement

Prevents: Disabling branch protection

Enforcement:

• Emergency does NOT mean disable protection
• 8-step process: hotfix branch → PR → 4-hour review → merge via protection
• Real-time webhook alerts if protection disabled
• Auto-remediation every 6 hours
• Mandatory post-mortem if disabled

Red flag: Protection disabled >1 hour

---

Reference Sheets

The following reference sheets provide detailed, step-by-step guidance for specific adoption scenarios. Each reference is a separate file - load on-demand when needed.

1. Maturity Assessment (maturity-assessment.md)

When to load: Starting adoption, gap analysis, determining Level 2/3/4 fit, audit preparation

Assess current CMMI maturity level, identify gaps, prioritize improvements using:

• Process area scoring rubric (11 CMMI process areas)
• Evidence-based assessment templates
• Risk-based gap prioritization matrix (quick wins vs. foundational practices)

Provides: Scoring method, assessment templates, prioritization framework, tool integration patterns

Load reference: See maturity-assessment.md for complete assessment process.

---

2. Incremental Adoption Roadmap (adoption-roadmap.md)

When to load: Planning phased rollout, pilot project strategy, scaling practices organization-wide

12-week incremental adoption roadmap with:

• Week-by-week milestones for Level 2/3/4
• Pilot project approach (start small, scale success)
• Parallel tracks timeline (new work = new process)
• Team size adaptations (2-person to 50+ person teams)

Provides: Weekly implementation plans, pilot selection criteria, scaling strategies, rollout timelines

Load reference: See adoption-roadmap.md for complete phased rollout guidance.

---

3. Retrofitting Requirements (retrofitting-requirements.md)

When to load: Adding requirements traceability to existing features, documenting undocumented code

Add RD + REQM practices to existing codebase without rewriting:

• Dark matter feature detection (find undocumented features)
• Reverse-engineering requirements from code
• Progressive traceability (start with critical paths)
• Stakeholder validation for legacy features

Provides: Retrofitting workflow, traceability templates, GitHub/Azure DevOps implementation patterns

Load reference: See retrofitting-requirements.md for complete retrofitting process.

---

4. Retrofitting Configuration Management (retrofitting-cm.md)

When to load: Adopting branching strategies mid-project, adding version control discipline, migrating platforms

Add CM practices to existing project without disrupting active development:

• Branch strategy migration (trunk-based → GitFlow → release branches)
• Grandfathering existing violations (future-only enforcement)
• Tag/release strategy for untagged history
• Migration workflows (SVN → Git, Git → Monorepo)

Provides: Migration playbooks, branch protection rules, release process templates, rollback procedures

Load reference: See retrofitting-cm.md for complete CM retrofitting guidance.

---

5. Retrofitting Quality Practices (retrofitting-quality.md)

When to load: Adding tests and code reviews to legacy code, implementing VER + VAL practices

Add testing and review practices without "test everything first":

• Progressive test coverage (new code first, then critical paths)
• Characterization tests for legacy code
• Code review policy adoption (future PRs only)
• Validation criteria for existing features

Provides: Test retrofitting strategies, review policy templates, coverage targeting, validation workflows

Load reference: See retrofitting-quality.md for complete quality retrofitting process.

---

6. Retrofitting Measurement (retrofitting-measurement.md)

When to load: Establishing metrics without historical data, adding MA + QPM + OPP practices

Create baselines and measurement programs when starting from zero:

• Establishing baselines without history (use industry benchmarks)
• Metric selection for Level 2/3/4
• Automated data collection (GitHub API, Azure DevOps Analytics)
• Statistical baselines and control limits (Level 4)

Provides: Metric definitions, baseline establishment methods, dashboard templates, SPC implementation

Load reference: See retrofitting-measurement.md for complete measurement retrofitting guidance.

---

7. Managing the Transition (managing-transition.md)

When to load: Tool migrations, platform changes, maintaining compliance during parallel operations

Maintain CMMI compliance while changing tools/platforms:

• Parallel operations (old + new systems simultaneously)
• GitHub ↔ Azure DevOps migration patterns
• Preserving traceability during migration
• Compliance continuity strategies

Provides: Migration playbooks, parallel operation procedures, traceability preservation, rollback plans

Load reference: See managing-transition.md for complete transition management guidance.

---

8. Change Management (change-management.md)

When to load: Team resistance, executive skepticism, demonstrating ROI, building buy-in

Overcome organizational resistance and build support for CMMI adoption:

• Countering "process = overhead" objections (with data)
• Demonstrating quick wins (velocity improvement, bug reduction)
• Executive sponsorship strategies
• Team buy-in through incremental value delivery

Provides: Objection handling scripts, ROI calculations, stakeholder communication templates, success metrics

Load reference: See change-management.md for complete change management guidance.

---

Loading Reference Sheets

How to access:

"I need detailed guidance on [topic]"
→ Load the appropriate reference sheet from the list above

When you need a reference:

• Be specific about which aspect you need ("gap analysis process" → maturity-assessment)
• References are comprehensive (250-550 lines each)
• Each reference is self-contained with templates and examples

Cross-references: Reference sheets link to each other when practices overlap (e.g., retrofitting requirements references maturity assessment for prioritization).