项目发起人如何与其他角色分工：职责划分与协作机制

项目发起人的分工，核心是把“为什么做、做到什么程度、谁有权拍板”与“怎么做、谁来做、何时交付”分开。发起人对立项理由、目标与成功标准、资源承诺和关键决策负责，项目经理承接计划与执行，业务负责人管需求与验收，职能经理保障人员供给，治理机构把关阶段评审与重大变更。本文围绕单项目从立项到验收的角色划分，给出一张可填写的职责对照表和一套落地步骤。

要点总览（TL;DR）

• 发起人保留决策与授权：立项理由、目标与成功标准、预算与关键资源承诺、重大变更审批；项目经理承接计划、执行与风险跟踪，两者在同一项目中并行。
• 按决策权、交付责任、资源供给、验收确认四类活动划分职责，每项关键活动只设一个最终问责人，用RACI标注参与和知会，减少职责重叠与空白。
• 把分工写成书面职责约定，在立项评审、阶段关口和变更审批三个节点固定交接动作，并写明更新触发条件。
• 用角色—活动—交付物对照表逐项核对：唯一负责人、交接输入输出闭合、变更阈值与升级路径清晰、资源承诺有书面记录。

先定分工原则：发起人管决策，执行角色管交付

分工不清往往源于用“职位高低”代替“活动归属”。更可操作的判断标准是看一项活动最终由谁承担后果：承担目标成败后果的是发起人，承担交付进度与质量后果的是项目经理，承担需求正确性与验收后果的是业务负责人。按这个标准划线，发起人保留决策与授权，执行角色承担计划与交付，两者在同一个项目里并行，不互相替代。

把项目中的活动归入四类，分工就有了稳定依据：

• 决策权活动：立项批准、目标与成功标准确认、预算与关键资源承诺、重大变更审批、项目终止或转向。这类活动由发起人主导，治理机构在阶段关口参与评审。
• 交付责任活动：范围分解、进度与成本计划、任务分派、执行推进、风险与问题跟踪、状态报告。这类活动由项目经理负责，业务负责人和职能经理按各自领域参与。
• 资源供给活动：人员配置、技能匹配、工作量协调、外部供应商引入。这类活动由职能经理负责，项目经理提出需求和优先级。
• 验收确认活动：需求确认、交付物评审、用户验收测试、上线确认。这类活动由业务负责人主导，发起人对验收结论做最终确认。

判断分工是否存在重叠或空白，可以用两个问题逐项检查：这项活动如果出了问题，第一个被追问的人是谁？如果答不出唯一的人，说明负责人缺失；如果答出两个人且都认为对方主责，说明职责重叠。另一个检查角度是看输入输出是否闭合：每项活动的输出，是否正好是下一项活动的输入。例如项目经理的《项目计划》应当是职能经理配置人员的输入，业务负责人的《验收标准》应当是项目经理制定测试安排的输入。输入输出接不上，通常意味着中间有一项活动没有明确归属。

需要说明一个适用条件：在规模较小或治理成熟度较低的组织中，发起人可能同时承担业务负责人甚至治理机构的角色。此时仍建议在职责约定中把这几类活动分别列出，注明由同一人兼任，保留活动边界，避免项目推进中因“一人多角”而跳过评审或验收环节。

各角色职责与交付物对照表

下表按立项、计划、执行、验收、变更五个阶段，列出各角色的主要职责与关键交付物。责任标注采用RACI方式：R为负责执行，A为最终问责，C为需征询意见，I为需知会。每项活动只设一个A。

阶段	关键活动	发起人	项目经理	业务负责人	职能经理	治理机构	关键交付物
立项	提出立项理由与业务价值	A	C	R	I	I	立项建议书
立项	确认目标与成功标准	A	C	R	I	C	项目目标与成功标准说明
立项	承诺预算与关键资源	A	C	I	C	C	资源承诺记录
计划	编制范围、进度、成本计划	I	A/R	C	C	I	项目管理计划
计划	配置人员与技能	I	C	I	A/R	I	人员配置表
执行	任务分派与进度推进	I	A/R	C	R	I	任务清单与状态报告
执行	风险与问题跟踪	C	A/R	C	C	I	风险与问题登记册
验收	需求确认与交付物评审	I	R	A	C	I	评审记录
验收	用户验收与上线确认	A	R	R	C	C	验收报告
变更	一般变更审批	C	A/R	C	C	I	变更申请单
变更	重大变更审批（范围、预算、目标）	A	R	C	I	C	变更审批记录

