项目复杂性管理有效实践

—— 本文内容结构 ——

第一部分 复杂性概念及度量

一、关于项目复杂性的理解

1、PMI关于项目复杂性的解读

（1）“人类行为”是项目的复杂性直接来源

（2）“系统行为”的复杂性来源于项目的系统本质

1）多样性

2）层次性

3）连通性

4）衍生性

5）共同演化

6）初始条件敏感性

（3）“模糊性”来源于“人类行为”与“系统”的互动

2、项目复杂性的其他解读方式

（1）项目复杂性的属性和构成

1）技术复杂性

2）组织复杂性

3）目标复杂性

4）环境复杂性

5）内容复杂性

6）信息复杂性

（2）项目复杂性的本体论及认识论

二、项目复杂性的测度方法

1、模型化度量方法

2、主观认知度量方法

3、间接复杂性度量方法

三、理解项目复杂性的价值

第二部分 复杂性管理工具与有效实践

一、复杂性管理基本原则

二、本文涉及的管理工具及有效实践清单

三、复杂性管理工具及有效实践介绍

1、复杂性评估工具（复杂性评估表）

2、项目核心领导团队

3、干系人分析与管理

4、项目分层/分组管理

5、项目治理

6、项目周期模型

1）增量交付模型

2）快速原型模型

3）敏捷模型

7、阶段审查方法

8、风险识别

9、协作性团队

10、团队建设

第一部分复杂性概念及度量

就像许多儿童故事始于“很久很久以前”一样，项目经理的分析汇报PPT也往往始于：“市场竞争日益激烈，市场环境变化日益迅速，项目（管理）复杂性不断提升”，可见项目复杂性这一概念早已广为人知，但是一旦被问及什么是项目复杂性，为什么现在项目复杂性会不断提升，许多项目经理却无法立即答出，严重影响了这些项目经理在项目管理小白眼中的高大全形象。

本文就是给这部分项目经理的形象挽救指南，读完之后，想必已经足以解答什么是项目复杂性以及为什么现在项目复杂性会不断提升的问题了。

一、关于项目复杂性的理解

关于项目复杂性，项目管理业界目前尚未有一种能被广泛接受的权威定义。

那个同学，你先把凳子放下，后面还有，后面还有。

虽然无法就项目复杂性的概念完全达成一致，但通过不断的研究，业界已经对项目复杂性的本质有了足够的理解。

1、PMI关于项目复杂性的解读

PMI的《项目复杂性管理实践指南》（2014）中，将复杂性划分为人类行为、系统行为、模糊性三大类，并将复杂性定义为项目或项目集或其环境的由于人类行为、系统行为和模糊性而难以管理的一个特点。

人类行为复杂性包含个体行为、群体、组织和政治行为、沟通与控制、组织设计与发展；

系统行为包含连通性、依赖性、系统动力；

模糊性包含不确定性和显露性。

其中“人类行为”是项目的复杂性直接来源，“系统行为”的复杂性则来源于项目的系统本质，而“模糊性（显露性和不确定性）”则来源于“人类行为”与“系统”的互动：

（1）“人类行为”是项目的复杂性直接来源

这点应该最易理解，正如那句“一切的问题，都是人的问题”，个体的非理性因素（乐观主义倾向和规划谬误、锚定效应、框架效应、损失规避心态、抵制及歪曲行为），群体、组织和政治行为中，部落心态、群体思维、群体转移、与项目目标不一致的自组织倾向、缺乏干系人承诺等情况，以及不同的法律视角，文化的多样性，组织设计的不当和不透明性均会导致复杂性的产生。

（2）“系统行为”的复杂性来源于项目的系统本质

项目的“系统行为”复杂性需要从项目管理系统学派的主要观点说起，系统学派认为项目是一个自适应系统。

系统包含多样性、层级性、连通性、衍生性，共同演化、初始条件敏感性等本质特征：

1）多样性：必要的要素多样性才可保证形成系统；

2）层次性：系统自身会有子系统，同时系统也是更大系统中的子系统，项目工作分解结构就是描绘这种系统层次结构的方法；

3）连通性：信息可以在系统的各部分之间传递；

4）衍生性：系统各部分的属性整体，产生了新的更高层级的属性，如汽车零件具备车轮、杠杆属性，而零件整体则构成了自行车系统；

5）共同演化：所有的系统都处于自身环境中，同时也是自身环境的一部分，随着环境的变化，系统也发生改变；

