项目定义、类型与分级

是什么

项目管理的第一件事不是排计划，而是判断这件事到底该不该按项目管。同样的资源投进去，一件被当成"项目"来管的任务，和一件被当成"日常活儿"来处理的任务，结果差别很大：前者有目标、有节点、有门径、有复盘；后者往往做着做着就散了。

判断标准只有三条，必须同时满足：

标准	含义	反例
有确定的开始和结束时间	不是长期职能工作	日常设备点检、月度报表
有确定的唯一产品或结果	交付物可被验收	反复进行的批量生产
需要一定资源投入（通常不少于 0.5 人/年）	人力、设备、预算有实质占用	顺手改个参数

三条不满足的一次性工作，按条线任务或工作包处理即可，不必套项目流程——流程越重，越容易被绕过。

一句话逻辑：

判定是不是项目 → 定类型（决定门径深度）→ 定分级（决定审批层级与模板）→ 定交付属性（决定验收口径）

项目层级：系统集合 → 项目集 → 项目 → 子项目

大组织里"项目"不是孤立的一层，往上往下都有归属，混淆层级会造成责任真空：

层级	定义	例子（通用化）
系统集合	服务于同一应用对象的一组关联项目	某车型平台上的整套电驱系统供货
项目集	放在一起管理、以获取单管拿不到的收益的一组项目	该车型下按排放/法规阶段划分的项目群
项目	对内外部客户交付一个完整成果	系统下的某个具体零部件/整机项目
子项目	为完成项目交付而拆分的范围，各自有独立交付物	开发、采购、生产、物流子项目；或系统、软件、硬件、机械、匹配子项目

关键点：子项目不是"任务包"，它有独立交付物、独立负责人和独立的风险。子项目出问题时，要拉着子项目经理和其条线经理一起上项目审查会，否则问题会在边界上被踢来踢去。

项目类型决定门径深度

同一套门径流程套到所有项目上，要么拖死小项目，要么放过大项目。先分类：

类型	做什么	门径深度
创新项目	对潜在概念方案做评估与研究开发，为后续平台提供输入	轻门径，重在技术可行性与专利/情报检索
平台项目	把新一代产品从概念变成具体设计并验证	全门径（QGP 系列），最严
客户项目	在平台基础上做客户定制化开发；首次在客户处应用即 Pilot 项目	全门径（QGC 系列）+ 对齐客户节点
其他项目	国产化、降本、移线、建厂、IT 系统/设备部署等	裁剪门径，重在投资、验收与切换风险

平台项目与客户项目的门径评审是两套编号（QGP / QGC），但阶段划分一致；看成套文件时先按阶段对齐，再对编号，别被编号绕晕。

项目分级决定管理强度

按规模把项目分为超大、大、中、小、工作包五级。分级不是面子问题，它直接决定：

• 项目管理委员会的组成与层级；
• 项目经理的资质等级与授权范围；
• 使用哪套模板、方法与工具（大项目用整套，小项目裁剪）；
• 评审频次（超大/大型项目至少每季度一次项目评审）；
• 是否需要正式的项目手册与启动加速工作法。

分级矩阵由各事业部结合自身业务调整，但指标要经职能部门审查、由业务单元负责人批准，不能由项目经理自己定级来减负。

交付属性决定验收口径

交付属性影响验收、成本和责任划分，常见三类：

• 整机交付：自行生产后直接交付客户，对制造质量与交付负全责；
• 外购转售：从外部供应商采购后转售，重点在供应商质量与来料管控；
• 半成品交付 + 客户末端完成：提供硬件与基础软件，客户自行刷写应用数据，验收要明确"哪些是供方责任、哪些是客户责任"。

怎么做 / 关键点

1. 先写一句项目定义：为谁、交付什么、什么时候结束、大概投入多少。写不出来，说明还不到立项的时候。
2. 套三条判定标准，不是项目就走条线任务，别硬塞流程。
3. 填分级矩阵打分：范围、投资额、技术新颖度、客户等级、跨部门数量，综合定级。
4. 按类型选模板集，把不需要的章节明确标注"本项目不适用"并说明理由（而不是默默跳过）。
5. 在项目协议里写清交付属性与验收边界，尤其是半成品交付和客户末端工序。
6. 层级关系画出来：这个项目属于哪个项目集、拆成哪几个子项目、各自负责人是谁。

常见坑

• 把任务当项目：小改动用全套门径，流程走完市场机会已经没了。
• 把项目当任务：真正需要资源保障的事没立项，最后没人负责、没有预算。
• 分级靠感觉：项目经理自评小项目逃避评审，风险在量产后暴露。
• 类型混用：客户项目套平台项目的门径，客户节点与内部评审互相打架。
• 层级不清：项目集、项目、子项目混着叫，出问题时找不到该升级给谁。
• 交付属性不写：客户末端工序出问题，供方与客户互相不认账。