使用这张表时有三个要点。第一，A列只能出现一个角色，出现两个A就说明该项活动需要拆分或明确主责。第二，R与A可以由同一角色承担，例如项目经理在计划编制中既是执行者也是问责人，这在执行类活动中是正常的；但决策类活动不宜由执行角色同时担任A，否则决策与交付的制衡会失效。第三，C与I的区分要落到动作上：C意味着在决定作出前必须收到该角色的书面意见，I意味着决定作出后需要通知，不参与讨论。把C和I写清楚，能减少大量“以为已经沟通过”的返工。

表中“重大变更”的界定建议在立项时就写进职责约定，例如涉及目标调整、预算超出一定比例、关键里程碑推迟超过约定周期，具体阈值由组织根据项目规模确定。阈值不写清，变更审批就会在发起人和项目经理之间来回推诿。

分工落地的操作步骤

从识别角色到形成可执行的职责约定，可以按以下四步推进。每一步都明确输入、动作和输出，便于在立项准备期内完成。

第一步：识别项目涉及的角色与关键干系人。输入是立项建议书和初步范围说明。动作是列出所有需要在项目中作出决定、提供资源、确认需求或接收交付的角色，区分“角色”与“具体人员”，先定角色再填人名，避免因人员变动导致分工失效。输出是一份角色清单，标注每个角色在本项目中的参与程度。完成标志是清单中每个角色都能对应到至少一项关键活动。

第二步：逐项活动分配负责人、参与人与知会人。输入是角色清单和项目活动分解。动作是把立项、计划、执行、验收、变更各阶段的关键活动逐条列出，为每条活动指定唯一的A，再标注R、C、I。分配时优先确认决策类活动和验收类活动的A，这两类最容易出现空白。输出是填好的角色—活动对照表。完成标志是表中没有空白的A，也没有一条活动出现两个A。

第三步：形成书面职责约定并评审确认。输入是角色—活动对照表。动作是把对照表连同决策权限说明、变更阈值、升级路径整理成一份职责约定文件，提交发起人、项目经理、业务负责人和职能经理共同评审，重点确认资源供给的承诺方式和验收标准的确认方式。输出是经各方确认的职责约定。完成标志是各方对本人承担的活动和交付物无异议，且知会方式已明确。

第四步：在立项评审与阶段关口固定交接动作。输入是职责约定和项目阶段计划。动作是在立项评审会上由发起人确认目标与资源承诺，项目经理接收并启动计划编制；在每个阶段关口，由项目经理提交阶段成果，业务负责人确认需求符合度，治理机构评审是否进入下一阶段，发起人对重大偏差作出决策。输出是各节点的评审记录与交接确认。完成标志是每个节点都有明确的交接输入、交接人和确认记录。

分工约定要真正约束日常协作，需要落到可查的状态上。在项目协作平台中，可以把角色与权限对应配置，让立项评审、阶段关口和变更审批各自对应固定的工作项类型与流转状态，评审意见和确认记录随工作项留存。ONES 支持通过工作项类型、状态流转和成员角色来承载这类流程，使“谁在什么状态下有权确认”与职责约定保持一致，减少口头约定与系统操作脱节的情况。具体配置方式需结合组织实际使用的版本与流程设计确定。

示例：一个立项到验收的分工场景

以下为演示性情景，用于说明分工在节点上的运转方式，不代表真实项目案例。

某业务部门计划上线一套内部审批流程优化项目。立项阶段，业务负责人提出立项理由：现有审批平均耗时较长，影响合同签署效率，并起草立项建议书。发起人审阅后确认项目目标为“将常规审批平均处理时间缩短至约定水平”，明确成功标准包含处理时长和用户满意度两项指标，并承诺调配两名业务骨干全职参与。项目经理在此阶段参与可行性讨论，接收目标与资源承诺后启动计划编制。治理机构在立项评审会上确认项目进入执行阶段。

执行阶段，项目经理将工作分解为流程梳理、系统配置、试点运行三个部分，向职能经理提出人员需求：流程梳理需要一名熟悉业务的专员，系统配置需要一名技术人员。职能经理按需求配置人员并确认可用工时，项目经理据此更新进度计划。执行中出现一处需求理解偏差，项目经理记录问题并提交业务负责人确认，业务负责人给出书面澄清，项目经理调整任务安排。整个过程通过任务状态和问题登记记录留痕。

验收阶段，业务负责人组织交付物评审和用户验收测试，确认流程配置符合需求，签署验收意见。发起人对验收结论做最终确认，并确认项目目标达成情况。试点运行期间业务方提出新增一类审批单据，属于范围变更。项目经理评估影响后判断超出预设变更阈值，提交发起人审批；发起人征询治理机构意见后批准变更，调整预算并更新目标说明。变更记录与审批意见一并归档，作为后续阶段关口的输入。