6）初始条件敏感性：即著名的“蝴蝶效应”。

项目或项目集均是存在于其他系统中的系统，通过组件的连接相互依存。项目或项目集组件的数量增加，在其多样性、层级性、连通性、衍生性的本质属性作用下，复杂性增加；项目或项目集组件发生变化或其间依赖关系发生变化，由于系统的初始条件敏感性，共同演化特征复杂性增加。

（3）“模糊性”来源于“人类行为”与“系统”的互动

《项目复杂性管理实践指南》（下称实践指南）认为显露性与不确定性是引起模糊性的原因：只要系统存在，且存在来自系统内外的观察，其组件间的层次性、连通性关系、衍生性特征、共同演化情况就存在显露/不显露两种情况；不确定性包含目标的不确定性及实现目标的方法、途径的不确定性，从系统论的角度来说，每个系统都有其系统目标，系统要素足够多，关系足够复杂，受其衍生性及共同演化特征影响，人类对系统目标的解读或者推动系统向目标演化的过程就必然存在不确定、不可知的情境。

显露性和不确定性来自于“人类行为”对“系统”的观察、解读或交互，其即是复杂性的原因，也是复杂性判断的结果。不同的认知层级、不同观察视角，对同一事物的复杂性认知结论存在不同，这也是为什么你身边的非项目管理专业同事会认为项目复杂性太高无从下手，而同时资深专家则认为只需要重点注意某方面的管理即可的原因。

2、项目复杂性的其他解读方式

关于复杂性，还有两种较主流的定义，一种在解读结构上更为清晰，将复杂性区分为本质属性和构成，另一种在复杂性的内涵解读上更为深刻，将复杂性的分为本体论和认知论。

（1）项目复杂性的属性和构成

这种理论认为项目复杂性内涵包括本质和构成。项目复杂性的本质属性包括要素数量多、要素具备多样性和差异性、要素间相互依赖相互作用、要素或要素间关系具备动态性及不确定性等，这些本质属性同时也是项目复杂性的本质来源，而其构成/分类则包括技术复杂性、组织复杂性、目标复杂性、环境复杂性、内容复杂性、信息复杂性。

1）技术复杂性

技术复杂性的影响因素包括许多方面，如技术类型、特殊设计、技术间依赖性等。

2）组织复杂性

组织是项目管理的基础和载体。组织复杂性的影响因素包括空间分布差异、垂直管理层级差异、组织间成员间或组织内部门间技能专业差异、组织类型差异等。

3）目标复杂性

目标复杂性的影响因素包括目标的多元性、层次性和动态性等。

4）环境复杂性

环境复杂性的影响因素包括自然环境、市场经济环境、社会文化环境、政策法规环境、政治环境、技术环境等。

5）内容复杂性

内容复杂性的影响因素包含任务数量、任务关系杂，任务间层次性及任务活动动态性。

6）信息复杂性

信息复杂性的影响因素包括信息系统、信息获取程度、信息处理水平和信息传递能力等。

（2）项目复杂性的本体论及认识论

本体论观点将复杂性称为描述性复杂性， 并认为复杂性是项目的内在客观属性。项目复杂性的属性和构成解读方式即是本体论观点。

认识论观点则从如何认知复杂性的角度展开研究，将复杂性看作人的一种主观感受， 认为对复杂性的认识仅仅存在于人们的观察和理解之中，一个系统复杂或简单是相对的，取决于我们怎么描述它， 并随着研究视角的不同而变化。

两种认识论实际上反映了认识事物的两个方面，并且在项目生命周期的不同阶段交替发挥作用。比如项目管理者制定项目战略时的复杂性即为认知复杂性，项目要素以及要素间的关系则是描述性复杂性。描述性复杂性在项目初期并不存在，而是在项目管理者确定项目目标，制定项目战略的推动下产生的。认知复杂性导致了描述性复杂性的出现，同时描述性复杂性的出现又会导致认知复杂性因管理者自身经验和能力的不同而变化。

二、项目复杂性的测度方法

1、模型化度量方法

模型化度量方法：项目复杂性因素较多，多数无法直接度量，所以部分专家学者们根据各自对复杂性的理解，选取度量项目复杂性的因子，并基于各项因子建立有效的整体测度模型，然后基于不同的方法进行计算，得出项目的复杂度数据。

《模型化度量方法示意》

