项目管理中的项目健康度评估
蒋昕炜
二00九 年 三
月
摘 要
在项目管理方法论当中，对项目的评估机制是一个非常重要的组成部分，目前的项目评估主要在两个层面上进行，即在项目的操作层面及企业的业务层面。
传统的项目评估机制完全针对项目当前的操作状态，以传统的“铁三角”理论为基础的，重点考察项目在成本、进度及业务目标上的完成状况。“铁三角”理论本身并不能很好地反映项目对于企业的业务价值，故从80年代以后，企业更多地引入了基于关键成功指标 CSF 的项目评估机制，以反映项目在业务层面的价值。
在项目管理实践中，管理者们发现他们需要一种更为有效的评估机制，介于上述两个层面之间，用以衡量一个项目能否最终取得成功的可能性，也就是项目的运行趋势。这就需要一种全新的理论与方法来对项目进行较高层面的分析与考察，可以从健康性与趋势上对项目加以评估。
在这一领域业界并没有非常成熟的理论体系，但在项目实践中很多大型企业有一些自有的经验与方法，本文的核心内容与工作，在于通过对项目“健康度”相关理论的研究以及大量具体案例的分析，总结归纳出一套面向IT行业的项目“健康度”评估方法，提供一套具体的、可操作的方法论，使之成为IT企业对项目进行深层次绩效评估的重要工具，这一方法论的设计过程主要基于以下过程及原则：
1. 对现有项目健康度理论进行研究与简化，使之易于操作 2. 对大量实际项目进行研究，分析导致出现问题的关键因素 3. 针对IT类项目的特点，对方法论进行优化，这些特点包括：
a. 需求的复杂性
b. 先进技术带来的潜在技术风险 c. 对关键技能与关键人的高度依赖性
4. 基于相对简化、易操作原则所做的评估流程与工具设计 5. 新的方法论在项目中的实践应用
本文将对大量的实践案例进行讨论与研究，对相应的方法论进行分析与介绍，重点分析在应用中的各种实际问题，同时探讨这一方法论在未来项目中的应用。
关键字：项目管理、项目健康度、绩效评估
I
作者简介
蒋昕炜老师1997年作为IT工程师加入IBM中国公司， 2000年成为解决方案中心技术经理，作为技术负责人和项目管理者参与IBM 服务器部门在国内的众多大型IT项目。2001年后作为产品经理负责高端解决方案的销售咨询工作，以及公司内部的员工培训。在近七年的IBM职业生涯中，参与公司内外的多个大型项目，直接负责一些重要项目的实施及控制，对“复合型”组织架构下项目的运作模式有多年的实际经验。
2004年离开IBM加入英特尔（Intel）公司，负责亚太区各国渠道客户解决方案咨询工作，2007年离职成为职业项目顾问与客座讲师，并与能通威科公司合作参与航天部五院相关航天项目的咨询服务。
从2004年开始作为兼职讲师，与北京大学软件与微电子学院合作从事项目管理的教学，目前是包括IBM在内国内多家著名企业、培训机构的客座讲师，其课程风格不同于本土学院派及港台讲师，注重西方管理方法在中国本土环境中的应用，解决项目化机制在企业应用过程中的各种实际问题，并强调职业的项目管理者所必需具备的素质与技能，主要课程涉及基本项目管理流程与思路、项目经理的素质与沟通技能、企业级项目组合管理与策略、项目风险的控制机制等相关领域，过去5年服务的客户覆盖外资（如IBM），本土大中型企业（中移动集团及多个省公司，中石油）、政府部门（如财政部、航天部）、科研机构（中科院电子所）、中小企业等多个层面，有丰富的企业培训经验。
蒋昕炜现为美国项目管理协会（PMI）会员，国际项目管理协会（IPMA）项目管理大奖评估师，项目管理专家（PMP）认证，北京大学客座讲师。
其论文《企业项目化改制的成熟度演进》2006年一月发表于项目管理学权威杂志
个人主页： www.pmtraining.net
II
目 录
摘 要 ..................................................................................................................................... I 作者简介 ............................................................................................................................... II 目 录 .................................................................................................................................. III 图目录 .................................................................................................................................. IV 表目录 .................................................................................................................................. IV 第一章 绪论 .......................................................................................................................... 1
1.1 研究背景与动机 ...................................................................................................... 1 1.2 研究的目的与问题 ................................................................................................. 2 1.3 本文的组织结构 ..................................................................................................... 3 1.4 本章小结 ................................................................................................................. 5 第二章 相关文献的探讨与分析 .......................................................................................... 6
2.1 关于项目成功的标准 ............................................................................................. 6 2.2 “项目健康度”相关理论的讨论 ............................................................................. 10 2.3 本章小结 ............................................................................................................... 12 第三章 IT项目管理中健康度评估方法研究 ................................................................... 13
3.1相关案例的讨论 .................................................................................................... 13 3.2 项目管理流程中的关键节点及关键指标 ........................................................... 17
3.2.1 IT类项目管理中关键时间点的划分 ...................................................... 18 3.2.2 IT类项目管理中关键健康度指标的确定 .............................................. 23 3.3 指标研究中的量化方法 ....................................................................................... 26 3.4 健康度评估的工作流程设计 ............................................................................... 28
3.4.1 项目健康度指标的评估流程： ............................................................. 28 3.4.2对项目综合健康度得分的分析 .................................................................. 33 3.5 健康度评估相关工具的设计 ............................................................................... 34 3.6 本章小结 ............................................................................................................... 39 第四章 案例应用研究 ........................................................................................................ 40
4.1 相关应用案例的研究 ........................................................................................... 40
4.1.1 案例1 深圳市某中学IT建设项目 ...................................................... 40 4.1.2 案例2 湖南某电力企业ERP实施项目 ................................................ 45 4.2 针对应用中相关问题的讨论与专家反馈 ........................................................... 48 4.3 本章小结 ............................................................................................................... 49 第五章 结论与未来发展改进 ............................................................................................ 51 参考文献 .............................................................................................................................. 53 版权声明 .............................................................................................................................. 55
III
图目录
图 1 论文结构 ........................................................... 4
表目录
表 1 项目健康度关键指标量化表 .......................................... 27 表 2 健康度关键指标量化表 .............................................. 29 表 3 不同项目阶段的权重表 .............................................. 30 表 4 健康度指标加权分析表 .............................................. 33 表 5 初始阶段关键指标量化表 ............................................ 35 表 6 计划阶段关键指标量化表 ............................................ 36 表 7 执行阶段关键指标量化表 ............................................ 37 表 8 收尾阶段关键指标量化表 ............................................ 38 表 9 案例1初始阶段关键指标评估 ........................................ 41 表 10 案例1初始阶段加权统计表 ......................................... 42 表 11 案例1计划阶段关键指标评估 ....................................... 42 表 12 案例1计划阶段加权统计表 ......................................... 42 表 13 案例1执行阶段关键指标评估 ....................................... 43 表 14 案例1执行阶段加权统计 ........................................... 43 表 15 关键指标的延续与扩散性在案例1中的表现 ........................... 44 表 16 案例2初始阶段关键指标分析 ....................................... 46 表 17 案例2 初始阶段加权统计 .......................................... 46 表 18 案例2计划阶段关键指标分析 ....................................... 47 表 19 案例2计划阶段加权统计 ........................................... 47
IV
第一章 绪论
1.1 研究背景与动机
在企业的项目管理实践中，针对项目的绩效评估是项目管理中的重要工作，传统的项目管理理论与实践也提供了大量的绩效考核工具，比如挣值分析方法，这些方法可以帮助项目经理与企业管理层对项目的当前运行状态有比较清晰的把握，比如项目的当前进度状态、成本分析以及范围内容的完成情况，这些方法被广泛地应用在项目管理实践中。
但是在传统项目绩效评估方式中，各种指标均过于强调反映项目的当前绩效，而没有能够很好地反映项目中长期的发展趋势。事实上，在现代项目管理实践中，有很多项目长期保持良好的绩效，但在一些关键的验收节点上出现了严重的问题，而导致项目的最后失败，所以项目良好的当前绩效并不代表项目最终一定能够取得成功。
随着项目管理技术的发展，出现了很多种新的项目评估理论，更加注重对项目的宏观发展趋势加以分析，试图分析一个项目最终能否取得成功的可能性，比如项目的需求明确程度、工作的可控性、风险控制流程的健全性等等，其中最为著名的就是项目的“健康度”概念。
项目的健康度不同于项目的状态，后者是在操作层面上判断项目的进度、成本、绩效等一系列指标，反映项目的当前进展状况。而前者则在宏观层面上反映了项目的发展趋势以及最终取得成功的概率。在许多项目化管理非常成熟的企业中，管理层往往更愿意通过健康度，而不是状态来宏观地把握项目的运行，确保企业战略目标的实现。
然而如何对项目的中长期趋势加以把握与评估呢？这里需要有全新的理论体系与方法论来加以指导，目前行业内并没有非常完善的理论体系能够对项目的运行趋势进行分析与研究，但在很多大型跨国企业中有一些自有的方法与经验，能够对项目的运行趋势分析提供理论上的指导，比如普华永道提出的“七个关键点”以及IBM的项目“健康度”概念。
1
我们将在第二章中对项目健康度的概念加以详细的解释，并对IBM的项目健康度指标体系进行介绍。这里我们要重点讨论的是，现有的关于项目趋势研究的相关理论更多的是在理论层面的指导性原则，涉及到项目及企业的各个层面，作为一种指导理论是全面的，但却缺乏在操作与应用层面的具体指导，没有能够使之广泛应用的方法论，这也是项目健康度多年来一致停留在理论层面的重要原因。
从另一个层面看，很多IT企业广泛地采用了项目管理机制来运营企业，但IT类项目的一些特点导致项目的成功率相对较低，比如IT项目中需求的复杂性与易变性、高技术手段导致的技术风险、对人的高度依赖性等等，这使得IT类企业迫切需要一种新的管理工具，能够对项目进行宏观的趋势性评估，以建立项目预警机制，提高项目成功率，并实现企业资源的合理优化。
由此，我们希望能够基于现有的项目健康度理论，并通过相应的简化与优化，设计一种具有良好可操作性的评估工具，能够服务于各种类型的IT项目，为IT企业提供一种有效的管理工具，提高IT项目的成功率。
1.2 研究的目的与问题
我们希望这种新的项目评估方法所提供的，不是项目在操作层面的绩效状况，而是能够反映项目在中长期运行趋势的管理评估，这就提出了一系列的问题 （1） （2） （3） （4）
哪些项目中的管理因素能够最终影响到项目的运行趋势？ 如何将这些因素综合归纳成关键的管理指标？
如何对运行中项目的管理数据加以提炼，获得这些量化的关键指标？ 如何对这些关键指标加以理解，以获得项目的趋势性分析？
我们将在后面章节中具体讨论这些问题。同时，由于我们所希望设计的是能够应用在实际IT类项目中的管理工具，所以就必须考虑到这一方法的可操作性问题，以及如何尽可能降低应用中的阻力，这就要求必须将相应的理论体系加以简化与归纳，尽可能地从实际管理应用的角度对相应的理论加以整合，并设计相应的工具，以帮助项目管理人员比较容易地完成对项目的评估。
基于这一思路，我们对相应的理论进行了深入的学习研究，同时对大量真实案例进行研究分析，从众多的导致项目产生各种问题的机制中，归纳总结了5种最为核心的“问题源”，包括项目的Sponsor管理、项目的需求界定、项目工作的可控性、
2
项目风险的可控性以及项目人员及团队的可控性，并以此为基础设计了5个关键的项目健康指标，指标T、指标S、指标W、指标R、指标P。
这一划分方法与IBM较为典型的7个关键点有一定的区别，主要在于将进度和范围整合为指标W，即工作可控，将团队因素与执行机构因素整合为指标P。，之所以做这一变化主要是希望提高这一方法的可操作性。IBM的7个关键点作为一个经典的理论体系，需要较为细致的划分，以说明不同要素的不同特性，但作为一个指导实际操作的方法论，过细的划分方式会导致很多具体问题在操作中不容易界定，加大执行中的难度，而如果将具有较强相关性的要素整合在一起，不仅大大降低了操作的难度，而且对于绝大多数的项目而言，这种划分精度是完全够用的。
除了关键指标的设计之外，还有一个重要的需要研究的问题是健康度评估的流程与工具。由于我们研究的重点是IT类的项目，所以在流程及工具的设计中充分地考虑了IT类项目的相关特性，如高技术因素导致的技术风险、需求的复杂性、对技术人才的依赖等等。在评估方法中必须要充分考虑到这些因素的影响，比如在工具设计中通过专门的权重量化表，强化在项目早期（初始阶段与设计阶段）的需求、业务目标的明确性，而在执行阶段则提高对于技术人才在评估中的权重。
在整个评估方法论的设计中，可操作性是贯彻始终的一个重点，而本文讨论的一个重点，也是如何将一种典型的理论体系，转化为一种可操作、并且易于操作的管理工具。
1.3 本文的组织结构
为了能够较为清楚地介绍项目健康度评估方法论的背景、关键指标、流程、工具以及具体应用，本文按下页结构安排
3
图 1 论文结构
第一章： 绪论
概要性地介绍项目健康度评估的理论体系，以及本文主要的研究工作，也就是如何将健康度评估的理论体系转换成一种可操作，能准确反映项目运行趋势的管理方法论。同时讨论了指导这一工作的主要原则与出发点。 第二章： 相关文献探讨及案例
这一章分为两个主要部分，前半部是对相关文献进行综述与讨论，包括传统的评估机制的基础与应用，以及现有项目健康度理论的现状与构成。第二部分则对若干案例进行了深入的讨论，进一步说明原有项目评估机制的局限性，以及项目中的哪些关键因素对项目的运行趋势与最终成败具有影响。 第三章： IT项目管理中健康度评估方法的研究
这一章重点介绍了项目健康度评估方法的具体内容，包括关键的评估时间点的把握、具体的项目评估指标、评估的工作流程，以及如何获得量化的评估指标。同时本章也介绍了相关的评估工具，可以帮助管理者简化评估过程，提高这一方法论的可操作性。
第四章： 案例应用研究
这一章介绍了几个具体的应用案例，讨论了这一方法论在具体案例应用中所带来的改善、产生的一些问题，以及一些具体的应用技巧，进一步证明了对于IT类
4
项目来讲，健康度评估方法论所具有的特殊价值。 第五章： 结论及未来发展的讨论
作为本文的收尾，这一章总结了项目健康度评估方法论在ＩＴ项目管理中的应用价值与前景，并为这一方法论（包括其理论体系）的未来发展提出了建议。
1.4 本章小结
本章讨论了传统项目评估机制的方法与现状，以及不同层次的项目评估方法的
差别，重点阐述了为什么需要一种新的项目评估方法论，能够在传统的基于绩效的评估模式之上，提供针对项目发展趋势的研究。
同时，本章也讨论了如何将项目“健康度”的理论体系，转化为一种易于操作，并且能够准确反映项目运行趋势的操作方法论，以及在这一过程中的主要原则与思路。
5
第二章 相关文献的探讨与分析
本部分重点收集了与本论文相关的文献内容，重点包含了3个方面，关于项目成功的标准及其演变过程、项目绩效考核的方法及工具、以及在一些大型跨国企业的项目管理实践中有关项目绩效趋势的基本观点及方法论。趋势分析是与项目的绩效考核紧密相关的，而绩效考核则依赖与对项目成功的标准与定义，故这三部分有着内在的联系。有关绩效趋势分析的相关文献较少，而且现有内容基本都是一些原则性、分析性的观点，没有具体的在操作层面的方法。在这片论文中，我将试图通过对项目成功、项目绩效以及项目绩效的趋势研究，归纳总结出一些可以应用在具体项目中的方法，以对项目绩效的趋势加以分析研究。
2.1 关于项目成功的标准
一个项目如何算作成功，人们印象最深的肯定是由Oilsen [1]提出的著名的铁三角理论，这也是因为这一理论被美国项目管理协会采用，并写入到了PMBOK当中。其实在这一体系中所强调的，是项目管理工作的成功，也就是进度、成本与质量的相互关系。[Project Management Institute 2000]
这里应该解释的问题是，很多文献中所谈到的项目成功，指的是项目管理的成功，Da Wit(1988) 提出项目管理成功包含进度、成本及质量、绩效，而项目成功则包含了更为广泛的内容，特别是与项目的干系人相关的视点，“好的项目管理有助于项目成功，但并不能彻底避免项目的失败”，（De Wit 1988, p 64）,或者用一个更加常用的比喻“手术很成功，但病人却死了”
所以对于项目管理的成功和项目的成功用不同的定义： 项目管理的成功：
传统意义上的项目成功更多是指在项目的生命周期内，对项目的成功管理，主要反映在项目的进度、成本、质量这些硬性指标上。
项目的成功：
项目的成功则是一个超出项目生命周期的概念，主要的衡量标准也包括项目在各个层面上的目标，特别是业务上的目标。
6
一个很好的例子是，举世闻名的悉尼歌剧院用了15年的时间才完成，而其成本超过了预算14倍。不论从各个角度讲,按照传统的项目管理理论，这都不能说是一个成功的项目，但是作为一个伟大的建筑与工程学杰作，作为一个著名的地标性建筑，我们又完全可以把它称为是一个成功的项目[4]（Baccarini 1999）
按照相关的理论，项目经理的职责只局限于项目的生命周期以内，而不会对项目结束之后的事情负责，这样的项目经理的职责仅仅在于项目管理的成功上[5] (Wateridge 1998), 而这往往是导致客户满意度下降的一个重要原因，而这对于IT类的项目是更为重要的。这种对于项目成功的较窄的定义很大程度上制约了项目团队的工作，使项目团队没有与业务部门紧密配合工作的动力，为了完成项目而完成项目，往往忽略了项目本身的业务目标。
而如果从一个更为宽泛的视角来研究项目成功，则必然会产生出了时间、成本、质量之外的更多的衡量项目的业务指标，也就是 CSF （关键成功指标），这些指标不是仅仅在项目的生命周期内部，而更多地包含了相关干系人的满意度、项目的业务目标的大程、项目的产品与服务是否能够为客户所接受等等因素，可以更全面地对项目的成功进行衡量。
按照KamJugde和 Ralf Muller的总结 [6]，我们对项目成功的理解可以分为4个阶段：
阶段1： 项目的实施与移交（1960–1980）
在这一阶段，人们对于项目成功的定义采用一些非常简单的指标，比如项目的进度、成本、与质量。这些指标易于计算与使用，而项目经理的职责主要在于项目的“完成”，以及确保项目的产品能够工作，可以被客户接受。也是在这一阶段，著名的铁三角理论被提出并且被广泛地接受[7]（Atkinson 1999）、[8]（Cooke-Davies 1990）
由于这种项目成功的定义是基于项目的生命周期，而不是产品的生命周期，所以在这个模式下，客户满意是一个非常难以衡量的因素，人们试图将客户满意、整个项目的成功与铁三角理论整合起来，比如强调应如何帮助客户了解自身的需求，如何通过软技能提高与客户的沟通等等手段，使得项目管理的成功与更大意义上的项目成功相统一，但这些努力仍不能很好地解决这些问题。
7
阶段2：CSF（关键成功指标）清单 (1980–1990)
在这一阶段，项目的成功被定义成了一系列关键成功指标的完成，“必须被正确
完成的事情” [9]（Kerzner, 1987, p32）。相关文献的描述更加注重与干系人的满意程度，项目完成的指标也从“我们完成了”转移到“我们很满意”，这也是与原有项目成功概念的一个巨大的区别。
Bounds 在1998年提到：“一个成功的项目应该包括员工的培训与教育、专门的资源、良好的工具、坚强的领导与管理，以及与项目执行同步的个人、团队、组织的提高”
这里面的重点在于我们从宏观还是微观上来看待一个项目。微观的视角之关注于项目工作的完成，而宏观的视角则扩展到在产品的生命周期中去评估客户的满意。而铁三角中所描述的项目承包、进度、质量指标依然是对项目的重要衡量，但已经不是唯一的指标。
基于这样一种理念，不同的人往往给出不同的项目成功标准，而其中很多是非常有代表性的，比如 Clark 的CFS 指标 [11]: “有效的沟通、清楚的目标与范围、将项目划分到可管理的模块、使用项目计划作为实时的项目文档”
第二阶段的特点是有大量的CFS指标被提出并被广泛的应用，但并没有形成完成的体系框架，特别是与项目管理的方法论相配合的体系。
阶段3：CSF框架体系 (1990–2000)
在上世纪90年代，出现了大量的文献试图建立一个关于项目成功的框架性标准，其中一些主流的出版物中关于这一问题都非常注重两点，即项目的成功是高度依赖于项目干系人的，项目的成功高度依赖于项目团队与接受组织间的互动。[12] (Lester, 1998)
最为先驱的要数 Morris 和 Hough，他们基于对大量实际案例的研究，首先将项目成功的前提条件进行了分组：
项目功能： 项目是否满足了财务及技术需求? 项目管理： 项目是否满足了成本、进度及质量要求？ 下包商： 项目下包商是否获得了他们需要的利益？
8
项目终止： 当项目不得不被取消时， 这一决定是否合理及有效？
Morris 与 Hough 开发出了能够预示项目成功的合理的框架，其中包括人员的态度、项目的定义、外部因素、财务、组织、合同策略、进度、沟通、控制、人员素质、资源管理等等。
在同一时期还有许多人开发出了不同的CSF框架，但均无法与 Morris 与 Hough相比拟。
但是Cleland 与 Ireland [13] (2002)的观点则相对不同， 他们认为项目的成功应该从两个维度上加以考虑，一个是项目的技术目标是否达到，另一个是项目的业务目标是否达到。后来有人基于此做了进一步的扩展，既第三个维度，客户组织的满意度。
另外一个著名的 CSF 来自 Pinto [14] ，这一CSF就是非常有名的10 CSF 清单： 项目目标、高层管理者的支持，项目进度计划，客户咨询、人员、技术对项目的有效支持、客户介绍、监控与反馈、沟通渠道、问题解决技能。其中某些CSF被划分为计划类，而其它的被划分到战术类。然而所有这些CSF 依然只是在项目的生命周期之内，成功被解释为项目被成功地完成，而项目管理工作有合理的运用。
阶段4：策略性的项目管理 （21世纪)
在这一阶段，人们认识到项目管理成功是一个相当复杂的概念，最少包括以下一些方面：
(1) 项目成功不只有一个通用的标准，高层管理者要给予足够的支持、资源与授权以保证项目成功。
(2) CSF的执行需要高层管理者的支持与授权
(3) 项目的成功与组织和外部环境有很大的关系，包括政治、经济、社会、技术的、自然的、客户的、以及市场竞争、下包商等等因素
(4) 执行组织的高层管理者有直接的责任，保证项目的目标与组织的计划与目标保持一致。
Turner 在2004年将其进行了归纳 [15] (Turner 2004):
(1) 项目成功的定义必须在项目开始前获得所有项目干系人的认可，并且在项目的每一个关键时间点再次获得确认
9
(2) 在项目经理与项目Sponsor之间，必须建立起合作性的工作关系 (3) 项目经理必须有足够的授权在一些不可预见的情况下做出灵活的处置，依据是他们对于项目状态的理解，而这种理解来自项目Sponsor 所给出的指导。
(4) 项目的Sponsor必须能够从项目的绩效中获利
在这一个阶段，对于项目成功的最核心的认识是，项目必须与组织的长期目标与计划相一致，使得组织可以从项目的绩效中获利，而组织也将给予项目足够的资源、授权，保证项目的进行。在这一过程中，项目所在组织的高层管理这有相当大的责任，包括对与组织策略的调整，对项目的引导，以及对项目团队的授权等等
2.2 “项目健康度”相关理论的讨论
我们在前面章节中重点讨论了项目成功标准与绩效考核的发展与演变过程，以及相关的经典文献。在这一过程中，人们对于“项目成功”的理解，有简单地按时、按成本完成既定目标，提升到更为贴近业务目标的关键考核指标，到最后企业认识到项目的成功必须与企业的长期战略目标相一致，这是一个由简单到复杂、由局部到整体的、由短期到长期的转变过程，反映了项目在企业中的地位由简单地完成某一工作，转变为达成企业长期战略的重要手段。
但在这一体系中，笔者认为依然存在一个重大的缺失，也就是不论从哪一个层面来衡量，现有的绩效考核体系完全是以项目“当前状态”为考虑依据的，而没有能够很好地反应项目中长期的发展趋势，而在很多情况下，当前绩效并不能保证项目最终取得成功，因为很多潜在的不确定因素并不能在项目的早期就很好地反映出来，所以往往被项目管理者所忽略，而当这些问题出现时，则已经对项目造成了严重的影响，而且难以挽回。
作为项目绩效考核体系的重要补充，笔者认为在现有项目绩效考核体系以外，应该将项目运行趋势作为一个重要的项目考核指标，而这样一个指标在项目管理过程中，特别是在项目运行的初期，对项目管理者而言应该有更大的参考价值。但项目的趋势如何衡量？什么样的指标能够综合性地反映项目不同层面的问题？显然目前的项目绩效考核工具无法达到这一目标，如同赢得值系统可以很好地反映项目当前绩效一样，我们需要另一套量化的指标体系来衡量项目中长期的运行趋势，也就是项目的“健康度”。
10
笔者研究了大量现有文献，认为目前针对项目管理的相关文献中，并没有完全针对“项目趋势”进行讨论的论著，也就是说在这一领域缺乏成熟的理论框架与基础。但笔者在以往的项目管理实践中发现，很多跨国企业在这一领域进行过很多有益的实践，并且积累了相当的实践经验，可以说项目“健康度”的概念完全来源于实践，所以笔者在研究过程中大量参考了相关企业的有关资料，比如普华永道的项目七个关键点，以及IBM的相应管理方法，这也是本文进行相关设计工作的一个重要参考依据，下面笔者尝试对现有“项目健康度”的概念进行归纳。
在项目健康度概念中，管理者认为项目的健康与人的健康具有类似性，人的健康往往通过具体的生理指标加以衡量，而项目的健康也体现在一些关键的管理指标上。 在健康度理论中一般从七个层面来对项目健康进行检查与判断。这七个层面包括干系人、项目范围的控制、进度的可控性、项目目标的清晰性、风险的认知、团队的士气以及执行机构的利益。这七个关键指标构成了项目进展的红绿灯，直接反映项目的整体趋势和最终成功的可能性。
与项目状态不同，这七个指标反映的是项目的本质。“干系人”在项目中有不同的利益与目标。协调一致的干系人利益直接决定了项目团队的执行能力，以及对项目方向的宏观把握。反之则会带来各种负面影响，如消极怠工、缺乏资源、得不到管理层支持等等。“项目范围”直接构成项目的基线，其与“进度”的控制紧密关联。有很多当前状态良好的项目却从开始时便注定要失败，原因就在于范围定义的不清晰，以及进度的不可控性。有很多看似合理的协议条款，比如“满足用户应用需求”，最终成为项目失败的根源，其原因便在于其的不可操作性。而过于先进的技术、不熟悉的供货渠道等原因，直接导致进度的不可控性。
对“风险”的管理直接反映了一个企业在项目管理上的成熟程度。积极、主动、有计划的风险管理可以在最大程度上将项目的不确定因素转化为确定因素，并为未知的风险预留足够的资源。而未知风险会比已知风险对项目成功造成更大的威胁。企业以及项目团队对风险的重视程度，以及应对的计划性都直接影响项目最终成功的可能性。
另一个重要的指标是关于项目的业务目标。任何一个项目都有其存在的必要性，而这一根本因素在项目执行的过程中也不是一成不变的。对这一目标的共同理解可以直接影响团队的工作重点，计划的制定以及技术方案的选择。最为典型的例
11
子是，过于追求技术的先进性经常会背离业务目标的需要，导致不必要的成本提高和风险的增加。
团队士气同样是项目经理必须关注的重要指标，一个缺乏信任，没有有效沟通的项目队伍是很难应对复杂的项目需求的。最后，项目执行结构的利益应该被充分重视，这包括了项目团队、下包商、供应商、以及其它合作方。除经济利益外，技能的培养、经验的积累等等都应被充分的考虑。
对这七个健康度的评估应该贯穿项目始终，从启动阶段直到收尾阶段，公司管理层都可以通过这一手段有效地跟踪项目进展，判断项目是否有机会最终在业务目标、进度、成本等各方面都取得成功。它所构成的系统如同汽车的仪表盘，当驾驶汽车行进时，除了正常驾驶以外，还应该通过仪表盘关心汽车本身的状况，而这恰恰是能否最终到达目的地的根本保障。
以上谈到的关于“项目健康度”的相关概念，来源与企业的应用实践，反映了在项目管理实践中管理者所关注的不同层面。但这一体系目前并没有形成相应的方法论，也并不存在量化的工作可以帮助管理者对相关的指标进行衡量。同时笔者认为，为了能够对影响项目趋势的指标进行量化衡量，也非常有必要对指标体系进行重新设计，以是其能够通过标准的“工具”与“流程”进行管理，这是笔者在本文中所要重点论述的。
2.3 本章小结
本章通过对相关文献的整理与综述，简要回顾了项目成功与项目评估机制的发展过程，包括传统的基于“铁三角”的项目绩效模式与基于关键成功指标CSF的项目评估机制。
同时在这一章中笔者重点介绍了目前在项目管理体系中所不能很好把握的“项目运行趋势”，也就是项目健康度的概念，并对这一概念的原理、现状与企业应用进行了相关的讨论。
12
第三章 IT项目管理中健康度评估方法研究
基于前一章中对相关理论的综述，我们在这一章中将首先对两个案例进行讨论，找出实际项目中有可能影响项目运行趋势的问题，然后试图建立一个相对标准的项目健康度指标体系，以及相关的工作流程、方法与工具，对项目的运行趋势进行一定的分析与预测。
笔者的这一工作是建立在相关案例研究的基础之上的，在这一过程中， 重点完成了以下三方面的工作：
项目健康度评估的流程与关键时点定义 项目健康度关键指标体系的确定 项目健康度量化方法与工具的设计
3.1相关案例的讨论
在本论文的前期调研阶段，我们访谈了20余个典型IT类项目，其中包括开发型项目、系统集成型项目、以及咨询类项目，从中找出在项目管理当中的一些具有明显共性的典型问题，这一类问题本身在项目运作中并不会对项目立即造成严重的影响，但在项目后期往往会产生严重的后果。
我们在对大量案例进行分析后可以发现，在很多项目中导致项目陷入困境的因素是非常类似的，尽管其结果及表现形式非常不同，我们在这里选择了两个非常有典型性的案例进行讨论，并试图归纳出某些具有代表性的项目潜在问题。
案例1： 广东省某医院病患随访系统
2006年，广东中山市某 医院与广州中山医科大学合作，讨论建立出院病人的信息随访系统，其第一期工程由广州市某软件企业承担，开发时间将近半年，目标是在2007年春节前建立起一个能够进行试点运行的系统，能够进行初步验收，同时了解这样一个商业化运作的系统能否有较好的市场接受度，以及医院内部的各部门能否整合资源，很好地配合这一系统的运行。
项目在初步系统设计阶段的一个主导思想是，这是一个尝试性系统，重点在于整
13
合院内各部门资源，尝试新的业务流程，并不是医院内当时最为主流的关键业务系统（HIS），同时甲方在给项目上的投入并不大，并且进度要求很紧，故在方案设计中采用了较为简单的2级架构设计，以及一个较为简单的数据库系统，没有考虑到与 HIS系统的对接。
该项目在整个设计与开发阶段均比较顺，过程中只有一些细节性的变更，但总体进度基本上满足要求，并且在2007年春节后完成了初步的功能性验收，但这时候客户并没有认可项目的完成，而是要求该系统直接上线运行，并在所有出院病人中进行推广，导致访问量迅速提高，这时由于系统在设计中并没有考虑到多科室及大量病人的实时访问，导致产生系统瓶颈，性能急剧下降，并经常性产生系统崩溃。
为解决这一问题，项目团队又进行了3个月的努力，对系统进行了全面改造，最终是性能达到客户的要求，但项目整体进度严重延误，成本远超预算，并导致了客户推迟付款。
项目问题分析：
通过对该项目的分析，我们可以明显地发现几方面的问题：
1. 对于客户在项目中的“业务需求”没有清楚地了解，而只是停留在项目需求上，从而影响对项目重要性及项目范围的判断。
我们在谈到客户需求的时候，往往只是简单地理解为“用户希望我们做的工作”，所以整个需求分析过程经常只是基于与用户间的书面协议，或是会议形式的几次简单沟通，就将客户的意见加以总结，形成所谓的“客户需求”，而没有真正花精力去理解一个重要问题，就是“用户为什么要做这个项目”，而这一问题的答案往往是比较复杂的，并不完全是表面上的原因。
在该项目中，由于国家医改工作的展开以及医药分离的政策，使得以往主要通过药品挣钱的医院开始重视病人的满意度，但由于医院多年以来形成的既定工作模式，医改工作的推进是非常缓慢的，所以这种转型也是需要相当长时间的。但在这过程中，类似病患管理管理这样的系统往往作为医院的“政绩”加以实施，虽然短期内不会是医院的主要业务方向，但在某些特定场合下同样是非常重要的。
2007年初，广东省的若干2线医院开始采用了这样类似的系统，并在行业内部产生了一定的影响，这使得本项目在医院的高层得到了重视，并以很大力度在医院内部加以推进，使得该系统不得不面临很大的访问量，导致性能的显著下降。
14
表面上看，这一项目开展的原因是改善医患关系，整合内部资源与流程，并不是医院当时的主流业务。但如果比较深层次地去理解，这一项目在一定程度上代表了医院的企业形象，影响它在行业中的地位，所以被客户所高度重视。由于对这一问题的理解不充分，在考虑技术方案时没有充分地考虑到系统将来运行时可能遇到的真实环境，导致出现了严重的性能问题。
2. 对于验收条件的不清晰，使得对工作的进度无法控制。
项目中的另一个问题， 是合同文档中对于验收条件没有非常清晰的定义，导致在验收过程中产生分歧。
项目中验收条件的描述包括相关功能的实现，并完成相关的业务测试，但并没有非常清楚地说明业务测试的环境、条件以及采用什么样的数据进行压力测试，这使得测试过程中双方各自坚持自己的标准，无法达成一致。
在项目管理中的一个重要基准，就是对于“项目完成”的描述，也就是对于项目范围的边界描述。对于项目完成的描述应该是非常清晰、可操作、和没有歧义的，对于验收中的所有细节在相关文档中都必须有非常清楚的描述，包括验收的项目、条件、环境、方法、流程等等，保证项目各方对于项目本身的认识是在同一个起点上。
只有对于项目的范围有一个清晰的认识，项目的相关计划工作、包括项目的进度、成本、风险等等才是有依据的、可信的，否则所有这些关键基线在项目运行中都会面临巨大的变更风险。而最为严重的是，往往一些关键的分歧不会在项目运行过程当中体现出来，而是在项目接近结束的时候才会对项目造成影响。这时候对于项目的管理者而言，已经没有足够的资金、进度余量来处理这些巨大变更，从而导致项目进度延误、成本超支，甚至导致项目最终的失败。
3. 没有清晰的风险管理规划，进一步加大了工作中的不确定性，包括成本及进度。 在于项目经理的访谈中我们发现，在该项目的启动阶段，曾经对项目的整体风险有过讨论，其中特别谈到了这种系统架构在高负荷下可能产生的各种问题，但由于没有同甲方进行认真的沟通，使得这种担心始终没有进行确认与落实，也没有形成规范的风险应对方案，导致最终造成了严重的影响。
在所有导致项目失败的问题中，绝大部分都或多或少地与项目的风险控制机制有关。风险管理中的几个关键要素，包括风险管理计划的制定、风险的持续分析与跟踪、风险应对机制、风险的专人负责等等是同等重要的。在本项目中，项目初期对性能问题
15
有过讨论，也就是说项目管理者能够意识到在这方面的不确定性，但却没有能够将其做为项目风险而进行系统地分析，没有专人负责与客户沟通，没有指定相应的应对策略，导致问题产生后没有很好的办法加以处理，是一个典型的风险失控的状况。
案例2： 校园信息管理系统开发项目
2006年，深圳市朗瑞斯科技与深圳市某区教育局合作，开发中小学学生信息管理系
统，实现教学管理的规范化。该项目由教育局出面协调，由福田区某小学作为试点学校，参与项目组，提供开发测试等应用环境。
该项目预计开发时间为10个月，在2006年底之前完成，项目经理有5年以上软件开发及项目管理经验，但早期的开发团队基本由应届大学毕业生组成，缺乏实际开发经验。
项目早期进展顺利，项目团队用3周时间在试点学校进行了需求分析及业务流程设计，与学校各教研室、各部门进行了广泛地沟通，设计方案基本上获得了认可。在项目开发阶段早期，由于开发人员缺少相应的经验，项目团队用了较多的时间熟悉开发工具与环境，以及协调开发流程，进度明显落后于计划。
但真正的问题出现在第一个关键里程碑验收，试点学校的校长认为该系统虽然实现了基本功能，但未能很好地达到管理的目的，特别是不能与教育局的原有系统相兼容，而要解决这一问题则需要更大的投入，对原有系统做重新规划。
之后的大量沟通工作中发现教育局以及各学校对这一系统的管理功能有很大分歧，需求差异性很大，希望最终产品能够满足所有学校的要求基本是不可能的，而短期内教育局也不可能出台规范性的要求，统一各学校的管理流程，在经过很长时间的大量沟通之后，该项目重新定义为针对核心模块的开发，而在不同学校进行分别的定制，以力求满足多数学校的需求。
该项目最终完成用了将近1年半的时间，为完成该项目重新进行了人员的招聘，成本比原先计划至少超出了一倍。
项目问题的分析：
1. 对项目干系人的定义不清楚，导致初期需求分析存在重大偏差。
该项目表现出来的问题是由于需求分析的重大偏差，导致工作严重不可控，然而如
16
果进一步分析，本案例中真正的问题所在是在项目初期未能对项目中的重要Sponsor进行定义，并进行恰当的管理，导致项目中的关键需求得不到准确的认定，多方之间的关系也无法进行协调，这是直接导致项目大幅度超支与延期的原因。
2. 项目团队人员技能有明显缺陷。
同样由于项目需求分析中存在的问题，该项目在启动时未能很好地定义们团队的人员技能需求，导致在项目的初期就出现了进度滞后，而后由于项目的大量变更，导致项目团队的技能更加不能满足需求，不得以进行了大幅度的调整，使项目成本进一步地超出了初始预算。
上面两个案例具有相当大的代表性，在许多IT类项目中都会存在类似的问题，我们通过对大量案例的分析，认为导致项目趋势性问题的潜在因素主要存在于以下几方面：
（1） 对项目需求没有充分地分析 （2） 对项目业务目标缺乏深层次的理解 （3） 项目风险把握中没有良好的机制 （4） 项目团队缺少必要的技能 （5） 项目团队不良的士气 （6） 项目工作的不可控
（7） 对项目的Sponsor 缺乏清晰的定义及持续的管理 （8） 对相关各方的利益关系及目的缺乏了解
以上这些因素本身存在很强的相关性，某些因素是根源性的，某些是衍生的，而在不同项目中根源性的原因相当不同，在下一章中将重点对这些因素加以分类整理，试图建立一个框架性的指标体系，能够对项目进行衡量。
3.2 项目管理流程中的关键节点及关键指标
通过对上述案例的分析，以及对项目管理流程的研究，我们认为在项目管理的过程中应有几个关键的时间点，需要对项目的整体健康程度进行检查与分析，以确保项目能够最终取得成功。
这里所谈到的项目健康度分析，并不是指项目的直接绩效，而是对项目长期运行趋
17
势的一种分析，也就是项目能够最终取得成功的概率。项目的当前状态表现的是项目的绩效，这往往是项目目前阶段的表面状态，而项目健康度则在更高层面上对项目进行观察，分析其关键的健康度指标，判断项目中是否有一些潜在的问题，这些问题虽然当前并没有很明显地表现出来，但最终会对项目的运行产生关键的影响。
根据对大量案例的分析，以及一些相关理论的研究，我们把在IT类项目中一些比较关键的项目指标加以总结，并按照项目运行的关键时间点加以分类，从而试图得到一种能够在IT类项目管理中可以具体操作的评估方法。
3.2.1 IT类项目管理中关键时间点的划分
在考虑如何安排项目管理中对项目进行健康度分析的关键时间点时，有如下几方面的情况应该加以考虑：
1．通常项目管理的生命周期包含初始阶段、计划阶段、执行阶段及收尾阶段四个主要阶段，而IT类项目由于其一些特有的特点，比如技术含量较高、用户需求复杂、市场变化快等等，我们一般更加注重在项目需求分析及计划阶段的投入。在每一个项目管理的生命周期中，都应该进行相应的健康度分析。
2．在关键时间点的划分上，除了项目管理的自然属性外，同时要考虑到管理工作的时间跨度，也就是基于“汇报周期”进行健康度的分析，如果在项目管理的某一个生命周期中，如项目计划阶段，时间跨度超过了4个汇报周期，则需要进行两次以上的健康度分析，以保证相关分析的真实性。
3．同时还要考虑的因素是，对项目健康度的评估，应该同时考虑到项目当前的绩效状况，如果项目某一方面的绩效发生问题，往往代表项目中出现了一些严重的问题，在对项目绩效进行分析的同时，也应该对项目整体的健康度进行分析，这样才能保证解决表面问题的同时，能够对一些根源上的原因进行分析及处理。
4. 另外，当项目中出现某些异常情况时，比如大量的人员变动、客户变更增多时，应该在必要时对项目的健康度进行整体评估，确保所有潜在的问题能够被及时发现并相应地进行处理。
据此，我们将项目中的健康度分析关键时间点做如下划分： 1. 固定的健康度分析
（1）在项目的需求分析阶段将要结束时
18
需求分析工作是整个项目管理工作的开始，也是所有项目管理工作的重要基础，在需求分析阶段的后期进行项目的健康度评估，其主要目的就是确保需求分析工作是充分的且足够深入，评估重点包括：
1) 对于项目的业务目标是否非常清晰？
2) 该项目能否为客户企业及执行方企业带来价值？ 3) 项目工作是否是可控的？
4) 项目参与各方间的利益是否协调？
5) 对项目的风险评估是否表明该项目值得投入？ 6) 管理层是否对项目的风险有足够认识？ 7) 协议中的工作定义是否清晰？ 8) 主要干系人对项目的理解是否一致？ 9) 团队的角色定义是否清晰？
10) 企业是否有足够的技能来完成相关工作？
（2）在项目的计划阶段将要结束时
在项目的计划工作基本完成时进行健康度评估，其关键评估要素包括： 1) 项目的计划是否有益于项目的业务目标？
2) 计划中对于如何达到项目目标是否有充分的考虑？这一过程是否可控？ 3) 对进度的预估是否合理？进度是否“适当的”紧凑，但避免了不必要的压力？ 4) 对项目执行机构在项目中的利益是否有充分的了解？ 5) 计划中是否考虑了风险因素？ 6) 风险计划中的风险项是否有专人负责？
7) 合约中是否对项目的范围与方案、角色与责任、可交付成果与完成日期有明确
定义？
8) 范围定义是否有明确的衡量标准？是否不存在误解？ 9) 范围定义中是否包含了产品的范围以及项目管理工作的范围？
10) 是否所有重要干系人都认可项目计划？包括正确性、可操作性、符合业务目
标？
11) 主要的项目 Sponsor 是否对项目的投资回报分析满意？
19
12) 项目是否有清晰的人员需求定义？是否有足够的具有合理技能的人来组成项
目团队？
（3）在项目的执行阶段每四个汇报周期完成时
在项目的执行阶段的健康度评估可以帮助项目管理者在监控项目的日常运行的同时，对项目的发展趋势及项目中开始出现各种潜在问题及时地发现，并做出有效地相应，避免严重问题的发生而影响到项目目标的实现。这一阶段主要的评估要素包括：
1) 项目的业务目标是否有变化？
2) 项目中的各管理计划是否被有效地沟通和执行？ 3) 是否所有的管理活动都在项目管理计划之内？ 4) 能否有效地监控项目的时间和进度?(与基线的偏差) 5) 各项目参与组织是否均对项目满意？
6) “经验获得与分享”机制是否有效的建立和运作 7) 风险管理计划是否被有效的沟通和执行？ 8) 风险是否被正确的监控和有效的更新？
9) 范围管理计划（包括下包）是否被有效地沟通和执行？ 10) 干系人管理计划是否被有效地沟通和执行？ 11) 团队是否有所需的技能及良好的士气？
12) 团队管理计划（团队建设、激励 „）是否被有效地沟通与执行？
（4）在项目收尾阶段开始时
在项目收尾阶段，对项目健康度的评估同样是非常重要的，这种重要性体现在两个方面，首先，在收尾阶段刚开始时（项目正式验收之前）的健康度评估可以帮助项目团队对项目的运行进行自查，对于发现的问题依然可以进行及时的处理与补救。第二，对于所有项目管理工作而言，形成项目的经验知识库都是非常重要的，如果一个项目中的经验不能很好地传递给今后的项目，从项目管理的角度来说就不能认为是一个成功的项目，而这个阶段的健康度评估本身所获得的经验与教训本身就是知识库中非常有价值的内容。
这一阶段健康度评估的关键因素包括：
20
1) 主要资助人（Sponsor）是否认可项目所实现的“业务目标”？ 2) 所有可交付成果是否按时完成？
3) 对执行组织（下包 „ )的财务结算是否完成？ 4) 利润分析是否证明项目是盈利的？ 5) 项目经验是否被正确地记录和分享？ 6) 风险是否被正确的监控和有效的更新？ 7) 是否所有事先定义地项目接受条件均得到满足？ 8) 是否得到正式接受项目的书面认可？
9) 是否正确评估该项目对“干系人”的价值，并与干系人进行有效地沟通？ 10) 团队成员是否被很好的安置？ 11) 绩效评估是否准确地完成？
2.临时性地健康度再分析
在项目运行的过程中，当某些特定情况或事件发生时，应当对项目重新进行健康度的评估，以确定项目的运行是否受到明显的影响，是否存在某些潜在的因素对项目的目标产生影响。
通过对大量的实际案例的分析以及项目经验的总结，我们认为在如下几种情况下应到考虑对项目的健康度进行再评估：
（1）项目出现连续3个里程碑事件没有按时完成。
项目运行中的里程碑事件没有按时完成往往有多种原因，一般可以通过技术性的分析加以研究。但如果在项目中连续出现关键里程碑点的延误，则应该怀疑是否存在某些系统性的因素导致出现这种问题，这个时候进行健康度的评估是非常必要的，有助于对项目中各种潜在问题的深入分析。
导致这种情况的某些可能原因包括，项目团队问题，如团队士气、人员技能等等，工作计划的问题，对项目工作的分解与计划不够合理，使项目的实际进展与项目基线产生偏差，干系人问题，如与客户方的沟通存在障碍，缺乏客户方的有效支持等等。
但在启动评估前，应排除某些可能的技术性因素导致此类问题的发生，比如某个明显的技术障碍、明显的外部条件问题导致的短期性问题等等。这些操作层面的问题可以通过正常的项目分析手段加以分析与解决。
21
（2）项目人员在短期内出现较大变化。
当项目中出现较大的人员变化时，对项目重新进行健康度评估是非常必要的，这包括两方面的原因：
第一： 人员变化是因为什么发生的？ 如果是因为项目本身的问题导致大量人员变化，则说明项目本身在干系人利益或相关机构利上存在严重的问题，而这些问题是必须加以解决的，否则项目必然在项目的后续运行中产生更为严重的问题。
第二：人员变化本身对项目的运行会产生什么样的影响？这个问题并不完全是一个技术层面的问题，从宏观层面上看，人员变更导致相关干系人间的关系变化，必须重新对项目的整体健康度重新进行评估，以确保新的干系人利益被充分地
了解。
所以，当人员产生较大变更，或关键干系人出现变更时，不论是由于何种原因，重新进行健康度评估都是必须的。
（3）项目的重要Sponsor 对项目的态度发生改变。
有几种可能的情况会导致项目干系人对项目的态度发生改变，比如：
1) 项目的外部商业环境出现了变化，使得项目本身对于企业的价值产生了变化，
比如上面谈到的第一个案例，就是属于这种情况。
2) 项目Sponsor与项目团队间的沟通出现问题，这往往使得Sponsor 对于项目的
运行不够了解，从而产生了分歧与误解，使得其态度发生了改变。
3) 某些特定的情况的发生，使得Sponsor在短期内的观点发生变化，或是不得不
对其计划进行调整，重新平衡企业的资源分配，导致其对特地功能项目的支持力度发生改变。
不论是由于何种原因，当项目重要干系人的态度发生改变时，对项目本身的影响都是巨大的，这个时候从项目管理的角度讲，必须加强与关键干系人的沟通，并对项目的整体健康度重新进行评估，据此对项目进行必要的调整。
（4）项目中产生的变更超出正常水平，或出现较大的变更请求。
在项目管理中产生的项目变更分为主动变更与被动变更，对于被动性的变更，如市场价格的波动导致成本的波动，从管理的角度讲最重要的就是对相关的项目基线进行调整，并与各方充分沟通以适应新的情况。而对于主动变更，管理者必须严格坚持变更控制流程，特别是涉及到项目范围、成本、进度的变更，必须有严格的审批机制，确保项目的各项目标在可控的范围之内。
22
但是当在一个特定阶段，项目中出现了较多的变更，或较为重大的变更时，则往往意味着项目中可能存在某些潜在的问题没有被充分认识，比如说对用户的业务需求不是充分地了解、对业务运行环境的变化没有充分掌握，或者是对于项目的规划在某些方面存在不合理性，这个时候进行相应的健康度再评估就是非常必要的。
当然，在启动评估过程前，同样应该首先排除某些明显的技术性因素，比如某些不可抗的外部因素等等。
（5）项目由于“非市场”原因导致的连续性的成本超支。
造成项目成本超支的原因同样是多方面的，涉及到外部市场环境、计划的合理性、变更的控制、人员的技能等等因素，所以正常情况下成本超支是可以在正常的项目管理过程中加以分析与解决。但如果出现持续性的，由于“非市场”原因导致的成本超支，则应该对项目本身的一些机制性问题加以评估，比如计划是否合理、团队是否拥有必要的技能等等，而这些因素造成的后果往往是持续性的，必须加以足够的重视。所以当项目出现持续性成本超支时，管理这可以具体加以分析，是否应该启动一个健康度评估过程，以找到项目中的某些潜在问题。
3.2.2 IT类项目管理中关键健康度指标的确定
为了能够以一种相对比较标准的方法对项目的健康度进行分析，我们对大量的案例
进行了研究，也借鉴了某些大型跨国企业中的应用经验，同时结合IT类项目的特点，总结了若干个关键指标，在这个过程中的主要的设计思路有如下几点：
1. IT类项目的特点是技术含量高、需求复杂，故在相应的项目健康度评估中非常重视项目早期的基础性工作，如项目的需求分析、计划过程是否充分，是否有客户方的足够参与等等。
2. IT类项目的运行对人的依赖性非常高，项目的总体成本中人员所占的比重也非常大，所以与团队项目的因素往往会对项目的绩效产生明显的影响，所以在指标体系的设计中更加强调人员及团队的利益与士气能否被充分的认可
3. IT类项目由于采用大量的高新技术，对风险控制的要求较高，所以应该注重技术方案的合理性，这本身要求对项目的业务目标有深刻的理解，而不是仅仅关注技术层面的要求。反映在健康度指标体系的设计中，对项目风险控制体系会作为重点进行评估。
4. IT类项目的工作流程往往比较复杂，不确定性同样比较大，从管理角度讲，对
23
于范围、进度、成本的控制相比其他类型的项目难度要大，所以对于计划的合理性有更高的要求，这也是健康度评估体系设计中的一个重点。
5. 指标体系的设计力求简化，将有相关性的因素加以整合，使得其作为一种评估方法易于操作，减少实行过程中的阻力
6. 将指标体系的设计与项目管理的不同生命周期加以整合，使其在项目的不同阶段有不同的针对性，能够更加客观的反映项目的运行情况。
基于以上思路与要点，将项目管理中的关键健康度指标总结如下，为了易于表达，分别标记为指标 T、S、R、W、P
A. 指标1（T）： 需求清晰、业务目标明确 B. 指标2（S）： Sponsor 的认可 C. 指标3（R）： 风险可控 D. 指标4（W）：工作可控 E. 指标5（P）： 人员与团队可控
（1） 指标T： 需求的清晰与业务目标的明确
指标T所描述的，是项目对于客户需求的分析是否足够深入，以及项目所要达成的业务目标是否足够明确。
这里要回答的几个非常重要的问题 1) 客户为什么要做这个项目？ 2) 我们为什么要做这个项目？
3) 我们（包括项目团队与Sponsor）对于项目需求的描述是否足够清晰？是否双方
都能够认可？
4) 在项目边界的定义上是否存在分歧？
项目需求分析的重要性不仅仅在于明确与客户间的协议、避免分歧，更为重要的原因是，项目中几乎所有的计划基线全部取决与项目的需求，我们采用什么样的技术方案？哪些个工作具有更高的优先级？哪些资源与成本开支是必须的 … 等等，可以说需求决定了项目的全部。而根据以往的项目经验，绝大多数的项目变更，都或多或少的与项目早期的需求分析不彻底有关系，从而导致项目运行中的失控。
另外一个经常产生的问题是，对于需求的描述不够清晰，或者存在各种歧义，比如
24
“对相关人员进行培训”、“系统满足用户的业务需求”等等这些缺乏可操作性的描述，由于这些模糊或没有形成一致共识的需求描述，往往导致项目在后期产生严重的问题。
总之，指标T所反映的，是项目对于需求的明确程度，以及相关计划能否很好地服务于这一需求。
（2） 指标S：Sponsor 的认可
Sponsor 是项目资源的提供者，也是项目中最为主要的客户，有可能来自客户企业，也有可能是企业内部的管理者。对任何一个项目而言，Sponsor 的态度、理解、支持对项目管理者而言都是至关重要的，直接影响到项目的运行。
对Sponsor的管理分为几个层面，包括项目Sponsor 的识别，即如何找到项目中的正确Sponsor，Sponsor的定义，即明确项目中Sponsor 的角色与分工，到Sponsor的管理 也就是与所有重要的Sponsor维持良好的沟通，并保持Sponsor对项目的投入资源的承诺。
当一个项目中的Sponsor管理出现问题时， 往往表现在对项目的需求不清晰、对业务目标不了解、以及在项目运行中无法获得有效的资源支持等等，而这些问题往往在项目早期不会得到足够重视，而在运行中对项目产生重大的影响
（3） 指标R：风险可控
企业项目管理成熟性的一个重要标志，便是其风险控制机制的成熟度，几乎所有导致项目最终走向失败的原因，都或多或少与项目中的风险管理机制有关，这当中包括风险的识别是否全面、分析是否恰当、应对计划是否合理有效、是否有风险责任人、是否有持续性的风险监控等等一系列的内容。
对于项目管理者而言，项目中存在各种各样的风险是必然的，关键在于如何让项目中的风险变得相对可控，不会对项目的运行形成致命的影响，而这靠管理者的个人能力是无法实现的，必然要通过一个成熟的机制加以控制，也就是项目的风险管理方法。
从项目健康度角度来看，任何不成熟、不健全的项目风险控制机制，都是非常重要的不健康信号，对项目而言往往意味着巨大的不确定性，是项目健康运行的隐患。
（4） 指标W：工作可控
25
如何保证项目能够按进度要求完成预订的工作，并且不超出成本预算，是传统项目成功的重要标志，我们把这一目标定义为“工作可控”，也就是如何保证项目能够很好地按照既定的项目计划基线运行，而不产生大的偏差。
在这一健康度指标中，保证项目中的工作可控设计到项目中非常多的领域，从需求的分析、方案的制定，到风险控制、团队建设，几乎所有与项目相关的工作都或多或少地影响到项目工作的可控性。
作为一个项目健康度指标，工作可控可以是由其它引发的问题，也可以本身就是核心原因，必然在方案设计中采用过于先进的技术方案，导致项目技术风险加大，使得项目进展的不确定性增加，影响到可靠性。而更多情况下，工作可控有其它因素引发，但对项目的影响同样是巨大的。
（5） 指标P： 人员与团队的可控
项目团队是项目管理工作的主体，作为一个项目健康度的衡量指标，人员与团队可控讨论的是项目中的人与团队问题，即如何保证项目所有干系人具有项目需要的技能、保持良好的士气，同时愿意对项目做出承诺。
在人的相关领域中，项目经理必须要考虑到干系人的表面需求与内在需求，比如在考虑相关团队的合理收益之外，还要考虑到如技能提升、事业发展、形象改善等其它因素，而在很多项目中这些因素往往是影响项目团队（或合作伙伴、下包商团队）士气的更为决定性的因素。
3.3 指标研究中的量化方法
在本论文的研究过程中，包括设计早期的案例分析与设计后期的方法论应用实践，主要的采样数据为项目管理当中的管理类数据，由于管理类数据的相对规模较小，而且量化的精度也相对有限，故将主要采用定性分析的方法，试图找到众多因素中的关键要素，而重点在于如何针对这些关键因素设计合理的方法与工具，对项目的趋势加以分析。
特别是针对上述5个关键指标的量化方法上，设计工作的主要目的是定性地表现出项目指标在不同阶段的重要程度，从而使得整个指标体系能够很好地反映项目的发展趋势，这里采用一个相对简单且便于应用的定性量化方法，对于所有5个关键指标，其量化取值范围在 0 到 1 之间，不同指标具有不同的描述。
26
有关相应关键指标的量化，这里做一些操作层面的说明： 1.关于坐标体系
上表中的量化采用了线性坐标体系（0.1-0.3-0.5-0.7-0.9），但在具体运用中可以考虑非线性的坐标体系，以体现不同企业在不同层面的策略不同，同时，不同的指标也可以采用不同的坐标体系。
比如，如果企业对项目的需求分析有较高的要求，希望规避由于需求不清所造成的风险，则可以对坐标T采用非线性的坐标，如（0-0.2-0.4-0.8-1），同时将相关的定义加以修正。
对于坐标量化体系中坐标系的定义，给了企业管理层相当大的灵活性，以实行不同的管理策略，这种策略一般有企业高层或项目管理办公室统一制定，在所有项目中实施。
2.关于量化的描述
对于不同的量化描述，上表中给出的是一个标准通用的解释，适用于绝大多数项目的管理要求。但对于某些特定的项目，管理层可以对不同指标的量化定义加以调整，以适应相应的管理策略的变化。
表 1 项目健康度关键指标量化表
指标T 描述 对于项目的客户需求及业务目标的了解程度 Sponsor 的认可 0 完全不了解 0.1 0.3 0.5 多少了解一些，但不足以据此进行项目计划 勉强认可，但不愿意提供相应的帮助 0.7 大体了解，但在计划中仍然有不确定性 大体认可，但对实质性的帮助仍有顾虑 0.9 1 基本上有一些了不了解，解，仍很知道一模糊 点 基本不认可，并有实质性的阻碍 有一定的风险意识，但没有相应机制 不很认可，或态度模糊，行动上保持中立 有较强的风险意识，但无相应机制，风险不可控 基本了解完全、透且足以支彻的了解 持项目计划与管理 基本认可，愿意提供必要的帮助 高度认可与支持 指标S 持坚决反对态度 指标R 对风险的控制 没有任何风险意识与机制 有相应的风险大体可风险机制，控，但仍有但整体不不确定性 确定性仍然较大 风险机制所有风险健全，基完全可控 本可控， 27
指标W 项目工作无任何的可控性 范围描述，工作完全失控 完全没有没有任恰当的人何人员员及团队 及相关技能，团队无法运作 难以描述项目工作，工作无从控制 只有个别人员及技能，无法建立项目团队 项目范围只有一个大致的描述，工作不可控 团队缺乏关键技能，士气低落，无法维持项目正常运行 范围定义模糊，工作的可控性难以预见 团队及人员仅有部分项目所需技能，士气不足，勉强维持项目运行 范围主体大致清晰，工作大体可控，但不确定性存在 团队及人员大体满足项目要求，士气与绩效一般 范围清范围绝对晰，工作清晰，工基本可控 作完全可控 团队及人员的技能基本满足项目要求，士气与绩效良好 具有项目所需的全部人员及技能，团队绩效优异 指标P 3.4 健康度评估的工作流程设计
针对项目的健康度评估流程，是与项目所处的不同阶段有紧密相关性的，在不同的
项目阶段对项目的评估重点是不同的，所采用的评估方法与手段也应该所有区别。在这一部分我们进行流程设计时，所基础的主要指导原则有两个：
1.力求流程的简化与易操作
项目健康度评估是完全应用于实际项目管理过程的方法论，所以过于复杂的评估流程会导致较大的操作难度，也提高了应用中的阻力，所以整个的流程设计以尽可能简化，便于项目管理者实际应用为原则
为达到这一目的，在数据收集层面采用两种比较简单的收集手段，即调查问卷形式或项目讨论会形式，由于这里所需要的数据绝大多数为管理类数据，数据量不大同时数据精度的要求也不是非常高，关键在于真是反映项目的显示情况，故这种方式所的到的数据完全能够满足定性分析的要求。
2.与项目的生命周期相符合
在不同的项目管理周期中对项目有不同的要求，从健康度评估的角度讲其侧重点是完全不同的，所以在这里我们针对不同的项目阶段设计了不同的权重表，以反映项目在某一个特定的阶段的健康度情况。
3.4.1 项目健康度指标的评估流程：
1. 步骤1： 针对项目的5个关键指标分别取值
28
在这一阶段，通过两种不同的方式针对项目的5个关键指标给出量化值： （1）方法一： 调查问卷方式
这种方式主要应用于规模较大的项目，难以将所有人员召集开会。通过调查问卷的方式对所有项目中重要的干系人进行调查，并将他们所给出的分值加以归纳统计，以一般平均或加权平均的方式获得该项指标的最终量化值。
这里非常重要的一点是，必须确保所有项目干系人对健康度方法论有清晰的认识，能够正确地理解每一个关键指标的含义，并且对量化的定义有统一的认识。这需要在项目团队中对相关的方法论进行培训，以保证所获得的数据的真实性与完整性。 （2）方法二： 项目讨论会方式
对于相对规模比较小的项目，或相关的干系人较少的情况，可以通过讨论会的形式对项目健康度的量化部分进行评估。这种方式的优点是干系人间能够有较好的沟通，对不同指标的理解如果有分歧可以及时加以统一，对于项目管理者来讲也比较容易控制。
同样，对于讨论会的方式，项目管理者要保证所有参与的干系人对相关指标的概念、定义有清楚的、相同的认识，及时对不同的观点加以统一。同时，这种讨论会方式中的另一个非常重要的因素是必须保证所有参与者能够畅所欲言，能够听取其他人的意见，但不被其他人的威望、地位所影响，这是保证最终数据可靠性的一个非常重要的因素，也就是需要对团队的表明“一致性”加以适当的管理。
表 2 健康度关键指标量化表
指标T 指标S 指标R 指标W 指标P 干系人1 干系人2 … … 干系人n 最终值
2. 步骤2： 根据项目所处的不同阶段，对关键指标进行加权处理
在项目的不同阶段，项目的不同关键指标具有不同的重要性，而这种重要性要通过不同的权重表进行处理。权重表应该有项目管理办公室或企业管理层统一制定以反映企
29
业特有的管理策略，在这里我们根据一般IT类项目的特点给出一个建议性的权重表，但这里需要强调的是，在不同的项目中（或不同类型的项目中），这一权重的设定应该是不同的，权重的设定直接反映了不同项目的具体情况，应有企业的管理层（项目管理办公室PMO）针对项目特定进行设定，并作为模板在进行健康度评估前下发给相关人员使用。
表 3 不同项目阶段的权重表
初始阶段 计划阶段 执行阶段 收尾阶段 指标T 0.4 0.3 0.1 0.2 指标S 0.2 0.1 0.25 0.5 指标R 0.2 0.25 0.25 0.1 指标W 0.1 0.25 0.2 0.1 指标P 0.1 0.1 0.2 0.1 1 1 1 1
（1）初始阶段权重划分的基本原则：
在项目的初始阶段，最为重要的工作是明确项目的需求，找出项目的业务目标，包括客户企业的业务目标以及执行企业的业务目标，对项目的成功标准形成共识，理清项目中的干系人间的相互关系，明确重要的项目Sponsor，需求他们对项目的承诺与支持。同时对项目的整体风险性进行评估，形成初步的项目管理计划与项目风险评级，对项目进行投入产出分析，及相应的价值分析，判断该项目是否值得投入。
故在这一阶段，一般意义上指标T在整体健康度中占有最大的权值，也就是项目的需求以及业务目标是否足够明确，这是后面所有计划工作的基础。同时，指标S与指标R也有较高的权值，关键干系人对项目必须有足够的重视且愿意为项目做出承诺，是项目能够顺利进行的关键。早期的风险分析有助于决策这对项目的整体风险程度有一个正确的认识，以判断是否值得对项目进行投入。
（2）计划阶段权重划分的基本原则
计划阶段中指标T同样具有最高的权值，在这一阶段的计划工作中必须严格基于对项目业务目标及客户需求的正确理解，保证所有计划要做的工作必须是项目所必须的，而且没有额外的工作占用项目资源。比如什么样的技术方案可以严格地满足客户的业务需求，而又不会带来额外的技术风险，什么样的工作流程可以达到特定的质量要求，又
30
能达到成本最优? 所有这些问题完全基于对项目“业务目标”的深入、客观的理解。
计划阶段另一个重要要素是风险的控制。这一阶段的一个重要产出物是项目的风险管理计划，而这一管理计划是否全面、客观、可操作直接影响整个项目运行中的风险控制，是至关重要的，而这一阶段的风险分析也有助于整个项目的计划过程，使得项目计划更为合理。
指标W在这一阶段有较高权值是因为计划的合理性直接影响后续项目运行中工作的可控程度，许多项目的延误，超支都是由于不合理的项目计划导致，而合理的计划是需求大量的沟通以及相关知识经验的保证，对这一指标的评估有助于项目团队对相关工作的重视。
（3）执行阶段权重划分的基本原则
执行阶段中指标S与指标R具有较高的权重。首先，执行阶段中有可能遇到各种各样的问题，比如资源的短缺、技术的障碍，以及与各干系人间的沟通与矛盾，在所有这些问题中，是否有一个良好的 Sponsor关系是至关重要的，很多时候Sponsor的支持与理解可以在较为困难的环境下为项目创造一个相对宽松的环境，有助于相关问题的解决，相反如果得不到重要Sponsor的支持，很容易使项目的运行走入困境。
项目执行阶段风险的控制同样重要。风险控制的一个原则就是它的持续性，在项目管理的每一个汇报周期中，都必须对项目中的所有风险进行重新评估，讨论相应的应对计划是否可行，针对以及发生的风险造成的影响进行分析，确认是否有二级风险发生，所有这些工作必须有效的完成，才能够保证项目的风险处于可控的范围内，对指标R的考察是对整个项目风险管理机制的一个确认过程。
（4）收尾阶段权重划分的基本原则
在项目收尾阶段的主要工作，除了确认项目工作满足既定的业务需求外，还要确认重要的 Sponsor 对项目工作的满意，这不仅仅是有助于项目的顺利验收，同时更为重要的是保证干系人的满意度，提升企业的形象，为今后企业的业务发展打下基础。
（5）其它影响权重划分的关键因素
影响某一个具体项目关键指标的权重划分因素是非常复杂的，取决与项目的特性、团队的构成、企业的战略、外部环境等大量因素，所以从原则上讲，笔者并不建议在企业中设定过于模板化的权重体系，而应将这一工作留给项目评估的具体执行者，根据具体项目的情况加以设定，以反映项目的具体业务要求。比如对于周期较长的项目，其指
31
标T可以在执行阶段有更大的权值，因为计划过程在执行阶段依然有较大的比重。
（6）权重设定中的相关工具
在前面章节中我们讨论了项目不同阶段权重设定的一般原则与基本因素，这里重点介绍一下在具体工作中可以帮助项目管理者对权重进行划分的工具，也就是AHP层次分析法。
对于某些复杂度极高的项目而言，5个关键指标在项目不同阶段的权重划分会是一个非常复杂的工作，对项目管理者而言最为重要的问题是，如何保证5个关键指标之间的相互关系具有一致性，而在这种情况下，AHP层次分析法将是一个重要的工具。
AHP层次分析法的应用必须是针对某一特定问题的，比如针对某一个具体的项目，5个关键指标间权重的一致性分析，所以笔者并不建议在企业层面对所有项目（或某类项目）通过AHP方法设定标准的权重结构，而是应该针对那些具有相当复杂度的项目，由具体的项目管理人员在项目评估前来使用，以保证权重的设定能够更为准确地反映项目的具体特性。
AHP方法在项目健康度评估体系中应用的要点，是要针对影响项目健康度的5个关键指标，设定指标与指标之间的相对关系，比如指标T与指标S谁更重要，指标P与指标W谁更重要，并要给出量化的差异，这一过程完全依赖项目管理者的经验来设定，然后通过数学方法对这一设定的相互关系进行一致性分析，如果发现偏差过大，则对原始的关系结构进行调整，直到最终的偏差在可接受的范围以内。
有关AHP层次分析法的具体操作细节并不在本文的讨论范围之内，有兴趣的读者可以参考T.L Saaty教授的经典论著 Fundamentals of the Analytic Hierarchy Process, RWS Publications, 4922 Ellsworth Avenue, Pittsburgh, PA 15413, 2000。
3. 步骤3： 计算项目的综合健康度得分
在这一阶段，将项目的各个关键指标进行加权处理后，得到项目的整体健康度指标，并对所有这些指标进行分析，试图找到项目中可能存在的相关问题。
32
表 4 健康度指标加权分析表
指标T 指标S 指标R 指标W 指标P 最终健康度: 权值 量化值 最终值
权值来自各项目阶段的权重表 量化值来自关键指标量化表 最终值＝权值 X 量化值 最终健康度＝各指标最终值之和
3.4.2对项目综合健康度得分的分析
对于项目健康度最终值分析的几个基本原则：
1．当项目的最终值得分在0.7之下时，代表项目中存在较为严重的问题，必须进行认真的分析
对于健康度的各个关键指标而言，0.7均是一个重要的门槛阀值，代表基本处于可控范围，项目可以比较安全地运行。项目的健康度最终值是指标的加权平均，所以0.7同样是一个关键阀值，对项目健康度有指标性的意义。
健康度 > = 0.7 : 项目处于基本健康的状态
健康度 < 0.7 : 项目中存在比较严重的问题，必须加以认真分析，找到相关的问题加以解决。
所有健康度<0.7 的项目，必须引起项目管理者的高度重视，对造成这一结果的相关指标进行进一步的认真分析，有针对性地对潜在的问题加以解决。
2．当项目最终值得分在0.5之下时，项目中存在致命的问题，很难取得最终成功，应建议管理层暂停项目运行，对项目进行重新评估
对每一个指标而言，<= 0.5 是一个存在严重问题的标志，而且这些问题对于项目管
33
理而言是相当致命的，很难保证项目最终能够取得成功。对于经过加权平均的项目健康度最终值，如果 < 0.5 则代表项目的运行整体处于非常混乱、严重失控的状态，项目本身存在巨大的风险，不论当前的状态是否良好，其最终能够取得成功的概率是非常小的。对于这一类的项目，理论上说应该暂停对项目的继续投入，重新进行宏观的评估，对项目的价值、风险、方案的成熟性等重新加以研究，以决定项目是否继续运行。
在某些情况下，对于一些战略性的项目有可能在其初期阶段项目的整体健康度非常低，甚至在0.5之下，但是由于其本身的战略意义，企业依然会选择继续执行该项目。这时候健康度评估的意义在于帮助你对项目本身及项目的运行环境、业务价值进行系统地评估，有助于管理者制定更为合理的策略，提高项目的成功概率。
3．当项目健康度最终值在0.7之上，但有某一分项在0.7之下时，必须启动相应的自查工作以找到问题的原因
如果项目的整体健康度在0.7之上，但某一项关键指标较低，这种情况往往是由于量化值较低的关键指标在项目的当前阶段没有很高的权值，比如在项目的初始阶段中的指标P。这中情况下虽然项目整体健康度可以接受，但并不代表较低的关键指标是无关紧要的，而是同样要引起管理者的足够重视。比如在初始阶段，如果项目的整体健康度为0.8，但指标P只有0.5，这种情况下说明该项目对企业虽然有很高的价值，也有高层的足够重视，但是在操作层面却将会缺乏相关团队及干系人的支持，必然会有很大的阻力，这种问题如果不能在早期很好地解决，对之后的项目运行必然是非常大的风险。所以对于管理者来说，任何关键的健康度指标如果低于0.7，都代表项目中有较为严重的问题存在，必须引起足够的重视。
3.5 健康度评估相关工具的设计
为了能够很好地辅助项目健康度评估机制在项目管理中的实际应用，简化操作难度，减少阻力，我们相应地设计了一套健康度评估工具，可以帮助管理者对项目中的某些管理数据较快地进行量化，并进行相关的统计。
按照设想，我们计划在较为复杂、庞大的项目组织中采用工具软件的方式对相关数据进行采集，但这种系统本身需要同企业自身的项目管理软件兼容，并能够共享数据，工作量较大，并不在本论文的讨论范围之内。这里所给出的是一组基于问卷与 Excel表格的评估工具，对于绝大多数实际项目而言，这些管理工具是完全能够满足管理需求
34
的。
关键指标的量化表：
表 5 初始阶段关键指标量化表
问 题 您是否清楚客户企业为什么要做这个项目？ 您是否清楚您所在的企业承接这个项目的主要目的是什么？ 0.1 完全不清楚 完全不清楚 0.3 基本不清楚 基本不清楚 0.5 大致了解 0.7 基本清楚 0.9 完全清楚 完全清楚 完全可以 完全明确 坚决支持 完全有信心 极充分的评估 肯定能 1 2 T 大致了解 基本清楚 3 您是否能清楚地列出该项完全不目用户需求中的全部工作，能 而且没有任何模糊？ 该项目中的重要Sponsor 是否明确？ S 基本不能 能列出一些 大体知道 中立，不反对 基本可以 4 5 完全不知道 坚决反对 知道一些 反对，但不是障碍 基本明确 基本支持 基本有信心 较全面的评估 能够列出所有重要的 都有过沟通 基本清晰 该项目中的重要Sponsor对项目是否足够支持？ 您是否对该项目Sponsor对项目的持续支持有信心？ 对该项目的风险是否有过评估？ 您是否能清楚地列出该项目中的主要风险？ 项目中的主要风险是否与所有干系人进行过有效沟通？ 您认为项目的范围定义是否足够清晰？ 您认为项目工作的完成是否可控？ 以现有的资源（技能、经费 „ ），您对完成项目工作是否有信心？ 6 完全没有些信心，比较有信有信心 不确定 心 完全没简单的评有评估 估 根本不能 能列出很少一些 有过评估 能列出一些 与个别重要干系人有过沟通 有大体的定义 能有一些控制，但不确定性很大 7 8 R 9 仅做过一从没有 些沟通 完全没仅有粗略有定义 的描述 完全不可控 能有些预测，但非常不确定 充分的沟通 非常清晰 完全可控 10 11 W 基本可控 12 一点没有 完全没有 有些信心，比较有信不确定 心 有较大分歧 有分歧 基本有信心 认识基本一致 完全有信心 认识高度一致 35
13 P 项目的主要干系人是否对该项目有一致认识？
14 您是否认为能够找到有足够技能的人来组建项目团队？ 根本不能 仅能找到一些 可以，但不很确定 基本可以 基本清晰，有较少模糊 完全可以 非常清晰 15 您是否认为与项目相关各完全混团队（干系人）定位清晰？ 乱 较为混乱
不很清晰 表 6 计划阶段关键指标量化表
问题 0.1 完全不是 完全不符合 完全不是 完全没有 坚决反对 完全不会 完全没有 完全没有 0.3 只有一些是 有些符合 0.5 多数是，有些不是 多数符合 0.7 基本是 基本符合 0.9 完全有益 完全符合 非常恰当 充分的沟通 坚决支持 肯定会 1 所有计划的工作是否对“业务目标”有益 项目计划是否完全符合2 T 用户的业务需求 3 采用的技术方案是否“恰当地”支持业务目标 是否与重要Sponsor对项目计划做过沟通 只有个别某些是恰当的，基本恰当 是恰当的 某些不是 只有一些只与个别干系简单沟通 人有过沟通 反对，但中立，不反对 不是障碍 也许会 应该会，但有不确定性 考虑了风险因素，但不全面 都有过沟通 基本支持 会的 4 重要Sponsor对项目计划5 S 是否支持？ 6 项目Sponsor是否愿意为该计划进行持续投入 计划中是否充分考虑了风险的因素？ 7 有一些 比较充分 有比较清晰的风险管理计划 重要风险有专人负责 非常充分 是否有清晰的风险管理8 R 计划 有一些简单的考有，但不是非常虑，但无明确 正式计划 个别风险有专基本没有 人负责 只是有简单的考虑，不可控 只有粗略的描述 有，非常清晰 9 对项目风险是否有专人负责 完全没有 有明确的专人负责 10 W 11 计划是否充分考虑了如何使工作可控？ 对可交付成果的验收标准是否足够清晰，无误解？ 完全没有 有大致的考虑，比较充分，但仍非常不确但仍有不非常充分 定 确定性 只有原则性的描述 基本清晰，完全清晰、个别处有无误解 小分歧 完全不清楚 36
12 13 项目范围中是否充分考虑了管理工作本身？ 干系人是否对该项目计划有一致认识？ 完全没有 完全没有 完全没有 完全没有 只包括了一些 有较大分歧 有一些考虑 包括了一些重要工作 有分歧 只考虑了部分关键干系人 基本包括 认识基本一致 考虑了全部重要干系人 完全包括 认识高度一致 充分考虑 该计划是否考虑了所有14 P 干系人的利益？ 计划所需的人员与角色是否有清晰的定义 15 较为混乱 不很清晰
基本清晰，有较少模非常清晰 糊 表 7 执行阶段关键指标量化表
问 题 项目的运行是否始终与“业务目标”一致？ 0.1 完全不是 完全不符合 完全没有 完全没有 非常不满意 完全不会 完全没有 0.3 只有个别时候是一致的 0.5 多数一致，有些地方存在矛盾 0.7 基本一致 0.9 完全一致 1 2 3 T 项目的运行是否完全符合项目范围的定义 对“业务目标”是否有持续的跟踪与沟通？ 是否与重要Sponsor保持良好沟通 有些符合 多数符合 有过一些沟通 有基本沟通 基本符合 沟通基本良好 沟通基本良好 基本认可 会的 完全符合 始终沟通良好 充分的沟通 非常认可 肯定会 4 只与个别只有一些Sponsor有过沟简单沟通 通 有些不满意 也许会 有一些监控 一般 应该会，但有不确定性 S 重要Sponsor是否对项目5 执行认可 6 项目Sponsor是否愿意为项目运行持续投入 项目风险是否被有效监控和更新？ 风险管理计划是否有效执行 以发生风险是否均恰当处理 7 多数风险可控，但存在不确定基本可控 性 基本执行 基本较好地处理 有效监控 8 R 完全没部分执行 执行的不彻底 有执行 完全没有 完全没有 无法很好处理，较混乱 只作为参考，无法执行 勉强能够应对 严格执行 均有效处理 非常有效地执行 9 项目计划是否被有效执10 W 行？ 大致能够执行，较好地执但偏差很大 行 37
11 是否所有工作都在项目管理计划之内？ 完全不是 计划内工作较少 大体在计划内，基本包含但有大量非计在计划内 划工作 勉强可控，但偏差较大 完全在管理计划之内 12 项目的进度与成本是否可控？ 完全不可控 有较大偏差 基本可控，但存在可完全可控 接受的偏差 有主要的基本技能 士气基本良好 基本有效执行 有所需的全部技能 极高的士气 极好地执行 13 项目团队是否有所需要的技能？ 完全没有 大体有，但仍缺只有一些乏一些关键技相关技能 能 一般 大体执行，但效果不好 P 团队是否有良好的士14 气？ 15 团队建设计划是否很好地执行 完全没士气很低有士气 落 完全没有 较少执行
表 8 收尾阶段关键指标量化表
问题 客户方的业务目标是否达成？ 0.1 完全没有 完全没有 0.3 个别达成 个别达成 0.5 部分达成，勉强可接受 部分达成，勉强可接受 部分完成 大体满意，可接受 大体可控，但有很大不确定性 一般 0.7 基本达成 基本达成 0.9 完全达成 完全达成 1 2 执行方的业务目标是否T 达成 需求分析中的内容是否全部完成 S 重要Sponsor是否对项目满意 项目风险是否可控？ R 风险管理计划是否有效 3 只完成完全没有 很少部分 完全不满意 完全不可控 完全没有执行 肯定不可以 不很满意 基本不可控 作用不大 可能性不大 基本完成 完全完成 4 5 6 基本满意 基本可控 基本有效执行 非常满意 完全可控 前往有效 7 W 8 项目能否正常验收？ 也许可以，但不确定性很大 基本可以，存在个别完全可以 可控问题 均正常完成 是否所有可交付成果都正常完成？ 有一些没有完大量未完全不是 成，但结果可接能完成 受 基本完成 38
9 P 10 项目干系人是否从项目中获益？ 团队成员是否很好安置？ 非常有完全没有 限 完全没有 较少执行 大体有收获，但不满意 一般 重要干系人均基本满意 基本安置 均有获益 极好安置 3.6 本章小结
本章重点讨论了项目“健康度”方法论的设计与构成、包括关键工作流程、关键评估指标以及具体的应用工具。通过大量的分析研究与设计工作，本章重点解决了如下一些问题：
1. 何时及何种情况下要对项目进行评估 2. 对项目中的哪些指标进行评估 3. 如何对这些关键指标进行量化评估 4. 以什么样的流程进行评估 5. 评估中使用何种工具
6. 如何对评估结果进行分析与理解
在所有这些内容中，本章的核心是如何从IT类项目中抽取核心的管理因素构成关键指标，以及如何对这些指标加以量化，并且保证整个过程的易操作性。
39
第四章 案例应用研究
4.1 相关应用案例的研究
4.1.1 案例1 深圳市某中学IT建设项目
这是一个规模较小的IT开发与集成综合项目，项目的目标是帮助深圳市福田区某中学建立校内办公管理系统，并整合该校的网站、博客、论坛等一系列IT基础架构，实现网上门户，帮助学校提升社会影响力，并通过自动化办公提高内部工作效率。
改项目预计工期为10周，从08年7月28号开始，预计10月中旬结束。整个计划中前两周用于需求分析，第三周到第七周为工作流系统的开发，第8、9周网站、论坛、博客上线，管理系统上线测试，最后一周全系统联调、验收。 项目团队中项目经理兼作系统架构师，对此类系统非常熟悉，此人并不仅负责这一个项目，另有两个专职程序员，最后三周时加入一个系统工程师负责系统联调。
我们从该项目的计划阶段开始介入该项目，并将项目健康度管理方法在项目中尝试性地应用，其评估流程由项目主要干系人共同完成，包括开发团队，管理团队已经部分客户参与人员，其评估过程中使用的指标权重表是通过项目管理人员的讨论最终确定的，到目前为止该项目已经完成了两次评估流程，下面是具体的评估结果。
40
表 9 案例1初始阶段关键指标评估
41
表 10 案例1初始阶段加权统计表
指标T 指标S 指标R 指标W 指标P 最终健康度: 权值 0.4 0.2 0.2 0.1 0.1 量化值 0.85 0.77 0.57 0.7 0.77 最终值 0.34 0.154 0.114 0.07 0.077 0.755 初始评估结论： 项目在风险控制方面存在比较明显的问题，但总体处于基本健康状态，项目继续运行。
表 11 案例1计划阶段关键指标评估
表 12 案例1计划阶段加权统计表
指标T 指标S 权值 0.3 0.1 量化值 0.7 0.7 最终值 0.21 0.07 42
指标R 指标W 指标P 最终健康度: 0.25 0.25 0.1 0.57 0.57 0.77 0.1425 0.1425 0.077 0.642 计划阶段评估结论： 项目处于“亚健康”状态，项目中存在较为严重的问题，主要表现在风险控制机制与工作控制上。
表 13 案例1执行阶段关键指标评估
表 14 案例1执行阶段加权统计
权值 量化值 最终值 指标T 指标S 指标R 指标W 指标P 最终健康度: 0.1 0.25 0.25 0.2 0.2 0.7 0.75 0.55 0.57 0.5 0.07 0.1875 0.1375 0.114 0.1 0.609
43
执行阶段评估结果: 项目中存在较为严重的问题，包括风险控制机制，工作控制及团队士气方面，特别是团队士气，在执行阶段出现了较为明显的问题。
我们针对该案例的3次评估结果做了分析研究，同时也同项目团队与项目经理进行了较为深入的交流，得出了几个比较重要的结论。
结论： 当项目早期某项关键健康度指标出现不健康信号时，如果没有及时加以解决，该问题会具有持续性与扩散性，也就是说在后续的项目阶段该问题始终存在，并且会向其它的项目领域扩散。
本案例中在初始阶段，指标R为0.57，表示项目的风险控制机制存在问题，指标W与指标T处于基本健康状态。但是在计划阶段，指标R依然是0.57，同时指标W也下降到了0.57。
那么是什么原因使得指标W下降了呢？具体分析后可以发现，在初始阶段导致R指标较低的一个重要原因，是对项目的整体风险评估不充分，同时没有与相关干系人进行良好的沟通（问题7与问题9），而这一问题没有得到及时的解决，在计划阶段，项目团队认为工作不可控，而不可控的根本原因就是由于风险造成的不确定性，这同时也是导致指标W在计划阶段下降的主要原因。
在执行阶段，指标P也出现了下降，通过事后与项目团队的访谈，我们发现导致团队士气下降有两个原因，其一是项目团队成员大量重复类似的项目，对项目缺乏热情，另一个原因是与客户沟通非常不好，特别是当项目延误之后，导致烦躁情绪出现。这里我们发现，沟通问题在项目早期就已经出现，如果能够及早得到解决，在执行阶段必然有一定的改善，所以我们认为，指标P的下降与早期其它指标中出现的问题有间接的联系。
表 15 关键指标的延续与扩散性在案例1中的表现
指标T 指标S 指标R 指标W 指标P 最终健康度: 初始阶段 0.57 0.755 计划阶段 0.57 0.57 0.642 执行阶段 0.55 0.57 0.5 0.609 44
注：表中列出各阶段中低于0.7的指标，我们发现是逐渐递增的，同时项目的健康度逐渐下降
通过这一分析过程，我们的结论是，项目健康度关键指标如果出现问题且没有得到及时的解决，该问题会持续存在，并且会对其它项目指标产生影响。
对这一现象我从理论上的理解是，项目的运行本身存在一个重要的特性，即所谓的“渐进明晰”性，这一点在PMBOK中有非常大量的论述，也就是说在项目早期，项目本身具有较大的不确定性，风险较大，但项目的可操作性也比较大，这一阶段如果对项目进行调整，往往对项目整体运行有较大影响。所以如果项目中的问题在早期能够及时发现，并做出相应调整，可以最大程度上避免后续问题的出现，相反，如果早期的问题没有及时加以解决，则会在运行中对项目持续造成影响，并造成更加实质性的后果，而这种后果也往往会随着项目的运行不断加大，扩散到其它项目领域，最终有可能导致项目的失败。
在项目运行的中后期，管理者对项目的可操作性在逐渐降低，也就是说这时候出现的问题如果进行修正，会有更大的难度，并且会造成更大的成本损失与进度延误，而有些情况下某些问题可能是无法进行弥补的。这也是问什么在项目早期对项目的健康度进行检验是至关重要的，而这一方法论在这一领域有着重要的价值。 4.1.2 案例2 湖南某电力企业ERP实施项目
该项目是一个标准的ERP实施项目，目前刚刚启动的是第二期工程，第一期在2006
年已经完成，当时在该企业下的一个子公司实施了ERP系统，历时半年。2008年9月该项目第二期启动，有两个项目目标，第一是对一期工程进行产品升级，第二是为另外2家子公司实施ERP系统。二期工程是为该企业最终全面实施ERP做准备。
该项目的项目经理与主要的技术架构师在深圳，需要出差到湖南完成项目，包括需求分析与实施。主要的技术架构师为外聘人员，也是这一ERP系统的主要开发者之一，具有很好的技术背景与ERP实施经验，但与客户的沟通缺乏技巧。
该项目目前刚刚完成项目需求分析阶段，开始项目计划，我们在这一阶段对项目进行了两次健康度评估，分别使用初始阶段与计划阶段量化表，权重表同样有管理人员与部分客户共同确定，评估结果如下：
45
表 16 案例2初始阶段关键指标分析
表 17 案例2 初始阶段加权统计
指标T 指标S 指标R 指标W 指标P 最终健康度: 权值 0.4 0.2 0.2 0.1 0.1 量化值 0.7 0.57 0.65 0.6 0.7 最终值 0.28 0.114 0.13 0.06 0.07 0.654 评估结论： 该项目具有较为严重的问题，虽然可以继续运行，但如果不及时解决将会带来严重的后果。
46
表 18 案例2计划阶段关键指标分析
表 19 案例2计划阶段加权统计
指标T 指标S 指标R 指标W 指标P 最终健康度: 权值 0.3 0.1 0.25 0.25 0.1 量化值 0.75 0.55 0.67 0.5 0.75 最终值 0.225 0.055 0.1675 0.125 0.075 0.6475
计划阶段评估结论：该项目处于不健康状态，在干系人管理、工作控制及风险管理上存在较大的问题。
由于这个项目目前仍处于计划阶段，我们目前还不可能有后续的数据，但以目前的健康度评估结论来看，这个项目处于非常不健康的状态，虽然目前看起来在按进度进行，但如果这些问题不能及时解决，将来存在巨大的风险。
通过对这个项目的进一步分析，我们得出了有关项目健康度指标的另一个重要结论：
47
结论： 项目健康度关键指标间具有明显的相互影响关系
在这个案例中，最为根源的问题是指标S，也就是重要的项目Sponsor对项目不是足够支持，导致项目团队对项目的运行缺乏信心，而同样由于重要的Sponsor没有明确地表态对项目支持，使得项目在工作的控制、风险的分析、计划的制定等等方面存在着巨大的不确定性，这也是指标W、指标R在初始阶段以及计划阶段都非常低的原因。
所以真正的根源原因在于指标S，而不同指标间具有明显的相互影响。如果从理论上对这一问题进行理解，项目的整个管理过程是一个有机的整体，在项目的启动、计划、执行、收尾、与综合控制五个过程间有密切的关联，所以当某一个项目指标产生问题时，必然会通过相应的管理工作传到其它的管理要素上，比如团队的问题会导致质量、进度等领域，而风险控制方面的欠缺更有可能会导致项目最终的失败，所以及时地发现问题并加以解决，是避免风险扩散的唯一有效方法。
4.2 针对应用中相关问题的讨论与专家反馈
通过在大量的实际案例中对项目健康度评估方法论的实际应用，我们认为这一方法论是有助于项目管理者对项目进行深入地评估分析，找到项目中长线的运行趋势，同时，通过与项目经理以及一些专家的访谈，我们也发现了这一方法论目前存在的一些问题，需要进一步完善。
我们把一些主要的问题，以及重要的反馈进行了如下整理：
1. 所有参与测试的项目经理都认为，这一方法论对于深层次地发我项目的运行趋
势是有益的，特别是对于周期长、负责度高的项目具有很好的实用价值，是传统项目绩效评估的重要补充。
2. 项目健康度关键指标的量化方法需要更强的多样性。
有项目经理认为，该方法论中的关键指标量化表过于通用。作为标准的方法论是合理的，但对于企业中的具体应用，则缺乏针对性。故应该针对不同类型的细分项目设计不同的量化表，或者由企业设计自身的量化问卷，以适应不同类型项目的需求。
同时，有项目经理认为，除了通常的管理信息以外，调查中应包含一定比例的专业内容，比如测试的流程、产品的兼容性等等。
48
3. 对于复杂的项目，应该提高问卷的覆盖度。
对于非常复杂的项目，或是在某一领域复杂度高的项目，如进度敏感型的项目，应该有针对性地对量化问卷进行扩展，增加专门针对相关领域的问题，以对某些问题进行更加深入的分析。
4. 提高问卷调查的真实性，是方法论成功的关键。
经过与项目经理的访谈，以及在大量项目中的应用，我们发现影响评估可信度的一个关键因素是对于量化表的回答质量。
对于某一个项目而言，针对相关管理状况的调查数量不可能很大（一般在5-10人之间），所以很多关于数据调查可信度方面的数学方法无法应用。同时由于管理类数据属于比较敏感的数据，有时甚至是保密数据，所以控制数据的真实性与可靠性变得非常重要。
所以在进行相关问卷设计时，应尽可能地避免敏感数据，但又要保证数据是可靠的，能够反映项目的真实情况。在我们本章的第一个案例中，我们发现在项目执行阶段的评估显示团队士气出现了较为严重的问题，而这一问题在项目初始阶段和计划阶段应该是已经存在的，但是却并没有体现在前两次评估中，这显示参与调查的人并没有完全坦诚地回答问卷问题，特别是与团队相关的一些敏感问题，这在很大程度上影响了项目评估的准确性。
5. 应有对权重分配表进行调整的指导。
很多项目经理认为，在方法论中给出的按项目周期划分的权重分配表过于简单，不能反映很多项目中的具体情况，应当能够在企业中进行修正，但作为一种方法论，应该对这一部分加以细化，给出相应的规则与要点。
4.3 本章小结
本章重点讨论了项目健康度评估方法论在具体项目中的应用，通过对两个实际应用案例的讨论，阐述了关于项目健康度关键指标的两个重要特性，即：
1．当某一项目健康度指标出现问题后，如果不能及时解决，这一问题具有持续性
49
与扩散性
2．项目健康度关键指标间是相互影响的，某一个指标的问题会导致其它指标产生问题。
本章另一个重点是将该方法论应用过程中出现的各种问题，以及项目经理对该方法论的反馈进行汇总，以此探讨这一方法的进一步改进方向。
50
第五章 结论与未来发展改进
我们在本文中探讨了项目健康度的概念及其与传统项目绩效评估机制的差别，介绍了一种基于项目健康度概念对IT类项目进行宏观评估的管理方法论。通过在实际项目案例中的具体应用，我们相信这样一种方法论对于项目管理者而言是一种非常有价值的管理工具，可以帮助管理者在标准的项目绩效之外，可以对项目的长期运行趋势进行把握，及时发现项目中潜在的问题并及时解决，提高IT类项目的成功率。
传统的项目绩效评估是基于所谓“铁三角”的状态评估方法，主要体现的是项目在成本、进度、及项目目标这三方面的完成情况。这种评估方式完全是操作层面的，反映的是项目的当前状态，而这种方式的缺陷是，即使项目有良好的当前绩效，管理层也不能确信该项目一定可以顺利的收尾并取得最终的成功，其中的原因就在于项目中的很多不确定性因素在项目早期、甚至是执行阶段都没有被发现，而当这些因素最终对项目造成影响时，往往已经是项目的后期，管理者已经没有足够的资源对这些问题加以解决。
而项目健康度正是这样一种新的项目评估理论，它能够从一个相对较高的层面，而不仅仅是操作上，对项目进行评估，试图找到项目中的各种潜在危险因素，并及时加以解决。健康度实际上是一种项目预警机制，当项目仍在正常运行时，为项目管理者提供一种自我检查的手段与方法。
但项目健康度作为一种理论体系，提供的是一些指导性的原则与要点，管理者们需要一种具体的、可操作的方法论将其加以应用，本文就具体介绍了这样一种方法，一种针对IT行业中IT类项目进行健康度评估的发法与工具，该方法完全针对IT类项目的特点，定义了项目的健康度关键指标、评估的关键时间点、具体评估流程以及相关的评估工具。同时本文中用大量篇幅讨论了这一方法论的设计思路，以及在应用实施中的技巧与经验。
作为一种新的方法论与管理工具，这一评估机制还需要通过更大规模的应用加以检验与完善，但通过目前的应用经验，我们完全相信这种评估方式对于项目管理这来讲是有着巨大价值的。通过这一方法，项目管理者不再是仅仅关注项目的短期绩效，而是更多的关注项目运行中本身的机制上是否存在问题，是否有某些潜在的问题没有及时发
51
现，然后又针对性地加以解决，可以大大提高IT类项目的成功概率，降低管理风险。
但这一方法论确实也存在很多问题，仍需要不断地加以完善，根据目前的应用经验，我们对这一方法的今后发展有如下设想：
首先，作为该方法论核心的关键指标，仍有进一步调整的可能。目前的5个关键健康度指标对于通常的项目是适用的，但对于不同的项目类型也许会有不同。我们在设计早期曾考虑采用４种关键指标，也就是将指标Ｓ与指标Ｐ进一步整合，这样可以更为简单，提高易操作性，但由于指标S对于很多项目来讲非常重要，最终还是采用了5个关键指标。但作为今后的进一步发展，有可能考虑针对不同类型不同规模的项目采用灵活的关键指标，更好地平衡有效性与易操作性。
在这一评估机制中，最重要但也最不容易把握的，就是量化的方法。我们在本文中给出的一些量化工具完全是针对通常项目，具有非常好的通用性，但肯定缺乏对不同项目的针对性。作为该方法的进一步发展，应该对不同的项目类型进行细分，比如针对研发类项目、集成类项目、或者是咨询类项目分别设计不同的量化工具，这样可以更好地反映不同项目的特点，使得评估工作更为真实可靠。
该方法论的一个最大弱点，在于管理数据的不易获取，以及量化数据的准确性不高。我们在本文中的所有分析完全采用定性分析，但对于复杂的大型项目而言，有时候我们会需要精度较高的分析与预测，这时候定量分析就是必须的。为实现一定程度的定量分析，必须改变数据采集的方法，更多地从项目管理数据库中获取项目的真实数据，同时结合专家面谈、Delphi法、蒙特卡罗分析的手段，对项目的运行趋势做出精度较高的分析与预测，这也许是给方法论今后的一个发展方向。
最后，项目管理方法论是一个完整的体系，有既定的工作流程，并且与要与企业的业务流程很好地整合，也就是我们所说的企业项目管理系统。而项目健康度评估方法同样应该与项目管理流程、企业业务流程很好地整合在一起，形成企业完善的项目管理规范，并可以随着企业业务的变化而做出调整，这样这一管理工作才能最终成为企业生产力。
本文中所介绍的这种基于项目健康度概念的项目评估方法，虽然不可避免地存在很多缺陷，仍然需要大量的工作加以完善，但其本身区别于传统评估机制的角度与定位，使其对项目管理者具有非常特殊的价值，相信会有非常广阔的应用空间。
52
参考文献
[1] OLisen，RP. Can project management be defined ? [J]. Project Management 1 Quarterly ，1971 ，2 (1) ：12214.
[2]Harold Kerzner.Project Management ：A System Approach to Planning ，Scheduling and Controlling (6th edition) [M]. New York ：Van Nostrand Reinhold ，1997. [3] Da Wit,A (1988). Measurement of project success. International journal of project management, 6(3) 164-170
[4] Baccarini, D (1996). The logical framework method for defining project success. Project management journal 30(4), 25-32
[5] Wateridge, J. (1998). How can IS/IT projects be measured for success? International project management 16(1), 59-63
[6] Kam Jugde, Ralf Muller. A Retrospective Look at our evolving understanding of Project success
[7] Atkinson, R. (1999). Project management: Cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International Journal of Project management, 17(6), 337-342
[8] Cooke-Davies, T. (2002). The “real” success factors in Projects. International Journal of Project management, 20(3), 185-190.
[9] Kerzner, H. (1987). In search of excellence in project management. Journal of Systems Management, 38(2), 30-=40
[10] Bounds,G (1998). The last word on project management. Institute of Industrial Engineers Solutions, 30(11), 41-43
[11] Clarke, A (1999). A practical use of key success factors to improve the effectiveness of project management. International journal of Project Management, 17(3), 139-145 [12] Lester, D. H. (1998). Critical success factors for new product development. Research Technology Management, 41(1), 36-43
[13] Cleland, D. I., & Ireland, L. (2002). Project management: Strategic design and
implementation (4th ed., Vol. 1). New York: McGraw-Hill.
[14] Pinto, J.K.,& Covin, J.G. (1989). Critical factors in project implementation: A comparison study of construction and R&D projects. Technology, 9(1), 49-51 [15] Turner, J.R. (2004). Five conditions for project success. International Journal of project management, 22(5), 349-350
[16] Stewart W E. Balanced scorecard for projects [J]. Project management Journal, 2001, 32(1): 38-53
[17] 杜亚灵、尹贻林. 公共项目管理绩效评价研究. 项目管理技术2008(7), 13-17.
[18] 张慧颖. 基于灰色变权聚类公路建设项目成功度评价[J]. 公路，2006(8): 141-145
[19] IBM: World wide project management methodology 1.4
[20] T.L. Saaty. Fundamentals of the Analytic Hierarchy Process. RWS Publications, 4922 Ellsworth Avenue, Pittsburgh, PA 15413, 2000.
版权声明
本文版权归原作者所有，任何转载、使用、分发须经原作者书面同意，否则视为侵权行为。
作者联系方式为： xinw.jiang@hotmail.com
因篇幅问题不能全部显示，请点此查看更多更全内容