technical-program-management

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Technical Program Management

技术项目集管理

Program-level control can fail even when every component is on its own track. Use this skill to see and manage the seams, not to replace project managers or product governance.

即使每个组成部分都在各自轨道上正常推进，项目集层面的控制仍可能失败。使用此 skill 识别并管理各组成部分之间的衔接点，而不是取代项目经理或产品治理。

First move: prove the program boundary

第一步：验证项目集边界

A program is not a larger project: it exists because coordination, shared constraints, or benefits across components require decisions that no component owner can make alone.

Read existing strategy, business case, component plans, dependency records, benefits assumptions, and recent status evidence before creating ceremony. Establish:

the shared outcome and why the components belong together;
the senior accountable owner and program decision rights;
component projects/workstreams, owners, interfaces, and operational recipients;
expected benefits, benefit owners, measures, baselines, timing, and disbenefits;
shared capacity, funding, architecture, vendors, environments, and policy constraints;
the current phase, critical decision, evidence gaps, and stop/revisit conditions.

If the work is one bounded project, route to technical-project-management. If the work is only a collection of unrelated investments, route to product-roadmapping-and-portfolio or strategy-frameworks.

项目集并非更大的项目：之所以成立，是因为跨组成部分的协调、共享约束或收益，需要作出任何单个组成部分负责人都无法独立作出的决策。

在建立额外管理机制之前，先阅读现有战略、业务论证、组成部分计划、依赖关系记录、收益假设和近期状态证据。明确：

共同结果，以及各组成部分为何需要归入同一项目集；
承担最终责任的高级负责人及项目集决策权；
组成项目或工作流、负责人、接口和运营接收方；
预期收益、收益负责人、衡量指标、基线、时间安排和负收益（disbenefits）；
共享资源容量、资金、架构、供应商、环境和政策约束；
当前阶段、关键决策、证据缺口，以及停止或重新评估的条件。

如果工作仅涉及一个有明确边界的项目，请转交 technical-project-management。如果工作只是一组互不相关的投资，请转交 product-roadmapping-and-portfolio 或 strategy-frameworks。

Reference routing

参考文档路由

Read only what the current decision requires:

Situation	Read
Program mandate, component map, or shared constraints	Program brief template
Integrated status, dependency, risk, or recovery problem	Program control and troubleshooting
Benefits, governance, or evidence boundary	Research ledger
Benefits dependency mapping, tranche decisions, or disbenefits	Benefits dependency and tranche control
Adoption, operating-model change, or benefit drift	Benefits and transformation
Integrated control record needs filling	Integrated control template
Audience-specific status or decision update	Stakeholder update template
Independent assurance or troubled-program intervention	Assurance and intervention
One project needs detailed control	technical-project-management
Product portfolio or capital-allocation choice	product-roadmapping-and-portfolio or strategy-frameworks

仅阅读当前决策所需的内容：

情况	阅读内容
项目集任务授权、组成部分图谱或共享约束	项目集简报模板
整合状态、依赖关系、风险或恢复问题	项目集控制与故障排查
收益、治理或证据边界	研究证据台账
收益依赖映射、分批次决策或负收益	收益依赖与分批次控制
采用、运营模式变革或收益偏移	收益与转型
需要填写整合控制记录	整合控制模板
面向特定受众的状态或决策更新	干系人更新模板
独立鉴证或问题项目集干预	鉴证与干预
单个项目需要详细控制	technical-project-management
产品组合或资本配置选择	product-roadmapping-and-portfolio 或 strategy-frameworks

Routing to adjacent skills

相邻 skill 路由

For a single bounded project's milestones, forecasts, dependencies, recovery, or closure, use technical-project-management.
For product roadmap and portfolio sequencing, use product-roadmapping-and-portfolio.
For recurring product decision rights and product governance, use product-operations-and-governance.
For enterprise target-state architecture or architecture governance, use enterprise-architecture.
For approved work breakdown and detailed rollout planning, use implementation-planning.

对于单个有边界项目的里程碑、预测、依赖关系、恢复或收尾，使用 technical-project-management。
对于产品路线图和组合排序，使用 product-roadmapping-and-portfolio。
对于常规产品决策权和产品治理，使用 product-operations-and-governance。
对于企业目标状态架构或架构治理，使用 enterprise-architecture。
对于已批准的工作分解和详细落地规划，使用 implementation-planning。

Program operating loop

项目集运营循环