模型化度量方法是一种看起来很美好的方法，因为使用该方法能得出具体的复杂度数据或者影响因子权重数据，符合人们对量化的期望。但是由于模型的非权威性，得出复杂度分析结果可信度存疑，同时算法要求量化影响因子并根据因子权重进行算术平均、加权平均等各种决策运算，需要一定的数学基础，导致掌握方法有较高门槛。当然将计算方法固化到程序中，使用时仅需输入数值即可得出结果，也是极佳的应用思路，不过不理解算法本身，只看结果的话，对项目经理也就只有评估参考作用了。

2、主观认知度量方法

主观认知度量方法 ：部分专家学者认为完全客观准确地度量项目复杂度并不可能，即使有方法能真正意义上准确度量项目复杂性，该方法用到的模型也会复杂到难以解读，所以他们考虑从人们对复杂性的认知和理解方面入手，收集专家意见，并综合分析，确定项目复杂度水平。

虽然主观认知度量方法看起来都来自主观意见，但是通过约定多种描述维度，邀请不同人员共同描述评估，有利于全面识别项目复杂点，其最终结果对项目经理管理项目能起到极大指导作用，并且利用一定方法，也能针对描述结果进行量化，得出数据来对比项目复杂度。

实践指南中PMI采取的复杂性评估问卷方式，就是一种主观认知度量方法。

《复杂性评估问卷部分问题示例》

这种方法也有缺点，因为结论来自于主观判断，所以高度依赖评估人员能力水平，不过增加评估专家人数，邀请多类型专家评估可降低对人员能力水平的依赖。简单说就是：三个臭皮匠使用此方法是顶不上诸葛亮的，三十个臭皮匠 + 三十个臭工匠使用此方法就有可能等于甚至超过诸葛亮。

3、间接复杂性度量方法

间接复杂性度量方法：直接度量项目复杂性遇到瓶颈时，专家学者们的研究就转向项目管理领域自身，如在时间管理领域中，项目是由很多工作包组成，研究各工作包的关联程度可以得出项目的复杂性。

目前关于间接复杂性度量的方法研究较少，从已有的研究结果看，准确性及可信度确实高于模型化度量方法。但这种方法实用价值低于前两者，因为度量的目的是为了更好的解读和管理，对项目经理而言，更多期望是有工具和方法能让项目管理者准确判断项目复杂点及复杂程度，以便针对性制定管理方法，而不只是在已经完成项目解读后，获知复杂数据，并根据再次调整规划和管理方法。

三、理解项目复杂性的价值

关于项目复杂性的概念洋洋洒洒好几段，想必有同学早就想问一句“知道有何用”了。

当今社会高速发展，市场环境高速变化，信息以几何量级倍增，项目的复杂程度日益加大，复杂性表现形式也日益繁多，对项目复杂性有了清晰的认识和了解，才能灵活正确的的采用不同的项目管理方法，进而提高复杂性项目成功的可能性。另外理论出于实践又高于实践，由实践而生，之后又能指导更高层次的实践，如果仅出于实务需要，重实践轻理论，反而会阻碍实践的总结和基于实践的理论升华。

第二部分复杂性管理工具与有效实践

一、复杂性管理基本原则

1、项目获批前用心研究项目可行性；

2、项目启动后，注意争取高层支持，并持续吸引高层关注；

3、根据项目情况灵活选择不同的项目组织结构或管理方法；

4、无论是工具的应用，还是采用各种实践手段，够用就好。

二、本文涉及的管理工具及有效实践清单

三、复杂性管理工具及有效实践介绍

1、复杂性评估工具（复杂性评估表）

工具简介：

复杂性评估表能帮助项目经理识别项目中的复杂问题，以便在项目治理结构、项目角色职责、项目管理策略等方面做出决策。

工具说明：

在项目一开始就使用复杂性评估工具，分析项目所具有的复杂性问题，并且在项目后续每个阶段关口再次使用。

从上部分可知，复杂性评估工具有多种类型，本文建议采用PMI的复杂性评估表方式，评估内容可参考PMI的《复杂性评估问卷表》，也可根据目标、环境、内容、技术等方面复杂性梳理问题，定期组织专家进行评估，问题至少应包含以下内容：

1、项目的目标是什么？

2、项目相关方是否都同意项目的目标?

3、项目具有多少站在不同立场上的利益相关者?

4、项目有时间方面的约束吗?

5、项目有固定的项目开始/完成的日期吗?

6、项目规模有多大?

7、有多少项目相关方参与?

8、项目各任务/活动是否存在较多相互依赖关系？