这个情景说明分工在节点上的三个关键动作：立项时发起人给出目标和资源承诺，项目经理才启动计划；执行中人员供给由职能经理承诺，项目经理据此排期；变更超出阈值时决策权回到发起人，治理机构提供评审意见。三个动作各有明确的输入和输出，衔接点不依赖个人默契。

完成检查：分工是否可执行的核对项

职责约定形成后，可用以下清单逐项核对。每项都给出可观察的判断依据，便于在立项评审前完成自检。

• 每项关键活动是否有唯一负责人。核对角色—活动对照表，确认每条活动只有一个A；出现两个A的活动，要么拆分，要么明确主责并记录理由。
• 交接节点是否有明确输入与输出。逐个检查立项评审、阶段关口、变更审批三个节点，确认每个节点都有交接的输入文件、交接人和确认记录，且上一节点的输出正好是下一节点的输入。
• 决策权限与升级路径是否清晰。确认重大变更的判定阈值已写入约定，超出阈值时由谁审批、征询谁的意见、多久内答复都有明确说明；一般变更的审批人也能在表中直接查到。
• 职责约定是否随项目阶段更新。确认约定中写明了更新触发条件，例如角色人员变动、范围重大调整、阶段转换；并确认最近一次更新已通知到所有C和I角色。
• 资源供给是否有承诺记录。确认职能经理对人员配置的承诺以书面形式留存，包含人员、可用工时和起止时间，项目经理的进度计划能对应到这些承诺。
• 验收标准是否在立项时已明确。确认成功标准和验收标准在立项阶段由业务负责人提出、发起人确认，验收阶段的评审依据可以直接引用，不需要临时补充。

清单中任何一项无法给出肯定回答，都建议在立项评审前补充完善。分工约定的价值在于让每个节点上的交接有据可查，随着项目推进逐步细化，而不是在启动时一次写死。

常见问题

发起人把决策权交给项目经理，会不会影响项目推进效率？

决策权与交付责任分开，目的是让两类判断各归其位，并不必然降低效率。发起人保留的是目标调整、预算与关键资源承诺、重大变更审批这类需要承担业务后果的决策；项目经理在既定目标和预算内对计划、任务分派、执行推进和风险处理拥有完整处置权。真正影响效率的是权限边界模糊：项目经理在预算内的事项也要层层上报，或者发起人直接干预任务安排却不承担交付责任。

落地时可以约定授权额度，例如在预算和进度偏差不超过预设阈值时由项目经理自行决策并知会发起人，超出阈值再升级。阈值写进职责约定，双方按同一标准执行。

组织规模小、发起人同时兼任业务负责人时，分工表还有必要吗？

有必要，但形式可以简化。一人兼任多个角色时，风险在于跳过评审或验收环节，把不同性质的判断混在一次口头沟通里。建议在职责约定中把决策、交付、资源供给、验收四类活动分别列出，注明由同一人兼任，保留活动边界和对应的确认记录。

例如发起人兼任业务负责人时，验收标准仍应在立项阶段书面确认，验收结论仍应有记录，便于后续追溯目标是否达成。兼任不改变活动本身需要留下的输入和输出。

重大变更的阈值应该由谁定、定在什么水平？

阈值建议在立项阶段由发起人与项目经理共同商定，写入职责约定，并由治理机构在立项评审时确认。常见维度包括目标或成功标准调整、预算超出比例、关键里程碑推迟周期、范围新增工作量占比。具体数值由组织根据项目规模和风险承受度确定，本文不给出统一标准。

阈值的作用是划清一般变更与重大变更的审批路径：一般变更由项目经理审批并知会相关角色，重大变更回到发起人决策，治理机构提供评审意见。阈值缺失时，变更容易在发起人和项目经理之间反复推诿。

职能经理承诺了人员，执行中又被抽调走，分工约定怎么处理？

这属于资源供给承诺的变更，应按约定中的更新机制处理，而不是临时口头协调。建议在职责约定中要求职能经理的人员承诺以书面形式留存，包含人员、可用工时和起止时间；发生抽调时，由职能经理提出变更说明，项目经理评估对进度和交付的影响，超出预设阈值的影响提交发起人决策。

同时更新人员配置表和进度计划，并通知所有知会角色。把资源变动纳入变更流程，能让进度偏差有据可查，也避免项目经理独自承担资源不足的后果。

职责约定多久更新一次比较合适？

按触发条件更新比按固定周期更新更实用。常见触发条件包括角色人员变动、范围重大调整、阶段转换、组织治理结构调整。每次更新后应通知全部参与和知会角色，并在文件中保留版本记录。

即使没有触发条件，也建议在阶段关口顺带核对一次职责约定是否仍与实际情况一致，重点看负责人是否变化、交接输入输出是否仍然闭合。分工约定随项目推进逐步细化，启动时一次写死反而容易与实际脱节。