Files
magnus919_agent-skills/technical-project-management/references/engagement-and-initiation.md
Magnus HedemarkandGitHub 22d141de75 feat: add research-grounded technical project management skill (#468)
* feat: add research-grounded technical project management skill

* test: retain isolated project coordination regression evidence
2026-09-04 23:56:40 -04:00

3.5 KiB

Engagement and initiation

Use for a new project, inherited project, missing PM role, or unclear mandate. Basis: S06 establishes proportionate governance and explicit accountability. The interaction and triage sequence below is original application.

Start where the user is

Read the brief, current plan, most recent status, decisions, and authoritative tracker before interviewing people. Identify which sources are current and who can resolve contradictions. Ask only questions that change the immediate decision. Do not demand a complete charter before helping with a blocking dependency. Preserve the existing board. Do not assign a per-person WIP limit or redesign workflow columns without a flow diagnosis; route that work to kanban-guru.

Context First useful output Avoid
Team without PM One-page outcome/ownership brief, next milestone, short blocker list Certification jargon or a meeting-heavy PMO
Practicing TPM Changes since last review, critical assumptions, options and recommendation Definitions of terms they already use
Inherited project Evidence inventory and disputed commitments Treating last week's green report as the baseline truth
Unapproved idea Discovery questions and an options/authorization brief An execution schedule masquerading as a harmless draft

For expert requests, use the user's requested format and decision horizon. Give feedback that improves their judgment: show the missing dependency, weak evidence, or tradeoff, and its consequence. Offer explanation only where the reasoning is non-obvious or requested. Do not label the person a novice based on job title.

Establish the minimum project contract

Capture outcome and acceptance authority; included and excluded scope; business reason; hard versus negotiable constraints; known capacity and skills; external interfaces; source of funding; decision rights; and the next decision date. Distinguish an actual deadline from a desired date and record its source.

A small team can combine sponsor, delivery coordinator, and technical lead roles, but name which decisions each role can make. A coordinator does not acquire architecture, budget, product-priority, or risk-acceptance authority by tracking work. Get explicit acceptance for new commitments, not merely a name in a table.

Use the project-brief template only to fill real gaps. Link existing approval records instead of recreating them. Unanswered fields remain unknown with a proposed owner and evidence request. Proposed owners are not accepted owners.

Inheriting unreliable records

  1. Save the stated baseline and source date; do not overwrite history.
  2. Separate accepted deliverables from claimed percentages and open work.
  3. Compare tracker records with integration evidence and receiving-team acceptance.
  4. Identify the earliest consequential decision: funding, vendor commitment, launch date, or safety concern.
  5. Issue a provisional health assessment with evidence gaps and a short recovery investigation; prioritize gaps that could reverse that decision.

For a volunteer or part-time team, ask about sustainable availability and absence coverage. Do not convert headcount into full-time capacity. For distributed teams, record working calendars and the latency of cross-time-zone decisions.

Exit

The immediate decision, authoritative sources, current mandate, and owner of each material gap are visible. Stop setup when these are adequate. Missing approval blocks commitments and execution authorization, not read-only diagnosis.