9、是否有很多新的或者没有解决的技术问题?

10、项目供应商/合作方出现问题，是否可能影响项目目标达成?

11、项目实施过程中，如果产生（技术/合作/其他）问题,必然会出现推迟项目的情况吗?

不同的专业人士具备项目不同层面的复杂性经验，围绕上述列表，尽可能多的收集项目专业性问题，并且要注意：

1）复杂性程度的评估结果取决于人们对复杂性构成的理解，同时项目复杂性也与项目相关方的管理经验有关；

2）由于人们所依据的资料均来源于手头即时信息，不同阶段评估的项目复杂性程度往往会有偏差，所以需要频繁地重复项目复杂性评估的过程。

2、项目核心领导团队

工具简介：

项目核心领导团队由不同领域的专家组成，并可在需要的时候引人主题专家。核心领导团队成员共同负责指导项目，各成员在需要用到其专长时来牵头领导，确保项目不会因不能同时胜任全方面角色的人员担任关键领导职位而失败。

工具说明：

核心领导团队并不意味着团队成员没有具体职责，比如项目经理仍然负责确保业务方案按时完整交付，业务分析师的责任仍是确保项目团队充分理解业务需求和预期收益等。

团队领导者根据项目在全生命周期中所处的阶段发生着转变。例如，在业务需求分析过程中，由业务分析师牵头，其他核心团队成员充当支持角色；当项目进人方案设计与开发阶段，技术架构师通常承担领导角色。所有的核心领导团队成员互相支持，并在他们的专长不是最关键因素时退居次位。

3、干系人分析与管理

实践简介：

干系人分析与管理是项目管理中最重要的事项之一。涉及变革的项目背后的权力操纵与斗争，隐藏在非正式谈话背后的项目期望，都是导致项目失败的主要因素。

实践说明：

1）在复杂项目中，强烈建议使用干系人分析、干系人登记册、干系人管理计划，干系人评估矩阵等工具；

2）强有力的管理层支持是复杂项目成功的关键，通过定期汇报、阶段成果呈现等方式持续吸引高层注意；

3）通过各种方式主动了解、分析并满足利益相关者的预期。预期的来源形式多样，如非正式谈话、电子邮件、需求、你和你的团队偶尔做出的承诺、在会议室的正式沟通或办公室走廊的聊天等；

4）了解并适应组织政治事件。

4、项目分层/分组管理

实践简介：

根据项目的目标及功能，进行归类、开发和整合，将项目分为多个具有不同目标的子项目/子项目组合，并交由不同的团队负责实现子项目目标。项目组合管理是项目分层/分组管理的一个典型案例。

实践说明：

1）确保子项目或子项目组合的目标有项目目标或功能拆解而来；

2）拆分目标为可以准确估算复杂度的子项目，估算方法可以采用专家判断、基于活动估算（自上而下的估算）、工作分布估算（通过项目关键阶段来进行估算）、比较估算（即已完成的类似项目进行比较）、参数估算等；

3）将目标、功能相同的子项目分为同组管理，便于安排统一的团队成员负责同类项目，便于团队成员经验积累与实践。

5、项目治理

实践简介：

治理的目的是为了营造可控的项目环境，组织已有结构、流程、规范等可以支持通常复杂度项目的顺利实施，却往往无法解决高复杂度项目的管理问题。项目经理通过治理来制定符合项目情况的项目组织结构，明确角色权责，制定重要的流程活动等，以便项目在组织形式、管理机制、日常运作、职责履行等方面更好的支持项目目标达成。

实践说明：

1）确保项目治理与组织治理分离，确保相关方管理与项目决策活动分离，避免影响决策效率；

2）明确项目决策结构及团队各角色职责；

3）至少明确以下关键活动流程：

a、项目或子项目运行状态和进展报告形式与周期；

b、项目或子项目收益规划或目标达成规划；

c、资源管理及调度方式；

d、阶段关口及关口评审；

e、决策流程；

f、风险问题应对计划和升级标准；

g、变更控制；

h、知识管理及经验教训。

6、项目周期模型

工具简介：

一种项目周期模型（也称为项目生命周期模型）并不能适应所有的项目，为解决不同层次的复杂性，项目周期也需要随之演化。复杂性项目通常适合使用增量交付模型、原型进化模型和敏捷模型。

工具说明：

1）增量交付模型