Mandate. Confirm the outcome, component boundaries, authority, funding horizon, success measures, and assumptions. Do not convert a strategic aspiration into an approved program without an accountable sponsor.
Shape the architecture of work. Define component charters, interfaces, shared milestones, integration evidence, decision rights, and escalation paths. Preserve each component's appropriate delivery method; coordinate outcomes, not ceremonies.
Build the integrated view. Maintain one program control record containing dependency health, integrated milestones, shared-capacity conflicts, benefits, risks/issues, decisions, forecasts, and changes. Link to component records rather than copying them.
Manage the seams. Review cross-project dependencies by provider, receiver, definition of ready, acceptance evidence, needed-by date, fallback, and escalation owner. A component marked green does not make an unmet program dependency green.
Steer by evidence. Compare actuals and forecasts with the program baseline and benefits hypothesis. Surface variance, confidence loss, benefit drift, and emerging disbenefits immediately. Missing evidence is unknown, not green.
Make trade-offs. Present options across scope, sequence, capacity, funding, quality, risk, adoption, and benefits. A local optimization that harms the shared outcome is a program issue. Preserve history when the mandate or baseline changes.
Realize and transition. Coordinate adoption, operating-model change, capability transfer, and benefits measurement. Use Benefits dependency and tranche control when components must produce a shared benefit in stages. Use Assurance and intervention when evidence, governance, or the integrated outcome is materially disputed or off track. Close or reshape the program only when the outcome decision, residual ownership, operational handoff, and benefits follow-up are explicit.

任务授权（Mandate）。 确认结果、组成部分边界、权限、资金周期、成功衡量指标和假设。在没有承担问责的发起人时，不要将战略愿景转化为已批准的项目集。
塑造工作架构。 定义组成部分章程、接口、共享里程碑、集成证据、决策权和升级路径。保留各组成部分适合的交付方式；协调的是结果，而非形式化流程。
建立整合视图。 维护一份项目集控制记录，其中包含依赖关系健康度、整合里程碑、共享资源容量冲突、收益、风险与问题、决策、预测和变更。链接至组成部分记录，而不是复制这些记录。
管理衔接点。 按提供方、接收方、就绪定义（definition of ready）、验收证据、需求日期、备选方案和升级负责人审查跨项目依赖关系。某个组成部分被标记为绿灯，并不意味着尚未满足的项目集依赖关系也变成了绿灯。
以证据引导决策。 将实际值和预测与项目集基线及收益假设进行比较。立即暴露偏差、置信度下降、收益偏移和新出现的负收益。缺失证据意味着未知，而不是绿灯。
作出权衡。 围绕范围、顺序、资源容量、资金、质量、风险、采用和收益呈现各种选项。损害共同结果的局部优化就是项目集问题。当任务授权或基线发生变化时，应保留历史记录。
落实与转型。 协调采用、运营模式变革、能力移交和收益衡量。当组成部分必须分阶段产生共同收益时，使用收益依赖与分批次控制。当证据、治理或整合结果存在重大争议或严重偏离时，使用鉴证与干预。只有在结果决策、剩余责任归属、运营移交和后续收益跟踪均明确时，才能关闭或重塑项目集。

Method selection

方法选择

Use the smallest adequate program model. Keep governance separate from component cadence.

Conditions	Program pattern	First test
Stable outcome, fixed external gates, staged component delivery	Predictive/stage-governed program	Are component interfaces and decision gates feasible with real capacity?
Uncertain solution or benefits, learning must change the roadmap	Iterative/adaptive program	Is there an evidence checkpoint that can change funding or scope?
Many products or teams release increments into one capability	Incremental/release-train coordination	Is each increment usable and does integration evidence accumulate?
High dependency density and shared specialists	Flow/network coordination	Are dependency aging, capacity contention, and escalation visible?
Mixed hardware, software, vendor, regulatory, or organizational change	Hybrid program	Is one integrated decision view connecting the different cadences?

Do not prescribe a branded method because the program uses multiple teams. Explain the trade-off, authority, cadence, evidence, and revisit trigger. A program manager coordinates; they do not acquire component owners' architecture, product, engineering, or risk-acceptance authority by tracking their work.

使用满足需求的最精简项目集模型。将治理与组成部分的运行节奏分开。

条件	项目集模式	首个检验问题
结果稳定、外部关卡固定、组成部分分阶段交付	预测型或阶段门控项目集	在真实资源容量下，组成部分接口和决策关卡是否可行？
解决方案或收益不确定，学习结果必须改变路线图	迭代型或自适应项目集	是否存在能够改变资金或范围的证据检查点？

