为了正常的体验网站,请在浏览器设置里面开启Javascript功能!

项目管理中的项目健康度评估

2011-01-21 50页 doc 884KB 56阅读

用户头像

is_127795

暂无简介

举报
项目管理中的项目健康度评估项目管理中的项目健康度评估 蒋昕炜 二00九 年 三 月 摘 要 在项目管理方法论当中,对项目的评估机制是一个非常重要的组成部分,目前的项目评估主要在两个层面上进行,即在项目的操作层面及企业的业务层面。 传统的项目评估机制完全针对项目当前的操作状态,以传统的“铁三角”理论为基础的,重点考察项目在成本、进度及业务目标上的完成状况。“铁三角”理论本身并不能很好地反映项目对于企业的业务价值,故从80年代以后,企业更多地引入了基于关键成功指标 CSF 的项目评估机制,以反映项目在业务层面的价值。 在项目管理实践中,管理者们发现他们需要...
项目管理中的项目健康度评估
项目管理中的项目健康度评估 蒋昕炜 二00九 年 三 月 摘 要 在项目管理方法论当中,对项目的评估机制是一个非常重要的组成部分,目前的项目评估主要在两个层面上进行,即在项目的操作层面及企业的业务层面。 传统的项目评估机制完全针对项目当前的操作状态,以传统的“铁三角”理论为基础的,重点考察项目在成本、进度及业务目标上的完成状况。“铁三角”理论本身并不能很好地反映项目对于企业的业务价值,故从80年代以后,企业更多地引入了基于关键成功指标 CSF 的项目评估机制,以反映项目在业务层面的价值。 在项目管理实践中,管理者们发现他们需要一种更为有效的评估机制,介于上述两个层面之间,用以衡量一个项目能否最终取得成功的可能性,也就是项目的运行趋势。这就需要一种全新的理论与方法来对项目进行较高层面的分析与考察,可以从健康性与趋势上对项目加以评估。 在这一领域业界并没有非常成熟的理论体系,但在项目实践中很多大型企业有一些自有的经验与方法,本文的核心内容与工作,在于通过对项目“健康度”相关理论的研究以及大量具体案例的分析,总结归纳出一套面向IT行业的项目“健康度”评估方法,提供一套具体的、可操作的方法论,使之成为IT企业对项目进行深层次绩效评估的重要工具,这一方法论的设计过程主要基于以下过程及原则: 1.​ 对现有项目健康度理论进行研究与简化,使之易于操作 2.​ 对大量实际项目进行研究,分析导致出现问的关键因素 3.​ 针对IT类项目的特点,对方法论进行优化,这些特点包括: a.​ 需求的复杂性 b.​ 先进技术带来的潜在技术风险 c.​ 对关键技能与关键人的高度依赖性 4.​ 基于相对简化、易操作原则所做的评估流程与工具设计 5.​ 新的方法论在项目中的实践应用 本文将对大量的实践案例进行讨论与研究,对相应的方法论进行分析与介绍,重点分析在应用中的各种实际问题,同时探讨这一方法论在未来项目中的应用。 关键字:项目管理、项目健康度、绩效评估 作者简介 蒋昕炜老师1997年作为IT工程师加入IBM中国公司, 2000年成为解决中心技术经理,作为技术负责人和项目管理者参与IBM 服务器部门在国内的众多大型IT项目。2001年后作为产品经理负责高端解决方案的销售咨询工作,以及公司内部的员工培训。在近七年的IBM职业生涯中,参与公司内外的多个大型项目,直接负责一些重要项目的实施及控制,对“复合型”组织架构下项目的运作模式有多年的实际经验。    2004年离开IBM加入英特尔(Intel)公司,负责亚太区各国渠道客户解决方案咨询工作,2007年离职成为职业项目顾问与客座讲师,并与能通威科公司合作参与航天部五院相关航天项目的咨询服务。        从2004年开始作为兼职讲师,与北京大学软件与微电子学院合作从事项目管理的教学,目前是包括IBM在内国内多家著名企业、培训机构的客座讲师,其课程风格不同于本土学院派及港台讲师,注重西方管理方法在中国本土环境中的应用,解决项目化机制在企业应用过程中的各种实际问题,并强调职业的项目管理者所必需具备的素质与技能,主要课程涉及基本项目管理流程与思路、项目经理的素质与沟通技能、企业级项目组合管理与策略、项目风险的控制机制等相关领域,过去5年服务的客户覆盖外资(如IBM),本土大中型企业(中移动集团及多个省公司,中石油)、政府部门(如财政部、航天部)、科研机构(中科院电子所)、中小企业等多个层面,有丰富的企业培训经验。     蒋昕炜现为美国项目管理协会(PMI)会员,国际项目管理协会(IPMA)项目管理大奖评估师,项目管理专家(PMP)认证,北京大学客座讲师。   其论文《企业项目化改制的成熟度演进》2006年一月发表于项目管理学权威杂志 个人主页: www.pmtraining.net 目 录 TOC \o "1-4" \f \h \z \u 摘 要 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 图目录 TOC \h \z \c "图" 图 1 论文结构 4 表目录 TOC \h \z \c "表" 表 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 第一章 绪论 1.1​ 研究背景与动机 在企业的项目管理实践中,针对项目的绩效评估是项目管理中的重要工作,传统的项目管理理论与实践也提供了大量的绩效考核工具,比如挣值分析方法,这些方法可以帮助项目经理与企业管理层对项目的当前运行状态有比较清晰的把握,比如项目的当前进度状态、成本分析以及范围内容的完成情况,这些方法被广泛地应用在项目管理实践中。 但是在传统项目绩效评估方式中,各种指标均过于强调反映项目的当前绩效,而没有能够很好地反映项目中长期的发展趋势。事实上,在现代项目管理实践中,有很多项目长期保持良好的绩效,但在一些关键的验收节点上出现了严重的问题,而导致项目的最后失败,所以项目良好的当前绩效并不代表项目最终一定能够取得成功。 随着项目管理技术的发展,出现了很多种新的项目评估理论,更加注重对项目的宏观发展趋势加以分析,试图分析一个项目最终能否取得成功的可能性,比如项目的需求明确程度、工作的可控性、风险控制流程的健全性等等,其中最为著名的就是项目的“健康度”概念。 项目的健康度不同于项目的状态,后者是在操作层面上判断项目的进度、成本、绩效等一系列指标,反映项目的当前进展状况。而前者则在宏观层面上反映了项目的发展趋势以及最终取得成功的概率。在许多项目化管理非常成熟的企业中,管理层往往更愿意通过健康度,而不是状态来宏观地把握项目的运行,确保企业战略目标的实现。 然而如何对项目的中长期趋势加以把握与评估呢?这里需要有全新的理论体系与方法论来加以指导,目前行业内并没有非常完善的理论体系能够对项目的运行趋势进行分析与研究,但在很多大型跨国企业中有一些自有的方法与经验,能够对项目的运行趋势分析提供理论上的指导,比如普华永道提出的“七个关键点”以及IBM的项目“健康度”概念。 我们将在第二章中对项目健康度的概念加以详细的解释,并对IBM的项目健康度指标体系进行介绍。这里我们要重点讨论的是,现有的关于项目趋势研究的相关理论更多的是在理论层面的指导性原则,涉及到项目及企业的各个层面,作为一种指导理论是全面的,但却缺乏在操作与应用层面的具体指导,没有能够使之广泛应用的方法论,这也是项目健康度多年来一致停留在理论层面的重要原因。 从另一个层面看,很多IT企业广泛地采用了项目管理机制来运营企业,但IT类项目的一些特点导致项目的成功率相对较低,比如IT项目中需求的复杂性与易变性、高技术手段导致的技术风险、对人的高度依赖性等等,这使得IT类企业迫切需要一种新的管理工具,能够对项目进行宏观的趋势性评估,以建立项目预警机制,提高项目成功率,并实现企业资源的合理优化。 由此,我们希望能够基于现有的项目健康度理论,并通过相应的简化与优化,设计一种具有良好可操作性的评估工具,能够服务于各种类型的IT项目,为IT企业提供一种有效的管理工具,提高IT项目的成功率。 1.2 研究的目的与问题 我们希望这种新的项目评估方法所提供的,不是项目在操作层面的绩效状况,而是能够反映项目在中长期运行趋势的管理评估,这就提出了一系列的问题 (1)​ 哪些项目中的管理因素能够最终影响到项目的运行趋势? (2)​ 如何将这些因素综合归纳成关键的管理指标? (3)​ 如何对运行中项目的管理数据加以提炼,获得这些量化的关键指标? (4)​ 如何对这些关键指标加以理解,以获得项目的趋势性分析? 我们将在后面章节中具体讨论这些问题。同时,由于我们所希望设计的是能够应用在实际IT类项目中的管理工具,所以就必须考虑到这一方法的可操作性问题,以及如何尽可能降低应用中的阻力,这就要求必须将相应的理论体系加以简化与归纳,尽可能地从实际管理应用的角度对相应的理论加以整合,并设计相应的工具,以帮助项目管理人员比较容易地完成对项目的评估。 基于这一思路,我们对相应的理论进行了深入的学习研究,同时对大量真实案例进行研究分析,从众多的导致项目产生各种问题的机制中,归纳总结了5种最为核心的“问题源”,包括项目的Sponsor管理、项目的需求界定、项目工作的可控性、项目风险的可控性以及项目人员及团队的可控性,并以此为基础设计了5个关键的项目健康指标,指标T、指标S、指标W、指标R、指标P。 这一划分方法与IBM较为典型的7个关键点有一定的区别,主要在于将进度和范围整合为指标W,即工作可控,将团队因素与执行机构因素整合为指标P。,之所以做这一变化主要是希望提高这一方法的可操作性。IBM的7个关键点作为一个经典的理论体系,需要较为细致的划分,以说明不同要素的不同特性,但作为一个指导实际操作的方法论,过细的划分方式会导致很多具体问题在操作中不容易界定,加大执行中的难度,而如果将具有较强相关性的要素整合在一起,不仅大大降低了操作的难度,而且对于绝大多数的项目而言,这种划分精度是完全够用的。 除了关键指标的设计之外,还有一个重要的需要研究的问题是健康度评估的流程与工具。由于我们研究的重点是IT类的项目,所以在流程及工具的设计中充分地考虑了IT类项目的相关特性,如高技术因素导致的技术风险、需求的复杂性、对技术人才的依赖等等。在评估方法中必须要充分考虑到这些因素的影响,比如在工具设计中通过专门的权重量化表,强化在项目早期(初始阶段与设计阶段)的需求、业务目标的明确性,而在执行阶段则提高对于技术人才在评估中的权重。 在整个评估方法论的设计中,可操作性是贯彻始终的一个重点,而本文讨论的一个重点,也是如何将一种典型的理论体系,转化为一种可操作、并且易于操作的管理工具。 1.3 本文的组织结构 为了能够较为清楚地介绍项目健康度评估方法论的背景、关键指标、流程、工具以及具体应用,本文按下页结构安排 图 1 论文结构 第一章: 绪论 概要性地介绍项目健康度评估的理论体系,以及本文主要的研究工作,也就是如何将健康度评估的理论体系转换成一种可操作,能准确反映项目运行趋势的管理方法论。同时讨论了指导这一工作的主要原则与出发点。 第二章: 相关文献探讨及案例 这一章分为两个主要部分,前半部是对相关文献进行综述与讨论,包括传统的评估机制的基础与应用,以及现有项目健康度理论的现状与构成。第二部分则对若干案例进行了深入的讨论,进一步说明原有项目评估机制的局限性,以及项目中的哪些关键因素对项目的运行趋势与最终成败具有影响。 第三章: IT项目管理中健康度评估方法的研究 这一章重点介绍了项目健康度评估方法的具体内容,包括关键的评估时间点的把握、具体的项目评估指标、评估的工作流程,以及如何获得量化的评估指标。同时本章也介绍了相关的评估工具,可以帮助管理者简化评估过程,提高这一方法论的可操作性。 第四章: 案例应用研究 这一章介绍了几个具体的应用案例,讨论了这一方法论在具体案例应用中所带来的改善、产生的一些问题,以及一些具体的应用技巧,进一步证明了对于IT类项目来讲,健康度评估方法论所具有的特殊价值。 第五章: 结论及未来发展的讨论 作为本文的收尾,这一章总结了项目健康度评估方法论在IT项目管理中的应用价值与前景,并为这一方法论(包括其理论体系)的未来发展提出了建议。 1.4 本章小结 本章讨论了传统项目评估机制的方法与现状,以及不同层次的项目评估方法的差别,重点阐述了为什么需要一种新的项目评估方法论,能够在传统的基于绩效的评估模式之上,提供针对项目发展趋势的研究。 同时,本章也讨论了如何将项目“健康度”的理论体系,转化为一种易于操作,并且能够准确反映项目运行趋势的操作方法论,以及在这一过程中的主要原则与思路。 第二章 相关文献的探讨与分析 本部分重点收集了与本论文相关的文献内容,重点包含了3个方面,关于项目成功的标准及其演变过程、项目绩效考核的方法及工具、以及在一些大型跨国企业的项目管理实践中有关项目绩效趋势的基本观点及方法论。趋势分析是与项目的绩效考核紧密相关的,而绩效考核则依赖与对项目成功的标准与定义,故这三部分有着内在的联系。有关绩效趋势分析的相关文献较少,而且现有内容基本都是一些原则性、分析性的观点,没有具体的在操作层面的方法。在这片论文中,我将试图通过对项目成功、项目绩效以及项目绩效的趋势研究,归纳总结出一些可以应用在具体项目中的方法,以对项目绩效的趋势加以分析研究。 2.1 关于项目成功的标准 一个项目如何算作成功,人们印象最深的肯定是由Oilsen [1]提出的著名的铁三角理论,这也是因为这一理论被美国项目管理协会采用,并写入到了PMBOK当中。其实在这一体系中所强调的,是项目管理工作的成功,也就是进度、成本与质量的相互关系。[Project Management Institute 2000] 这里应该解释的问题是,很多文献中所谈到的项目成功,指的是项目管理的成功,Da Wit(1988) 提出项目管理成功包含进度、成本及质量、绩效,而项目成功则包含了更为广泛的内容,特别是与项目的干系人相关的视点,“好的项目管理有助于项目成功,但并不能彻底避免项目的失败”,(De Wit 1988, p 64),或者用一个更加常用的比喻“手术很成功,但病人却死了” 所以对于项目管理的成功和项目的成功用不同的定义: 项目管理的成功: 传统意义上的项目成功更多是指在项目的生命周期内,对项目的成功管理,主要反映在项目的进度、成本、质量这些硬性指标上。 项目的成功: 项目的成功则是一个超出项目生命周期的概念,主要的衡量标准也包括项目在各个层面上的目标,特别是业务上的目标。 一个很好的例子是,举世闻名的悉尼歌剧院用了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) 由于这种项目成功的定义是基于项目的生命周期,而不是产品的生命周期,所以在这个模式下,客户满意是一个非常难以衡量的因素,人们试图将客户满意、整个项目的成功与铁三角理论整合起来,比如强调应如何帮助客户了解自身的需求,如何通过软技能提高与客户的沟通等等手段,使得项目管理的成功与更大意义上的项目成功相统一,但这些努力仍不能很好地解决这些问题。 阶段2:CSF(关键成功指标)清单 (1980–1990) 在这一阶段,项目的成功被定义成了一系列关键成功指标的完成,“必须被正确完成的事情” [9](Kerzner, 1987, p32)。相关文献的描述更加注重与干系人的满意程度,项目完成的指标也从“我们完成了”转移到“我们很满意”,这也是与原有项目成功概念的一个巨大的区别。 Bounds 在1998年提到:“一个成功的项目应该包括员工的培训与教育、专门的资源、良好的工具、坚强的领导与管理,以及与项目执行同步的个人、团队、组织的提高” 这里面的重点在于我们从宏观还是微观上来看待一个项目。微观的视角之关注于项目工作的完成,而宏观的视角则扩展到在产品的生命周期中去评估客户的满意。而铁三角中所描述的项目承包、进度、质量指标依然是对项目的重要衡量,但已经不是唯一的指标。 基于这样一种理念,不同的人往往给出不同的项目成功标准,而其中很多是非常有代表性的,比如 Clark 的CFS 指标 [11]: “有效的沟通、清楚的目标与范围、将项目划分到可管理的模块、使用项目计划作为实时的项目文档” 第二阶段的特点是有大量的CFS指标被提出并被广泛的应用,但并没有形成完成的体系框架,特别是与项目管理的方法论相配合的体系。 阶段3:CSF框架体系 (1990–2000) 在上世纪90年代,出现了大量的文献试图建立一个关于项目成功的框架性标准,其中一些主流的出版物中关于这一问题都非常注重两点,即项目的成功是高度依赖于项目干系人的,项目的成功高度依赖于项目团队与接受组织间的互动。[12] (Lester, 1998) 最为先驱的要数 Morris 和 Hough,他们基于对大量实际案例的研究,首先将项目成功的前提条件进行了分组: 项目功能: 项目是否满足了财务及技术需求? 项目管理: 项目是否满足了成本、进度及质量要求? 下包商: 项目下包商是否获得了他们需要的利益? 项目终止: 当项目不得不被取消时, 这一决定是否合理及有效? 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) 项目成功的定义必须在项目开始前获得所有项目干系人的认可,并且在项目的每一个关键时间点再次获得确认 (2) 在项目经理与项目Sponsor之间,必须建立起合作性的工作关系 (3) 项目经理必须有足够的授权在一些不可预见的情况下做出灵活的处置,依据是他们对于项目状态的理解,而这种理解来自项目Sponsor 所给出的指导。 (4) 项目的Sponsor必须能够从项目的绩效中获利 在这一个阶段,对于项目成功的最核心的认识是,项目必须与组织的长期目标与计划相一致,使得组织可以从项目的绩效中获利,而组织也将给予项目足够的资源、授权,保证项目的进行。在这一过程中,项目所在组织的高层管理这有相当大的责任,包括对与组织策略的调整,对项目的引导,以及对项目团队的授权等等 2.2 “项目健康度”相关理论的讨论 我们在前面章节中重点讨论了项目成功标准与绩效考核的发展与演变过程,以及相关的经典文献。在这一过程中,人们对于“项目成功”的理解,有简单地按时、按成本完成既定目标,提升到更为贴近业务目标的关键考核指标,到最后企业认识到项目的成功必须与企业的长期战略目标相一致,这是一个由简单到复杂、由局部到整体的、由短期到长期的转变过程,反映了项目在企业中的地位由简单地完成某一工作,转变为达成企业长期战略的重要手段。 但在这一体系中,笔者认为依然存在一个重大的缺失,也就是不论从哪一个层面来衡量,现有的绩效考核体系完全是以项目“当前状态”为考虑依据的,而没有能够很好地反应项目中长期的发展趋势,而在很多情况下,当前绩效并不能保证项目最终取得成功,因为很多潜在的不确定因素并不能在项目的早期就很好地反映出来,所以往往被项目管理者所忽略,而当这些问题出现时,则已经对项目造成了严重的影响,而且难以挽回。 作为项目绩效考核体系的重要补充,笔者认为在现有项目绩效考核体系以外,应该将项目运行趋势作为一个重要的项目考核指标,而这样一个指标在项目管理过程中,特别是在项目运行的初期,对项目管理者而言应该有更大的参考价值。但项目的趋势如何衡量?什么样的指标能够综合性地反映项目不同层面的问题?显然目前的项目绩效考核工具无法达到这一目标,如同赢得值系统可以很好地反映项目当前绩效一样,我们需要另一套量化的指标体系来衡量项目中长期的运行趋势,也就是项目的“健康度”。 笔者研究了大量现有文献,认为目前针对项目管理的相关文献中,并没有完全针对“项目趋势”进行讨论的论著,也就是说在这一领域缺乏成熟的理论框架与基础。但笔者在以往的项目管理实践中发现,很多跨国企业在这一领域进行过很多有益的实践,并且积累了相当的实践经验,可以说项目“健康度”的概念完全来源于实践,所以笔者在研究过程中大量参考了相关企业的有关资料,比如普华永道的项目七个关键点,以及IBM的相应管理方法,这也是本文进行相关设计工作的一个重要参考依据,下面笔者尝试对现有“项目健康度”的概念进行归纳。 在项目健康度概念中,管理者认为项目的健康与人的健康具有类似性,人的健康往往通过具体的生理指标加以衡量,而项目的健康也体现在一些关键的管理指标上。 在健康度理论中一般从七个层面来对项目健康进行检查与判断。这七个层面包括干系人、项目范围的控制、进度的可控性、项目目标的清晰性、风险的认知、团队的士气以及执行机构的利益。这七个关键指标构成了项目进展的红绿灯,直接反映项目的整体趋势和最终成功的可能性。 与项目状态不同,这七个指标反映的是项目的本质。“干系人”在项目中有不同的利益与目标。协调一致的干系人利益直接决定了项目团队的执行能力,以及对项目方向的宏观把握。反之则会带来各种负面影响,如消极怠工、缺乏资源、得不到管理层支持等等。“项目范围”直接构成项目的基线,其与“进度”的控制紧密关联。有很多当前状态良好的项目却从开始时便注定要失败,原因就在于范围定义的不清晰,以及进度的不可控性。有很多看似合理的协议条款,比如“满足用户应用需求”,最终成为项目失败的根源,其原因便在于其的不可操作性。而过于先进的技术、不熟悉的供货渠道等原因,直接导致进度的不可控性。 对“风险”的管理直接反映了一个企业在项目管理上的成熟程度。积极、主动、有计划的风险管理可以在最大程度上将项目的不确定因素转化为确定因素,并为未知的风险预留足够的资源。而未知风险会比已知风险对项目成功造成更大的威胁。企业以及项目团队对风险的重视程度,以及应对的计划性都直接影响项目最终成功的可能性。 另一个重要的指标是关于项目的业务目标。任何一个项目都有其存在的必要性,而这一根本因素在项目执行的过程中也不是一成不变的。对这一目标的共同理解可以直接影响团队的工作重点,计划的制定以及技术方案的选择。最为典型的例子是,过于追求技术的先进性经常会背离业务目标的需要,导致不必要的成本提高和风险的增加。 团队士气同样是项目经理必须关注的重要指标,一个缺乏信任,没有有效沟通的项目队伍是很难应对复杂的项目需求的。最后,项目执行结构的利益应该被充分重视,这包括了项目团队、下包商、供应商、以及其它合作方。除经济利益外,技能的培养、经验的积累等等都应被充分的考虑。 对这七个健康度的评估应该贯穿项目始终,从启动阶段直到收尾阶段,公司管理层都可以通过这一手段有效地跟踪项目进展,判断项目是否有机会最终在业务目标、进度、成本等各方面都取得成功。它所构成的系统如同汽车的仪表盘,当驾驶汽车行进时,除了正常驾驶以外,还应该通过仪表盘关心汽车本身的状况,而这恰恰是能否最终到达目的地的根本保障。 以上谈到的关于“项目健康度”的相关概念,来源与企业的应用实践,反映了在项目管理实践中管理者所关注的不同层面。但这一体系目前并没有形成相应的方法论,也并不存在量化的工作可以帮助管理者对相关的指标进行衡量。同时笔者认为,为了能够对影响项目趋势的指标进行量化衡量,也非常有必要对指标体系进行重新设计,以是其能够通过标准的“工具”与“流程”进行管理,这是笔者在本文中所要重点论述的。 2.3 本章小结 本章通过对相关文献的整理与综述,简要回顾了项目成功与项目评估机制的发展过程,包括传统的基于“铁三角”的项目绩效模式与基于关键成功指标CSF的项目评估机制。 同时在这一章中笔者重点介绍了目前在项目管理体系中所不能很好把握的“项目运行趋势”,也就是项目健康度的概念,并对这一概念的原理、现状与企业应用进行了相关的讨论。 第三章 IT项目管理中健康度评估方法研究 基于前一章中对相关理论的综述,我们在这一章中将首先对两个案例进行讨论,找出实际项目中有可能影响项目运行趋势的问题,然后试图建立一个相对标准的项目健康度指标体系,以及相关的工作流程、方法与工具,对项目的运行趋势进行一定的分析与预测。 笔者的这一工作是建立在相关案例研究的基础之上的,在这一过程中, 重点完成了以下三方面的工作: ​ 项目健康度评估的流程与关键时点定义 ​ 项目健康度关键指标体系的确定 ​ 项目健康度量化方法与工具的设计 3.1相关案例的讨论 在本论文的前期调研阶段,我们访谈了20余个典型IT类项目,其中包括开发型项目、系统集成型项目、以及咨询类项目,从中找出在项目管理当中的一些具有明显共性的典型问题,这一类问题本身在项目运作中并不会对项目立即造成严重的影响,但在项目后期往往会产生严重的后果。 我们在对大量案例进行分析后可以发现,在很多项目中导致项目陷入困境的因素是非常类似的,尽管其结果及表现形式非常不同,我们在这里选择了两个非常有典型性的案例进行讨论,并试图归纳出某些具有代表性的项目潜在问题。 案例1: 广东省某医院病患随访系统 2006年,广东中山市某 医院与广州中山医科大学合作,讨论建立出院病人的信息随访系统,其第一期工程由广州市某软件企业承担,开发时间将近半年,目标是在2007年春节前建立起一个能够进行试点运行的系统,能够进行初步验收,同时了解这样一个商业化运作的系统能否有较好的市场接受度,以及医院内部的各部门能否整合资源,很好地配合这一系统的运行。 项目在初步系统设计阶段的一个主导思想是,这是一个尝试性系统,重点在于整合院内各部门资源,尝试新的业务流程,并不是医院内当时最为主流的关键业务系统(HIS),同时甲方在给项目上的投入并不大,并且进度要求很紧,故在方案设计中采用了较为简单的2级架构设计,以及一个较为简单的数据库系统,没有考虑到与 HIS系统的对接。 该项目在整个设计与开发阶段均比较顺,过程中只有一些细节性的变更,但总体进度基本上满足要求,并且在2007年春节后完成了初步的功能性验收,但这时候客户并没有认可项目的完成,而是要求该系统直接上线运行,并在所有出院病人中进行推广,导致访问量迅速提高,这时由于系统在设计中并没有考虑到多科室及大量病人的实时访问,导致产生系统瓶颈,性能急剧下降,并经常性产生系统崩溃。 为解决这一问题,项目团队又进行了3个月的努力,对系统进行了全面改造,最终是性能达到客户的要求,但项目整体进度严重延误,成本远超预算,并导致了客户推迟付款。 项目问题分析: 通过对该项目的分析,我们可以明显地发现几方面的问题: 1. 对于客户在项目中的“业务需求”没有清楚地了解,而只是停留在项目需求上,从而影响对项目重要性及项目范围的判断。 我们在谈到客户需求的时候,往往只是简单地理解为“用户希望我们做的工作”,所以整个需求分析过程经常只是基于与用户间的书面协议,或是会议形式的几次简单沟通,就将客户的意见加以总结,形成所谓的“客户需求”,而没有真正花精力去理解一个重要问题,就是“用户为什么要做这个项目”,而这一问题的答案往往是比较复杂的,并不完全是表面上的原因。 在该项目中,由于国家医改工作的展开以及医药分离的政策,使得以往主要通过药品挣钱的医院开始重视病人的满意度,但由于医院多年以来形成的既定工作模式,医改工作的推进是非常缓慢的,所以这种转型也是需要相当长时间的。但在这过程中,类似病患管理管理这样的系统往往作为医院的“政绩”加以实施,虽然短期内不会是医院的主要业务方向,但在某些特定场合下同样是非常重要的。 2007年初,广东省的若干2线医院开始采用了这样类似的系统,并在行业内部产生了一定的影响,这使得本项目在医院的高层得到了重视,并以很大力度在医院内部加以推进,使得该系统不得不面临很大的访问量,导致性能的显著下降。 表面上看,这一项目开展的原因是改善医患关系,整合内部资源与流程,并不是医院当时的主流业务。但如果比较深层次地去理解,这一项目在一定程度上代表了医院的企业形象,影响它在行业中的地位,所以被客户所高度重视。由于对这一问题的理解不充分,在考虑技术方案时没有充分地考虑到系统将来运行时可能遇到的真实环境,导致出现了严重的性能问题。 2. 对于验收条件的不清晰,使得对工作的进度无法控制。 项目中的另一个问题, 是合同文档中对于验收条件没有非常清晰的定义,导致在验收过程中产生分歧。 项目中验收条件的描述包括相关功能的实现,并完成相关的业务测试,但并没有非常清楚地说明业务测试的环境、条件以及采用什么样的数据进行压力测试,这使得测试过程中双方各自坚持自己的标准,无法达成一致。 在项目管理中的一个重要基准,就是对于“项目完成”的描述,也就是对于项目范围的边界描述。对于项目完成的描述应该是非常清晰、可操作、和没有歧义的,对于验收中的所有细节在相关文档中都必须有非常清楚的描述,包括验收的项目、条件、环境、方法、流程等等,保证项目各方对于项目本身的认识是在同一个起点上。 只有对于项目的范围有一个清晰的认识,项目的相关计划工作、包括项目的进度、成本、风险等等才是有依据的、可信的,否则所有这些关键基线在项目运行中都会面临巨大的变更风险。而最为严重的是,往往一些关键的分歧不会在项目运行过程当中体现出来,而是在项目接近结束的时候才会对项目造成影响。这时候对于项目的管理者而言,已经没有足够的资金、进度余量来处理这些巨大变更,从而导致项目进度延误、成本超支,甚至导致项目最终的失败。 3. 没有清晰的风险管理规划,进一步加大了工作中的不确定性,包括成本及进度。 在于项目经理的访谈中我们发现,在该项目的启动阶段,曾经对项目的整体风险有过讨论,其中特别谈到了这种系统架构在高负荷下可能产生的各种问题,但由于没有同甲方进行认真的沟通,使得这种担心始终没有进行确认与落实,也没有形成的风险应对方案,导致最终造成了严重的影响。 在所有导致项目失败的问题中,绝大部分都或多或少地与项目的风险控制机制有关。风险管理中的几个关键要素,包括风险管理计划的制定、风险的持续分析与跟踪、风险应对机制、风险的专人负责等等是同等重要的。在本项目中,项目初期对性能问题有过讨论,也就是说项目管理者能够意识到在这方面的不确定性,但却没有能够将其做为项目风险而进行系统地分析,没有专人负责与客户沟通,没有指定相应的应对策略,导致问题产生后没有很好的办法加以处理,是一个典型的风险失控的状况。 案例2: 校园信息管理系统开发项目 2006年,深圳市朗瑞斯科技与深圳市某区教育局合作,开发中小学学生信息管理系统,实现教学管理的规范化。该项目由教育局出面协调,由福田区某小学作为试点学校,参与项目组,提供开发测试等应用环境。 该项目预计开发时间为10个月,在2006年底之前完成,项目经理有5年以上软件开发及项目管理经验,但早期的开发团队基本由应届大学毕业生组成,缺乏实际开发经验。 项目早期进展顺利,项目团队用3周时间在试点学校进行了需求分析及业务流程设计,与学校各教研室、各部门进行了广泛地沟通,设计方案基本上获得了认可。在项目开发阶段早期,由于开发人员缺少相应的经验,项目团队用了较多的时间熟悉开发工具与环境,以及协调开发流程,进度明显落后于计划。 但真正的问题出现在第一个关键里程碑验收,试点学校的校长认为该系统虽然实现了基本功能,但未能很好地达到管理的目的,特别是不能与教育局的原有系统相兼容,而要解决这一问题则需要更大的投入,对原有系统做重新规划。 之后的大量沟通工作中发现教育局以及各学校对这一系统的管理功能有很大分歧,需求差异性很大,希望最终产品能够满足所有学校的要求基本是不可能的,而短期内教育局也不可能出台规范性的要求,统一各学校的管理流程,在经过很长时间的大量沟通之后,该项目重新定义为针对核心模块的开发,而在不同学校进行分别的定制,以力求满足多数学校的需求。 该项目最终完成用了将近1年半的时间,为完成该项目重新进行了人员的招聘,成本比原先计划至少超出了一倍。 项目问题的分析: 1.​ 对项目干系人的定义不清楚,导致初期需求分析存在重大偏差。 该项目表现出来的问题是由于需求分析的重大偏差,导致工作严重不可控,然而如果进一步分析,本案例中真正的问题所在是在项目初期未能对项目中的重要Sponsor进行定义,并进行恰当的管理,导致项目中的关键需求得不到准确的认定,多方之间的关系也无法进行协调,这是直接导致项目大幅度超支与延期的原因。 2.​ 项目团队人员技能有明显缺陷。 同样由于项目需求分析中存在的问题,该项目在启动时未能很好地定义们团队的人员技能需求,导致在项目的初期就出现了进度滞后,而后由于项目的大量变更,导致项目团队的技能更加不能满足需求,不得以进行了大幅度的调整,使项目成本进一步地超出了初始预算。 上面两个案例具有相当大的代表性,在许多IT类项目中都会存在类似的问题,我们通过对大量案例的分析,认为导致项目趋势性问题的潜在因素主要存在于以下几方面: (1)​ 对项目需求没有充分地分析 (2)​ 对项目业务目标缺乏深层次的理解 (3)​ 项目风险把握中没有良好的机制 (4)​ 项目团队缺少必要的技能 (5)​ 项目团队不良的士气 (6)​ 项目工作的不可控 (7)​ 对项目的Sponsor 缺乏清晰的定义及持续的管理 (8)​ 对相关各方的利益关系及目的缺乏了解 以上这些因素本身存在很强的相关性,某些因素是根源性的,某些是衍生的,而在不同项目中根源性的原因相当不同,在下一章中将重点对这些因素加以分类整理,试图建立一个框架性的指标体系,能够对项目进行衡量。 3.2 项目管理流程中的关键节点及关键指标 通过对上述案例的分析,以及对项目管理流程的研究,我们认为在项目管理的过程中应有几个关键的时间点,需要对项目的整体健康程度进行检查与分析,以确保项目能够最终取得成功。 这里所谈到的项目健康度分析,并不是指项目的直接绩效,而是对项目长期运行趋势的一种分析,也就是项目能够最终取得成功的概率。项目的当前状态表现的是项目的绩效,这往往是项目目前阶段的表面状态,而项目健康度则在更高层面上对项目进行观察,分析其关键的健康度指标,判断项目中是否有一些潜在的问题,这些问题虽然当前并没有很明显地表现出来,但最终会对项目的运行产生关键的影响。 根据对大量案例的分析,以及一些相关理论的研究,我们把在IT类项目中一些比较关键的项目指标加以总结,并按照项目运行的关键时间点加以分类,从而试图得到一种能够在IT类项目管理中可以具体操作的评估方法。 3.2.1 IT类项目管理中关键时间点的划分 在考虑如何安排项目管理中对项目进行健康度分析的关键时间点时,有如下几方面的情况应该加以考虑: 1.通常项目管理的生命周期包含初始阶段、计划阶段、执行阶段及收尾阶段四个主要阶段,而IT类项目由于其一些特有的特点,比如技术含量较高、用户需求复杂、市场变化快等等,我们一般更加注重在项目需求分析及计划阶段的投入。在每一个项目管理的生命周期中,都应该进行相应的健康度分析。 2.在关键时间点的划分上,除了项目管理的自然属性外,同时要考虑到管理工作的时间跨度,也就是基于“汇报周期”进行健康度的分析,如果在项目管理的某一个生命周期中,如项目计划阶段,时间跨度超过了4个汇报周期,则需要进行两次以上的健康度分析,以保证相关分析的真实性。 3.同时还要考虑的因素是,对项目健康度的评估,应该同时考虑到项目当前的绩效状况,如果项目某一方面的绩效发生问题,往往代表项目中出现了一些严重的问题,在对项目绩效进行分析的同时,也应该对项目整体的健康度进行分析,这样才能保证解决表面问题的同时,能够对一些根源上的原因进行分析及处理。 4. 另外,当项目中出现某些异常情况时,比如大量的人员变动、客户变更增多时,应该在必要时对项目的健康度进行整体评估,确保所有潜在的问题能够被及时发现并相应地进行处理。 据此,我们将项目中的健康度分析关键时间点做如下划分: 1.​ 固定的健康度分析 (1)在项目的需求分析阶段将要结束时 需求分析工作是整个项目管理工作的开始,也是所有项目管理工作的重要基础,在需求分析阶段的后期进行项目的健康度评估,其主要目的就是确保需求分析工作是充分的且足够深入,评估重点包括: 1)​ 对于项目的业务目标是否非常清晰? 2)​ 该项目能否为客户企业及执行方企业带来价值? 3)​ 项目工作是否是可控的? 4)​ 项目参与各方间的利益是否协调? 5)​ 对项目的风险评估是否表明该项目值得投入? 6)​ 管理层是否对项目的风险有足够认识? 7)​ 协议中的工作定义是否清晰? 8)​ 主要干系人对项目的理解是否一致? 9)​ 团队的角色定义是否清晰? 10)​ 企业是否有足够的技能来完成相关工作? (2)在项目的计划阶段将要结束时 在项目的计划工作基本完成时进行健康度评估,其关键评估要素包括: 1)​ 项目的计划是否有益于项目的业务目标? 2)​ 计划中对于如何达到项目目标是否有充分的考虑?这一过程是否可控? 3)​ 对进度的预估是否合理?进度是否“适当的”紧凑,但避免了不必要的压力? 4)​ 对项目执行机构在项目中的利益是否有充分的了解? 5)​ 计划中是否考虑了风险因素? 6)​ 风险计划中的风险项是否有专人负责? 7)​ 合约中是否对项目的范围与方案、角色与责任、可交付成果与完成日期有明确定义? 8)​ 范围定义是否有明确的衡量标准?是否不存在误解? 9)​ 范围定义中是否包含了产品的范围以及项目管理工作的范围? 10)​ 是否所有重要干系人都认可项目计划?包括正确性、可操作性、符合业务目标? 11)​ 主要的项目 Sponsor 是否对项目的投资回报分析满意? 12)​ 项目是否有清晰的人员需求定义?是否有足够的具有合理技能的人来组成项目团队? (3)在项目的执行阶段每四个汇报周期完成时 在项目的执行阶段的健康度评估可以帮助项目管理者在监控项目的日常运行的同时,对项目的发展趋势及项目中开始出现各种潜在问题及时地发现,并做出有效地相应,避免严重问题的发生而影响到项目目标的实现。这一阶段主要的评估要素包括: 1)​ 项目的业务目标是否有变化? 2)​ 项目中的各管理计划是否被有效地沟通和执行? 3)​ 是否所有的管理活动都在项目管理计划之内? 4)​ 能否有效地监控项目的时间和进度?(与基线的偏差) 5)​ 各项目参与组织是否均对项目满意? 6)​ “经验获得与分享”机制是否有效的建立和运作 7)​ 风险管理计划是否被有效的沟通和执行? 8)​ 风险是否被正确的监控和有效的更新? 9)​ 范围管理计划(包括下包)是否被有效地沟通和执行? 10)​ 干系人管理计划是否被有效地沟通和执行? 11)​ 团队是否有所需的技能及良好的士气? 12)​ 团队管理计划(团队建设、激励 …)是否被有效地沟通与执行? (4)在项目收尾阶段开始时 在项目收尾阶段,对项目健康度的评估同样是非常重要的,这种重要性体现在两个方面,首先,在收尾阶段刚开始时(项目正式验收之前)的健康度评估可以帮助项目团队对项目的运行进行自查,对于发现的问题依然可以进行及时的处理与补救。第二,对于所有项目管理工作而言,形成项目的经验知识库都是非常重要的,如果一个项目中的经验不能很好地传递给今后的项目,从项目管理的角度来说就不能认为是一个成功的项目,而这个阶段的健康度评估本身所获得的经验与教训本身就是知识库中非常有价值的内容。 这一阶段健康度评估的关键因素包括: 1)​ 主要资助人(Sponsor)是否认可项目所实现的“业务目标”? 2)​ 所有可交付成果是否按时完成? 3)​ 对执行组织(下包 … )的财务结算是否完成? 4)​ 利润分析是否证明项目是盈利的? 5)​ 项目经验是否被正确地记录和分享? 6)​ 风险是否被正确的监控和有效的更新? 7)​ 是否所有事先定义地项目接受条件均得到满足? 8)​ 是否得到正式接受项目的书面认可? 9)​ 是否正确评估该项目对“干系人”的价值,并与干系人进行有效地沟通? 10)​ 团队成员是否被很好的安置? 11)​ 绩效评估是否准确地完成? 2.临时性地健康度再分析 在项目运行的过程中,当某些特定情况或事件发生时,应当对项目重新进行健康度的评估,以确定项目的运行是否受到明显的影响,是否存在某些潜在的因素对项目的目标产生影响。 通过对大量的实际案例的分析以及项目经验的总结,我们认为在如下几种情况下应到考虑对项目的健康度进行再评估: (1)项目出现连续3个里程碑事件没有按时完成。 项目运行中的里程碑事件没有按时完成往往有多种原因,一般可以通过技术性的分析加以研究。但如果在项目中连续出现关键里程碑点的延误,则应该怀疑是否存在某些系统性的因素导致出现这种问题,这个时候进行健康度的评估是非常必要的,有助于对项目中各种潜在问题的深入分析。 导致这种情况的某些可能原因包括,项目团队问题,如团队士气、人员技能等等,的问题,对项目工作的分解与计划不够合理,使项目的实际进展与项目基线产生偏差,干系人问题,如与客户方的沟通存在障碍,缺乏客户方的有效支持等等。 但在启动评估前,应排除某些可能的技术性因素导致此类问题的发生,比如某个明显的技术障碍、明显的外部条件问题导致的短期性问题等等。这些操作层面的问题可以通过正常的项目分析手段加以分析与解决。 (2)项目人员在短期内出现较大变化。 当项目中出现较大的人员变化时,对项目重新进行健康度评估是非常必要的,这包括两方面的原因: 第一: 人员变化是因为什么发生的? 如果是因为项目本身的问题导致大量人员变化,则说明项目本身在干系人利益或相关机构利上存在严重的问题,而这些问题是必须加以解决的,否则项目必然在项目的后续运行中产生更为严重的问题。 第二:人员变化本身对项目的运行会产生什么样的影响?这个问题并不完全是一个技术层面的问题,从宏观层面上看,人员变更导致相关干系人间的关系变化,必须重新对项目的整体健康度重新进行评估,以确保新的干系人利益被充分地 了解。 所以,当人员产生较大变更,或关键干系人出现变更时,不论是由于何种原因,重新进行健康度评估都是必须的。 (3)项目的重要Sponsor 对项目的态度发生改变。 有几种可能的情况会导致项目干系人对项目的态度发生改变,比如: 1)​ 项目的外部商业环境出现了变化,使得项目本身对于企业的价值产生了变化,比如上面谈到的第一个案例,就是属于这种情况。 2)​ 项目Sponsor与项目团队间的沟通出现问题,这往往使得Sponsor 对于项目的运行不够了解,从而产生了分歧与误解,使得其态度发生了改变。 3)​ 某些特定的情况的发生,使得Sponsor在短期内的观点发生变化,或是不得不对其计划进行调整,重新平衡企业的资源分配,导致其对特地功能项目的支持力度发生改变。 不论是由于何种原因,当项目重要干系人的态度发生改变时,对项目本身的影响都是巨大的,这个时候从项目管理的角度讲,必须加强与关键干系人的沟通,并对项目的整体健康度重新进行评估,据此对项目进行必要的调整。 (4)项目中产生的变更超出正常水平,或出现较大的变更请求。 在项目管理中产生的项目变更分为主动变更与被动变更,对于被动性的变更,如市场价格的波动导致成本的波动,从管理的角度讲最重要的就是对相关的项目基线进行调整,并与各方充分沟通以适应新的情况。而对于主动变更,管理者必须严格坚持变更控制流程,特别是涉及到项目范围、成本、进度的变更,必须有严格的审批机制,确保项目的各项目标在可控的范围之内。 但是当在一个特定阶段,项目中出现了较多的变更,或较为重大的变更时,则往往意味着项目中可能存在某些潜在的问题没有被充分认识,比如说对用户的业务需求不是充分地了解、对业务运行环境的变化没有充分掌握,或者是对于项目的规划在某些方面存在不合理性,这个时候进行相应的健康度再评估就是非常必要的。 当然,在启动评估过程前,同样应该首先排除某些明显的技术性因素,比如某些不可抗的外部因素等等。 (5)项目由于“非市场”原因导致的连续性的成本超支。 造成项目成本超支的原因同样是多方面的,涉及到外部市场环境、计划的合理性、变更
/
本文档为【项目管理中的项目健康度评估】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。 本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。 网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。

历史搜索

    清空历史搜索