* feat: add research-grounded technical project management skill * test: retain isolated project coordination regression evidence
3.9 KiB
Research brief and coverage map
Purpose and plan
Build a technical project management methodology for teams without a dedicated PM and experienced TPMs. Own the continuous management loop from initiation through closure. Preserve existing specialists' ownership of detailed implementation planning, product choices, flow design, engineering, and release mechanics.
Implementation sequence: research primary guidance and cases; map ownership; write conditional references and reusable artifacts; add a bounded schedule analysis tool; exercise difficult scenarios and script edge cases; validate the catalog; publish and review the change. No claim of superior delivery outcomes follows merely from shipping this bundle.
Research method
Sources were inspected on 2026-09-05. Prefer framework owners for definitions, independent audits for failure findings, and first-person engineering accounts for operating details. Check edition and distinguish event date from publication date. Do not count search snippets as full-report review. The source index identifies exact sections inspected and evidence limitations. Original procedures and templates are this repository's synthesis, not quotations or claims of certified compliance.
The initial 2020 GAO Agile exposure draft was superseded in this research by the 2023 revised guide. Standards for government apply within their jurisdiction; transferable practices do not make their requirements universal.
Coverage and ownership
| Need | This skill owns | Specialist boundary |
|---|---|---|
| Starting or inheriting a project | Mandate, authority, uncertainty, baseline discovery | Product discovery validates the problem; implementation planning requires approved input |
| Choosing a method | Fit, adaptation, coordination across methods | Kanban guru owns detailed flow design; product shaping owns Shape Up shaping |
| Execution | Milestone evidence, commitments, issues, decisions, scope changes | Engineering specialists implement; Jira/Linear operate systems |
| Forecasting | Model choice, assumptions, resource feasibility, forecast versus promise | Implementation planning owns the detailed dependency plan |
| Governance | Project tolerances and escalation | Product governance and executive strategy retain their own authority |
| Closure | Acceptance, residual owners, operational handoff, benefit review | Production readiness owns launch evidence; lifecycle learning owns outcome reviews |
Evidence-driven design decisions
- Keep governance separate from delivery cadence (GovS 002, PMI tailoring).
- Require observable progress and current remaining work, not optimistic color labels (GAO Healthcare.gov findings).
- Treat interfaces and escalation as management work (NASA MCO review).
- Track readiness and coordination before production dates (GitHub upgrade case).
- Include transition to ongoing service, not only shipping (GOV.UK case).
- Protect team accountabilities when adding coordination (Scrum Guide).
- Do not promise that any branded method is universally faster (PMI evidence is contextual; practitioner accounts are not controlled comparisons).
Acceptance and limitations
Acceptance requires a thin entry point, reachable references, useful templates, valid output-quality evals, tests for any bundled executable, source-to-practice traceability, and passing repository checks. Behavioral tests must distinguish actual outputs from expected outcomes and record revision and limitations.
Cases deliberately include public and private organizations, failures and reported successes. They are not a representative sample. Small volunteer teams, early-stage startups, and high-uncertainty AI research are covered by labeled adaptations and scenario tests, not invented field evidence. Expand the case library when credible first-person artifacts become available. Do not label the skill "world-class" as an established result of structural validation.