多个产品或团队将增量发布到同一项能力中 | 增量或发布列车（release train）协调 | 每个增量是否可用，集成证据是否不断累积？ | | 依赖关系密集且共享专业人员较多 | 流动（flow）或网络协调 | 依赖关系老化、资源容量争用和升级情况是否清晰可见？ | | 硬件、软件、供应商、监管或组织变革混合存在 | 混合型项目集 | 是否存在一个连接不同运行节奏的整合决策视图？ |

不要仅因为项目集涉及多个团队，就直接套用某个品牌化方法。应说明权衡、权限、节奏、证据和重新评估的触发条件。项目集经理负责协调；他们不会因为追踪工作而取得组成部分负责人的架构、产品、工程或风险接受权限。

Communication contract

沟通约定

Tailor the same evidence to the stakeholder's decision:

Sponsor/executive: outcome confidence, material variance, options, recommendation, decision required, latest useful decision date, and consequence of waiting.
Component leads: dependency changes, interface acceptance, shared-capacity trade- offs, decisions needed, and what remains within their authority.
Operations/adoption owners: capability readiness, training/process change, support model, adoption evidence, residual risk, and handoff date.
Vendor/partner: provider and receiver obligations, definition of ready, evidence, commercial/technical constraint, escalation route, and next checkpoint.
Affected users or customers: what changes, when, impact, support, uncertainty, and how feedback changes the plan. Do not publish internal risk detail that is not appropriate for the audience.

Never make a component dashboard, meeting count, or percentage complete stand in for program health. Report health by dimension: outcome, schedule, dependency, capacity, quality, adoption, benefits, and risk.

针对干系人的决策，对同一组证据进行相应调整：

发起人/高管： 成果置信度、重大偏差、选项、建议、所需决策、最晚有用决策日期，以及等待决策的后果。
组成部分负责人： 依赖关系变化、接口验收、共享资源容量权衡、所需决策，以及仍由其自行决定的事项。
运营/采用负责人： 能力就绪度、培训或流程变革、支持模式、采用证据、剩余风险和移交日期。
供应商/合作伙伴： 提供方和接收方各自的义务、就绪定义、证据、商业或技术约束、升级路径和下一检查点。
受影响用户或客户： 哪些内容会发生变化、何时变化、影响、支持方式、不确定性，以及反馈如何改变计划。不要披露不适合该受众的内部风险细节。

绝不能用组成部分仪表板、会议数量或完成百分比来代替项目集健康状况。应按以下维度报告健康状态：结果、进度、依赖关系、资源容量、质量、采用、收益和风险。

Troubleshooting patterns

故障排查模式

All projects green, program red: inspect integration, shared capacity, benefit ownership, and adoption; do not average component status.
Dependency dispute: reconstruct the provider/receiver contract and evidence, then escalate the decision the local owners cannot make.
Benefits are slipping while outputs ship: test the benefit hypothesis, adoption and operating assumptions, and disbenefits; re-scope or stop rather than declaring output delivery equal to value.
Program has become a project list: restate the shared outcome, remove unrelated components, and route independent investments to portfolio governance.
Sponsor changes direction midstream: preserve the original mandate and variance, record the new decision, assess component and benefit impacts, and rebaseline only with authority.
Shared team is the bottleneck: show competing demand and consequences; do not promise that adding work or meetings creates capacity.
Transformation resistance: identify affected roles, decision rights, incentives, training, feedback channels, and adoption signals. Route organizational design to org-design; keep program coordination here.
No evidence after repeated reviews: stop after three non-converging diagnostic passes, name the missing evidence and decision owner, and escalate or pause.

所有项目均为绿灯，项目集却为红灯： 检查集成、共享资源容量、收益归属和采用情况；不要对各组成部分的状态取平均值。
依赖关系争议： 重建提供方与接收方的约定及证据，然后升级处理当地负责人无法作出的决策。
输出已交付，但收益持续延期： 检验收益假设、采用和运营假设以及负收益；应重新划定范围或停止，而不是将交付输出等同于创造价值。
项目集已经变成项目清单： 重申共同结果，移除无关组成部分，并将独立投资转交产品组合治理。
发起人在中途改变方向： 保留原始任务授权和偏差记录，记录新决策，评估组成部分和收益影响，并且只有在具备相应权限时才重新建立基线。
共享团队成为瓶颈： 展示相互竞争的需求及其后果；不要承诺增加工作或会议就能创造资源容量。
转型遇到阻力： 识别受影响角色、决策权、激励、培训、反馈渠道和采用信号。将组织设计转交 org-design；项目集协调仍保留在当前 skill 中。
多次审查后仍无证据： 连续三次诊断仍未收敛时停止，明确指出缺失的证据和决策负责人，并升级处理或暂停。

