组织做的工作可以分为两类：项目和运营。
它们是一对相对的概念：
1. 可以根据侧重性，对工作进行“项目 or 运营”的性质转换；
2. 运营往往可以划分为不同的项目来执行；
一、 项目的定义与特性
项目是指为创造独特的产品、服务或成果而进行的临时性工作。项目是为了组织的经营需要与战略目标服务的。
临时性
- 临时性是指项目有明确的开始时间和结束时间（启动过程的开始时间可能不明确），不会无限期的延续下去；
- 临时性与项目工期的长短无关，可以一两个月，也可以十几年；
- 项目可以因多种原因而结束，譬如目标达到、需求变更、目标无法达成，但是无论何时何因结束必须经过既定的批准程序，不能不了了之；
- 临时性的构因是由于商业机会的短暂性导致的；
- 项目的临时性诱发了项目团队的临时性，为团队成员带来了挑战；
- 项目具有临时性，但是项目产品往往具有可持续的长期生命力，譬如水电站建设项目
独特性
- 独特性又指“一次性”，只做一次的事情总会是独特的，只要是项目多多少少会与之前的项目有所差异；
- 独特性是相对的概念，一个项目与之前的项目总会有些相似地方(注意这种一定的相似性并不能改变项目的独特性)，正是这种“相对的独特性”才体现了PMBOK的构因和价值；
- 强调独特性在于重视项目风险，表示需要加以注意而不要完全的“循规蹈矩”；
- 项目的独特性也表示了项目产品的独特性，因此独特性也是项目可交付成果的重要特性之一；
- 项目的可交付成果可以是 有形的产品，无形的服务能力(员工培训后的员工能力)、其他成果(科研出来的知识)；
渐进明细性
- 随着时间的推移、情况的明朗和信息的增加，在连续的积累中分步骤开发，以便逐步明确项目的细节特征；
- 渐进明细的外部构因：
- 首先往往很难不可能一开始就制定一份非常明晰的计划，因为项目的各种信息是逐渐明朗的；
- 其次能够避免一定的风险，毕竟一开始就太过详细的计划必定需要一定的人力，而计划一旦被否决，就会损失很大，不如一开始制定一个大概的框架性计划；
- 最重要的，只有逐渐细化的项目计划才具有可操作性和可实现性；
- 渐进明细的内部构因：
1.项目的范围。一开始只有粗略的范围说明书，然后逐渐细化为工作分解结构和工作分解词典；
2.项目的计划。一开始只有控制性的计划，逐渐分解后才有具体可实施的计划；
3.项目的目标。一开始只有方向性的大目标，逐渐细化后具体的、可测量的、可实现的小目标；
4.其他
- 渐进明细与范围蔓延根本不是一回事，前者必须做，后者必须避免；
渐进明细必须在一定的项目边界内进行，以避免演变为“范围蔓延”；譬如合同工作的渐进明细必须在合同所规定的工作范围内进行，如果超过属于追加额外工作，应该按照合同变更管理程序加以管理；
二、 运营
从项目的三个特性出发，针对任何一项工作：
1. 如果更看中它的临时性、独特性和渐进明细性，都可以将它视作 项目
2. 如果更看重它的永久性、与其他工作的相似性，则可以将它视作 运营
运营是根据现有的程序，在标准化的生产线上进行；或者根据既定的服务标准，按规定好的服务流程进行。
2.1 项目和运营的共性
- 都由人来完成
- 都受制于有限的资源
- 都要被规划、执行和监控
- 都是为了组织的经营需要与战略目标服务的
2.2 项目和运营的差异
- 临时性与永久性；
项目是临时的，做项目就是为了实现其目标，并结束项目，因此项目在达成某种特定目标的时候就告结束；
运营是永久的，做运营是为了持续的经营下来，不因目标的实现而结束，因此运营在达成阶段目标的时候采用新目标，并通过这种不断制定新目标的方式把工作继续下去；
- 独特性与同样性
项目是创造独特的产品的，追求独特性；
运营是生产出同样的成果，追求相似性，譬如汽车零配件的生产，追求不同批次的产品一致相似；
- 逐渐细化与标准化
项目产品的生产过程是逐渐细化的； 过程中充满风险；
运营是在标准化的生产线或根据标准化的服务流程开展的； 过程中几乎无风险；
2.3 项目与运营具有相对性
2.3.1 项目与运营的承接关系
- 在组织工作中，两者相互支持，相互协调，共同为了组织的经营需要与战略目标服务；
- 项目的启动与收尾都与组织的运营密切相关；
- 运营是建立在项目开发的生产线或者服务能力的基础上的；在运营的过程中，当需要开展一些重复性工作无法胜任的活动时，又需要做项目，譬如生产线改造升级；
- 在新产品开发、产品升级或提高产量时
- 在改进运营或产品开发流程时；
- 在产品生命周期结束阶段(注意不是，结束时)
- 在每个收尾阶段(注意不是，时)
- 项目所形成的产品要交付运营，项目服务于运营； 项目又往往来自于运营(在运营工作中发现了某种机会或威胁)；
三、商业价值、组织战略、项目组合、项目集
3.1 商业价值与组织战略
商业价值是组织有形资产和无形资产的综合，如固定资产、货币资产、商誉、商标等；
组织战略是组织长远(5or10年以上)的发展目标；
3.2 项目组合和项目集
项目一定隶属于某个项目组合，但可以不属于任何项目集；不属于项目组合的项目是对资源的浪费，对组织发展无任何意义，不允许存在；
项目组合是为了实现组织的战略目标而被集中管理的一些项目、项目集、子项目组合以及其他相关工作；
项目集是相互关联并被协调管理的一组项目；譬如街道开挖部门的供水、供电、供气等项目，合在一起管理可以避免乱挖的混乱局面；
- 项目是临时的，但项目集可以是长期持续的(不断实施新项目)，譬如出版报纸或杂志就是一个项目集，每期是一个项目；
- 项目集除了包含项目外，也包含一些各项目的项目范围之外的工作(也可以视为一个项目)；譬如汽车研发项目集不仅包含各汽车部件的研发项目，各部件的组装是各项目之外的工作；
- 许多持续性运营可以视为“项目集”，然后分解为许多项目，来进行项目化管理；
| 分析 |
项目组合 |
项目集 |
| 内容 |
一些项目、项目集、子项目组合以及其他相关工作 |
一些项目以及联系跟项目的工作(也可以视为项目) |
| 项目间的关系 |
不一定有内在的联系或依赖，只是都使用了系统有限的资源，一定有优先级顺序 |
一定有内在的联系，相互平等无优先级顺序 |
| 管理的目的 |
排列项目的优先顺序，以便确认全局资源的优先分配顺序 |
通过抓住各项目间的内在联系获得额外利益 |
| 管理的重点 |
按一定的标准对项目或项目集进行优先排序，实现项目组合对项目的最大贡献 |
项目之间的依赖关系 |
| 与组织战略的关系 |
直接服务于战略 |
通过项目组合，间接服务于战略 |
| 变化性 |
非一成不变，可能需要终止旧项目，补充新项目等 |
|
项目集与项目的相对性
一个大项目，被视作单个项目或者项目集，取决于人们的需要；
- 如果作为单个项目，则每个组成部分都是子项目，譬如“汽车研发项目”。不仅项目中的某一部分可以作为子项目（例如房建项目中的基础工程），项目生命周期中的某一个阶段也可以视为一个子项目（房建项目的设计阶段）
- 如果作为项目集，则每个组成部分都是项目；
项目与子项目的相对性
单个的子项目可以被看做项目，并按项目进行管理 完整的概念层次结构:“组织战略—-项目组合—-项目集—项目—子项目—可交付成果—-工作包—-进度活动”
- 项目产品为最终交付成果
- 为了实现最终交付，需要完成一些较小的可交付成果。工作包是项目上最小的可交付成果
- 进度活动是为了完成工作包而必须进行的具体活动；
【图1.3.1】
四、 项目、项目集、项目组合管理及组织级项目管理
PMP考试针对单个项目的管理，不针对“项目集、项目组合管理及组织级项目管理”，仅需要了解必要的基本概念
项目管理是要正确的完成单个项目。它把项目单独拿出来考察，不考虑与其他项目的联系；
项目集管理是正确的完成一系列项目，它通过管理项目之间的内在联系，来取得把每个项目单独管理所不能取得的利益。它重点观察项目之间的相互联系，平等看待同一个项目集中的不同项目，不存在优先级顺序
项目组合管理是要选择一系列正确的项目来执行，并且排列项目的优先顺序。由于项目组合是直接服务于组织战略的，组合管理就是为了确保每个项目都是有助于组织战略的实施，对有限的资源进行分配和确定优先顺序；
组织级项目管理（OPM）通过协调组织驱动因素（如组织结构、组织文化、人力资源政策等）与项目、项目集、项目组合管理实践，来提高组织实施战略的能力。也就是通过不断优化组织因素，来更优支持“项目、项目集、项目组合管理”
OPM 旨在确保组织开展正确的项目并合适地分配关键资源。 OPM 有助于确保组织的各个层级都了解组织的战略愿景、支持愿景的举措、目标以及可交付成果
4.1项目管理
项目管理就是把各种知识、技能、工具和技术运用于项目活动，来达到项目要求。(这主要从技术层面说，其实也需要理念层面的知识)
4.1.1 管理一个项目需要
- 通过与项目的主要干系人(对项目有不同的需要、关注(想要)和期望)的沟通，识别他们对项目的要求；
- 在分析项目要求的基础上，权衡不同干系人对项目的不同要求，在他们之间找到最佳平衡点；
- 在分析项目要求的基础上，权衡项目范围、时间、成本、质量、资源和风险等相互竞争的要求，找到最佳平衡点；
- 建立明确、具体且现实可行的项目目标；
- 把项目目标转化为具体的实施计划，组建项目团队具体实施；
- 对项目的进展情况进行动态的监督与控制，及时纠正错误，保证项目顺利进行；
- 对项目阶段或者整个项目进行正式的收尾工作，结束阶段或整个项目；
4.1.2 项目目标的主要维度
时间和成本是关于“效率”得，即以正确、高效的方式做事；
质量和范围是关于“效果”的，即做正确的事，获得正确的结果，保证项目产品能够发挥既定功能；
需要注意的是：“项目干系人”的期望是需要考虑和满足的；但是“项目范围”是不可镀金的，不能做额外的工作；
项目目标的4个维度紧密联系，相互之间有有着冲突；一方面的变化势必引起至少一个其他方面的变化；一个方面的优化可能只有以另个方面的损失为代价。
- 各维度间的优先顺序
- 笼统的讲，各维度之间不存在优先顺序；
- 只有落实在具体的项目，结合具体的场景和现况，各维度间的优先顺序才存在；
- 即便在实际落实后获得了优先级顺序，这种顺序往往也是有管理层决定的，而不是项目经理；
- 不同的干系人对不同维度的重要性的要求可能不同，从而增加了项目管理的难度；
- 如果项目产品是为某个外在事件服务的，并且这个外在事件的开始时间无法更改，那么往往时间是最重要的；
4.1.3 新的三重制约
- 项目经理需要把干系人的需要Needs、想要Wants、期望Expectations转化为“项目要求”Requirements，前者是可以笼统含糊的，但后者必须是具体的，可测量的。
- “项目要求”Requirements通常用“三重制约”来表示。
- 老的三重制约是：时间、成本、质量
狭义：“范围、时间、成本”和夹在他们之间的“质量”。
- 新的三重制约
- 体现了“范围”的龙头作用
- 承认了对“范围、时间、成本”的调整都会影响项目“质量”
广义：在狭义基础上，包含“范围、时间、成本、质量、风险、客户需求”6个方面。
标明项目管理就是要在充分考虑干系人需求和风险的前提下，在规定的范围、时间、成本和质量下完成项目，以满足干系人对项目利益的追求；
【图1.4.1】
4.1.4 项目管理需要的知识
除了项目管理自身所涉及的知识、技术和理念外，还需要掌握其他的知识：
- 通用的管理知识与技能；
- 应用领域的知识、标准和法规；
- 对项目环境的理解； 社会的政治经济文化甚至自然环境，对项目都有一定的影响，项目的实施也会对相关环境产生影响，项目团队需要对环境加以考量；
- 人际关系技能；包括有效的沟通、施加影响、领导、激励、谈判、冲突管理、解决问题等；
五、生命周期
项目生命周期及其阶段划分，是项目治理的重要内容
注意与 “项目管理生命周期”，以及更长的“产品生命周期”的区别,尤其：项目阶段 和 项目管理过程组 是完全不同的两个概念
- 项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架，项目的生命周期各不相同，但是基本框架相同
- 项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段，属性是可测量且独特的
- 一个项目阶段可能重复循环进行5个过程组
- 一个阶段结束并不意味下一个阶段的开始，发起人具有权利终止项目
- 阶段关口在项目阶段结束时进行，将项目的绩效和进度与项目和业务文件比较，根据比较结果做出决定（例如继续/终止的决定）
- 项目管理过程是旨在为创造最终结果的系统化的系列活动，以便对一个输入或多个输入进行加工，生成一个或多个输出
- 项目管理生命周期，也就是项目管理过程组，包括五大过程组类型，是项目管理输入、工具和技术、以及输出的逻辑组合。
5.1 项目生命周期
项目生命周期是通常划分为若干个阶段的、从项目开始到结束的全过程。
为了便于管理和控制，进行了阶段划分，每个阶段都有应该完成的工作、该交付的可交付成果，都需要阶段验收标准和阶段放行口。
随着生命周期的开始，项目对资源的需求越来越大，并在项目执行期间达到最大，最后在收尾阶段急速下降。 因此，收尾阶段要快速收尾，不要拖拖拉拉。
5.1.1 项目生命周期的特点
- 不同类型的项目有不同的项目生命周期阶段划分。 因为他们所要完成的工作完全不一样，注意不要去找共性。
建筑项目：可行性研究、初步设计、详细设计、施工和移交
软件项目：需求分析、框架设计、详细设计、编程、调试、安装和移交
- 项目生命周期的每个阶段都可以看做一个单独的项目或者子项目。取决于客观情况和主观需求。
- 一般情况下，一个阶段结束后才可以开始下一个阶段，但是如果风险不大，在经过一定审批后可以提前进入下一个阶段。
项目生命周期是通常顺序排列而有时相互交叉的集合
- 一个阶段开始并不意味着下一个阶段结束。任何一个阶段点的结束，都可能成为项目的结束点或封杀点。
- 如果一个项目包含多个相对独立的部分，项目生命周期可能在不同部分上同时演进，从而形成不同的当前阶段结构
5.1.2 项目生命周期的分类
| x |
预测型&计划驱动型 |
适应型&变更驱动型 |
| 定义 |
事先编制计划，详细定义产品，然后在执行阶段完成已定义好的产品，在收尾阶段验收并移交已完成的产品 |
随用户需求的变化(或逐渐明细)，通过短期迭代来逐步完善产品，直到产出最终产品 |
| 特点 |
先设计好最终成品，再开始做，对变更执行严格控制 |
边设计边生产，每个迭代期都设计并生产满足用户当前需求的产品原型，并在下个迭代进行完善 |
| 适用条件 |
有成熟做法、风险低、待开发产品清晰明确的项目，或者产品必须作为整体完整交付的项目 |
适用于需求不是很明确，或者经常变动的项目 |
| 开发方式 |
瀑布模式 |
原型法 或者 敏捷开发方式 |
| 开发按过程 |
依次进行 设计—建设-验收交付，一次交付完整产品 |
每个迭代都进行“设计—建设-验收交付”，分阶段交付产品 |
| 干系人参与 |
只参与开始和结束阶段，也就是产品的设计和验收交付 |
频繁参与，也就是每个迭代的设计和验收交付 |
| 项目范围 |
开始就很明确，且不变动 |
在迭代期内不变，在迭代期之间通常变化；依次确定各个迭代的范围 |
| 示例 |
建筑工程项目 |
研发项目 或 It项目 |
- 具体的项目可以采用 这两端之间的任何类型的生命周期
- 无论是预测型，还是适应型，其阶段之间的关系有可能是 先后顺序(1结束2开始)，也可能是交叉(1未结束，2就开始)的
项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关，这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式：
| 类型 |
定义 |
适用 |
图解 |
| 预测型 |
在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。软件开发领域的瀑布模型就属于该模型 |
1.需求、时间、范围确定
2. 所处行业知识充足 |
见下图1 |
| 迭代型 |
伴随对产品理解的不断深入，通过一系列重复的循环活动来开发产品 |
1.项目范围在早期确定，但是时间和成本估算难以估算而要不断修改；
2.性能优化的场景
3. 管理技术风险 |
见下图2上 |
| 增量型 |
将产品分成不同的模块或功能，通过一系列的迭代不断的增加产品的功能，并交付给客户使用。只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的 |
1.需求基本确定，但是范围需要不断渐进明细
2.可以应对小的需求变更
3. 管理日程风险 |
见下图2下 |
| 适应型 |
(变更驱动型 or 敏捷型) 是迭代型和增量型的一个特例，目的在于应对大量的变更，获取相关方的持续参与，其迭代周期更短，而且所需的时间和资源往往固定 |
1.环境和需求快速变化
2.需求和范围难以事先确定 |
见下图3上 |
| 混合型 |
预测型和适应型混合使用，譬如：需求分析阶段使用预测型，而开发方法按照适应型 |
1.组织从传统管理过渡但敏捷管理时 |
见下图3下 |
5.2 项目管理生命周期
做项目，必须同时做技术工作和管理工作。技术工作是基础，管理工作能提高效率和改进效果
基于技术的项目生命周期 = 项目生命周期 = 产品导向过程； 在不同类型的项目上不同
基于管理的项目生命周期 = 项目管理生命周期 = 项目管理过程组； 在不同类型的项目上相同
基于管理的项目生命周期就是项目管理生命周期，旨在描述项目的每个阶段应该完成什么管理工
作。
按照PMBOK，项目管理生命周期包含 启动-规划-执行-监控-收尾
- 项目管理生命周期在不同的项目上是一样的
- PMBOK往往用 “项目管理过程组” 代表 “项目管理生命周期”
- “项目生命周期” 和 “项目管理生命周期” 的阶段划分是显著不同的，前者根据技术，后者根据管理
- “项目生命周期” 和 “项目管理生命周期”有相同的起点和终点
— 大过程组/阶段之间不是简单地依次顺序，往往是循环和交叉的
5.3 产品生命周期
**从项目开始到项目结束再到项目产品运行生命终止(退出市场)的全过
程。**
- 产品生命周期包含通常 顺序排列的且不相互交叉的一系列产品阶段
- 一个产品的生命周期可以包括多个项目周期
项目生命周期只是产品生命周期的一部分，且产品生命周期往往包含多个项目周期，因为不仅产品研发是一个项目，产品运营中的升级等等都可以作为一个项目
产品生命周期成本:
- 项目建设成本
- 项目建成以后营运成本
- 产品退出市场时的处理成本
|
