lifecycle-adoption

Use when starting new projects with CMMI, adding CMMI to active development, preparing for audits, migrating tools, or facing team resistance to process adoption

SKILL.md

GitHub

Lifecycle Adoption

Adopt only controls with a named purpose and owner. Maturity labels are not evidence and the default is not Level 3.

Workflow

  1. Read the organization's actual policy, obligations, current delivery records and pain points. Identify scope, baseline and evidence consumers.
  2. Assess controls with examples from real work: present/effective, present/unverified, absent, or not applicable. Distinguish observed practice from intended policy.
  3. Prioritize gaps by demonstrated consequence, dependencies and cost. Pilot the smallest change that can test the expected benefit.
  4. Preserve active delivery and custody: requirements, configuration, branches/releases, tests, decision records and measurement definitions need clear owners during transition.
  5. Introduce only required artifacts; use existing tracker/repository records where they contain the evidence. Characterize important existing behavior before risky refactoring.
  6. Evaluate the pilot against outcomes and burden, then expand, adjust or retire controls. A fast clean review can be valid; do not require hours, comments or arbitrary requirement counts.

Evidence

A tailored adoption note names policy/version, baseline evidence, gap/consequence, proposed change, owner, acceptance/check, transition risk and review trigger. No universal schedules, ROI claims or reviewer quotas apply.

Optional references

Assessment, roadmap, change, transition, requirements, configuration, quality, measurement.

Working contract

Use the smallest deliverable that makes the decision or change reviewable. Existing project records can satisfy these fields; do not create duplicate documents. Read only references needed for the unresolved question. Ordinary work does not require loading a specialist, delegating, or asking a routing question.

Use tools and current project evidence where available. Distinguish observed facts, inferences and unknowns. Report material findings with a source, consequence and proposed action; report a supported clean result when appropriate. State checks run, checks omitted and residual uncertainty without mandatory report sections. Honor current user authorization and applicable project policy; ask only when a missing decision materially blocks progress.