Routing table

路由表

Need	Route
One project's milestones, vendor handoff, forecast, recovery, or closure	technical-project-management
Approved requirement into work breakdown and rollout plan	implementation-planning
Product bets, roadmap sequencing, or portfolio allocation	product-roadmapping-and-portfolio
Product decision rights and recurring product governance	product-operations-and-governance
Enterprise capabilities, target/transition architecture, or architecture authority	enterprise-architecture
Technology adoption posture or standards governance	technology-radar
Release mechanics or launch authorization	release-engineering and production-readiness
Live outage or responder command	site-reliability-engineering
Capital allocation, corporate strategy, or M&A	strategy-frameworks
Organizational structure and talent design	org-design
Independent assurance or troubled-program intervention	Assurance and intervention
Post-delivery adoption evidence or benefits learning	product-adoption and product-lifecycle-learning

需求	转交至
单个项目的里程碑、供应商移交、预测、恢复或收尾	technical-project-management
将已批准需求转化为工作分解和落地计划	implementation-planning
产品决策、路线图排序或产品组合配置	product-roadmapping-and-portfolio
产品决策权和常规产品治理	product-operations-and-governance
企业能力、目标或过渡架构、架构权限	enterprise-architecture
技术采用态势或标准治理	technology-radar
发布机制或上线授权	release-engineering 和 production-readiness
线上故障或响应指挥	site-reliability-engineering
资本配置、公司战略或并购	strategy-frameworks
组织结构和人才设计	org-design
独立鉴证或问题项目集干预	鉴证与干预
交付后的采用证据或收益学习	product-adoption 和 product-lifecycle-learning

Output contract and completion

输出约定与完成标准

Produce the smallest useful artifact: program brief, integrated dependency/control record, benefits map, governance decision, escalation brief, stakeholder update, recovery options, or transition/closure record. Separate evidence, inference, assumptions, commitments, options, and unknowns. Link to component sources and name owners rather than inventing agreement.

Complete when the requested program decision or artifact is delivered, the shared outcome and component boundaries are explicit, material dependencies and benefits have owners and review triggers, unresolved authority is escalated, and no claim exceeds the evidence. Do not imply ongoing monitoring without an authorized mechanism.

产出最有用的最小交付物：项目集简报、整合依赖关系或控制记录、收益映射、治理决策、升级简报、干系人更新、恢复选项，或转型与收尾记录。将证据、推断、假设、承诺、选项和未知事项分开。链接至组成部分来源并明确负责人，不要虚构共识。

当所请求的项目集决策或交付物已经完成，共同结果和组成部分边界明确，重要依赖关系和收益均已指定负责人及审查触发条件，未解决的权限问题已经升级处理，且任何主张均未超出证据时，即可视为完成。在没有获授权机制的情况下，不要暗示将持续开展监控。

Research basis and limitations

研究依据与局限

This synthesis is informed by a deep, source-grounded research artifact retained with the development record, including PMI's The Standard for Program Management, Fifth Edition (2024), UK Government Project Delivery guidance, Local Government Association dependency guidance, and NASA risk management guidance. The deep run confirmed the value of benefits dependency mapping, tranches, disbenefits, enterprise risk categories, and independent assurance. It directly consulted three sources; the NASA handbook PDF and some UK pages remained inaccessible to the scraper, so claims requiring those exact documents are not presented as verified here. The sources provide principles and jurisdiction-specific requirements, not a universal operating model or proof that any method guarantees success. Use formal organizational or regulatory standards when they govern the actual program.

本综合内容基于一项随开发记录保留的深入、来源可追溯的研究成果，其中包括 PMI 的 The Standard for Program Management, Fifth Edition（2024）、英国政府项目交付指南、地方政府协会依赖关系指南和 NASA 风险管理指南。深度研究确认了收益依赖映射、分批次、负收益、企业级风险类别和独立鉴证的价值。研究直接查阅了三个来源；由于抓取工具无法访问 NASA 手册 PDF 和部分英国页面，因此本文未将依赖这些确切文件的主张表述为已验证。

这些来源提供的是原则和特定司法辖区要求，而非通用运营模型，也不能证明任何方法必然成功。当正式的组织标准或监管标准对实际项目集具有约束力时，应采用这些标准。