增量交付模型也被称为阶段交付模型、渐进交付模允许解决方案的逐步实施，通过积累前一版本的经验和知识，不断完善迭代，最终获得正确的方案，第一阶段通常是用于确定基本需求和方案设计的实验阶段，解决技术方案/需求可行性的不确定性问题。适用于将有价值的功能增量（部分解决方案）在早期就交付给客户，而不是在项目结束时提交整个解决方案。

2）快速原型模型

快速原型模型主要用于解决髙风险功能问题、需求理解或者概念验证。快速原型模型鼓励客户和利益相关者在项目早期参与，优势是业务方或最终客户可与项目团队密切合作，为每次迭代提供反馈。如果需求不明确且极不稳定，原型会帮助其弄清业务需要MVP（最小可视化产品）即为快速原型模型的一种。

3）敏捷模型

敏捷模型通常被用于业务目标和解决方案不明或者没有明确界定的时候，采用高度迭代和增量的流程。使开发人员和项目利益相关者积极合作，以了解范围，确定建设内容，及区分功能的优先次序。当需要大量实验以开发最佳方案时，就适合采用敏捷模型。

7、阶段审查方法

工具简介：

阶段审查方法是指通过在项目/子项目的各个阶段关口加入评审或评估，以便根据项目评价决定是继续按计划开展还是重新规划项目或终止项目。

工具说明：

1）阶段审查可以创造机会以定期从客户那里收集反馈信息；

2）通过挣值分析、收益偏差比较等方式可以确定项目的进展是否正常、方向是否正确；

3）同项目发起人和其他主要的利益相关者一起对项目开展阶段评审或评估，可以持续争取相关方参与与支持，也便于及时了解相关方的预期。

8、风险识别

工具简介：

风险管理主要目标为进行计划，以应对未来可能发生或可能不发生的事件。复杂型项目中风险管理的关键是项目的风险识别。

工具说明：

项目风险识别的方法大致可归纳为“自上而下”和“由下而上”两种方法：

自上而下的项目风险识别方法：

基于案例的方法。利用类似项目的历史经验，识别出项目风险的方法。

自下而上的项目风险识别方法：

风险检查清单。根据以往的项目中已经出现过的项目风险给出分类清单来识别新项目的风险。

集思广益。参会者们提出各种不同的项目风险问题，过程中不对项目风险做出评价，得到一系列的项目风险方面的想法，并进一步做出项目风险的分类处理。

项目工作分解结构。项目的组织分解结构常常以项目工作分解结果为依据，同时可用来确定相关的项目风险要素的结构。

流程图。以图表方式表示项目任务进程的管理方法，以项目各决策点为基础，去识别项目风险事件将在何时发生。

德尔菲法。这系统的方式向专家们单独征求意见，然后将专家意见资料进行汇总并得出相关研究的结论。

情景模拟。这是一个制定项目风险管理备选方案的复杂和反复的过程方法。

因果图。因果图可用于弄清项目风险之间的相互关系。

9、协作性团队

工具简介：

协作性团队的目的是创造一个合作的环境，让项目相关方成为一个团队，以便促使每个人通过共同合作来实现项目目标。协作性团队的原则是项目的“利益共享，损失共担”。

工具说明：

多数复杂性项目存在利益相关方（如业务方）参与不足的问题，甚至由于难以找到合适的利益相关者参与并致力于明晰需求而导致项目的失败。部分利益相关方认为需求定义是项目团队的责任，而不是业务经营人员或业务发展领导者的责任，为了解决这一问题，需要注意以下几点：

1）寻求主要参与方在项目目标上与相关方的共同利益点，如有可能，争取双方平等的收益分配/收益获取方式；

2）坚持客户、最终用户共同参与项目，从相关人员中获得关键资源，作为需求团队的正式成员参与整个项目；

3）鼓励项目团队成员寻求“对项目而言什么是最好的”这一问题的答案。

10、团队建设

实践简介：

复杂型项目，需要更强力的团队，而强力的项目团队离不开有效的团队建设。

实践说明：

1）建立纪律文化，遵循必需的流程，越是复杂型项目，越需要有规范的流程；

2）引导而不是仅仅管理团队，尽可能让每个团队成员都能主动为团队贡献力量；

3）建立能够节省时间的沟通方式，明确团队成员间沟通响应规则。如团队成员预期回复信息的速度多快？团队成员外出或休假时的通信方式是什么？

4）鼓励创新，允许团队成员在可控情况下试验与核心领导团队意见不符的技术方案、管理方式等。(来源：苏项荟 苏宁金融-陈辉）