1.4　项目管理方法论和框架

今天，大多数公司似乎都认识到需要一种或多种项目管理方法论，但要么创建了错误的方法论，要么滥用了已经创建的方法论。很多时候，公司会在完全不理解需求的情况下就匆忙地开发或购买一种方法论，只是因为它们的竞争对手已经有了这种方法论。正如杰森·查瓦特（Jason Charvat）所说：

使用项目管理方法论是一种商业策略，允许公司最大化项目带给组织的价值。方法论必须不断发展，并进行“调整”，以适应公司不断变化的重点或方向。这几乎是一种思维模式，一种重塑整个组织流程的方式：销售和营销、产品设计、规划、部署、招聘、财务和运营支持。对许多组织来说，这是一种根本性的文化转变。随着行业和公司的改变，它们的方法论也必须改变。否则，它们就会失去重点。

设计和实施一种良好的、灵活的方法论有显著的优势：

■　更短的项目进度。

■　更好地控制成本。

■　更少或没有不必要的范围变更。

■　能够规划更好的执行过程。

■　预测结果更加准确。

■　在项目执行过程中改善客户关系。

■　项目可在执行过程中进行调整，以适应不断变化的客户需求。

■　高层管理人员可以更好地看到状态。

■　执行过程标准化。

■　可以获取最佳实践。

一些方法论是通过一组可以应用到特定项目或情形的表单、指南、模板和检查清单构建的，而不是政策和程序。建立一种单一的企业级方法论并能应用到每个项目上是特别困难的。一些公司已经成功地做到了这一点，但是多数公司成功地维护了不止一种方法论。除非项目经理能够根据他们的需要定制EPM方法论，否则可能需要多个方法论。

有几个原因可以解释为什么良好的意图经常误入歧途。在高管层，方法论可能失败，如果高管们不太了解方法论是什么并认为方法论是：

■　速成法。

■　一个银弹。

■　临时解决方案。

■　项目成功的秘诀。

在工作层，如果方法论出现以下情况，它们也可能会失败：

■　抽象的并且高层次的。

■　缺乏足够的说明来支持这些方法论。

■　不具功能性或没有解决关键领域……

■　忽视行业标准和最佳实践。

■　看起来很吸引人但是很难真正融入业务。

■　使用非标准的项目惯例和术语。

■　在没有解决问题的情况下竞争相似的资源。

■　没有任何绩效指标。

■　因官僚和行政管理的原因，花费了过长的时间。

方法论也可能失败，由于方法论：

■　即使假设和环境输入的因素发生了变化，也必须严格遵守。

■　注重线性思维。

■　不允许有创新思维。

■　不允许在原有需求之外的增值变更。

■　不适合项目类型。

■　太抽象（急于设计）。

■　开发团队忽略了瓶颈和用户社群的关注。

■　过于详细。

■　要花过长时间来使用。

■　对于市场、客户和干系人来说过于复杂，无法理解。

■　没有足够或正确的度量指标。

决定采用哪种方法论不是一件容易的事。有很多因素需要考虑，例如：

■　公司整体战略——作为一个公司，我们的竞争力如何？

■　项目团队规模和/或管理范围。

■　项目的优先级。

■　项目对公司的重要性。

■　方法论及其组成部分的灵活性。

还有许多其他因素可能影响方法论的设计。这些因素包括：

■　企业战略。

■　项目组合中的项目复杂性和规模。

■　高管对项目管理的信心。

■　开发预算。

■　生命周期的阶段数量。

■　技术需求。

■　客户需求。

■　培训需求和成本。

■　支持工具和软件成本。

项目管理方法论是围绕企业的项目管理成熟度水平和企业文化创建的。如果公司在项目管理方面相当成熟，并且拥有一种促进合作、有效沟通、团队合作和信任的文化，那么就可以根据指南、表单、检查清单和模板创建高度灵活的方法论。如前所述，在方法论中增加的灵活性越大，对一系列度量指标和KPI的需求就越大。项目经理可以根据特定的客户为其选择方法论和度量指标中适合的部分。不具备这两种特征中的任何一种的组织在很大程度上依赖用严格的策略和程序所构建的方法论，从而产生了大量的文书工作需求，并伴随着成本的增加，继而去除了项目经理所需要的灵活性，以使方法论适应特定客户的需求。这些严格的方法论通常依赖时间和成本作为唯一的度量指标，并且几乎不可能确定项目的真实状态。

查瓦特将这两种类型描述为轻量级方法论和重量级方法论。

轻量级方法论

不断增加的技术复杂性、项目延迟和不断变化的客户需求给开发方法论领域带来了一场小小的革命。这时一种全新的方法论，也就是敏捷的，是适应性强的，并且在整个过程的每一个环节都涉及客户。许多重量级方法论学家反对引入这些“轻量级”或“敏捷”方法论。这些方法论使用一种非正式的沟通方式。与重量级方法论不同，轻量级项目只有一些规则、实践和文档。项目是在面对面的讨论、会议和向客户传递信息的基础上设计和构建的。采用轻量级方法论的直接区别在于，它们很少以文档为导向，通常会强调较少的项目文档数量。

重量级方法论

传统的项目管理方法论［即系统开发生命周期（Systems Development Life Cycle，SDLC）方法］在本质上被认为是官僚主义或预测性的，并导致了许多不成功的项目。这些方法论越来越不受欢迎。这些方法论是如此耗时费力，以至于整个设计、开发和部署的步伐都变慢了，直到什么也干不成。项目经理倾向于预测每个里程碑，因为他们想要预测每个技术细节（例如，软件代码或工程细节）。这导致管理人员开始要求许多类型的规范、计划、报告、检查点和时间表。重量级方法论试图在很长一段时间内对项目的大部分进行详细的计划。在事情开始发生变化之前，这种方法一直有效，并导致项目经理本能地去抵制改变。

框架

今天，越来越多的公司，特别是那些希望作为业务解决方案分包商在全球市场上竞争的公司，正在使用框架而不是方法论。

■　框架：完成一个项目所需流程的各个部分、原则、片段或组件。其可以包括表单、指南、检查清单和模板。

■　方法论：对部分或框架元素进行有序结构化或分组。其可以作为策略、过程或指南出现。

框架关注必须在所有项目上完成的一系列流程。每个流程都由一系列可应用于特定客户业务需求的表单、指南、模板、检查清单和度量指标支持。度量指标由项目经理、客户和干系人共同确定。

如前所述，方法论是作为一个特定学科（例如，项目管理）的一部分的一系列流程、活动和工具，旨在实现特定的目标。当产品、服务或客户有类似的需求，并且不需要大量定制时，公司开发方法论以便在项目管理的方式上提供某种程度的一致性。在使用这些方法论时，一旦建立了度量指标，通常就会对每个项目保持一致。

随着公司在项目管理方面变得相当成熟，策略和过程被表单、指南、模板和检查清单所取代。这些工具为项目经理提供了更大的灵活性，帮助他们应用方法来满足特定客户的需求。这种灵活性导致在项目管理方法论上的更多非正式应用，而且现在更加需要度量指标了。

今天，这种非正式的项目管理方法已经进行了一些修改，并被称为框架。框架是一种基本的概念结构，用于解决问题，例如一个项目。它包括一组假设、特定于项目的度量指标、概念、价值和流程，为项目经理提供了查看满足客户需求所需内容的方式。框架是构建项目可交付物的骨骼支撑结构。在敏捷和Scrum中大量地应用框架的概念。

只要项目的需求不给项目经理带来很大的压力，框架就可以很好地工作。遗憾的是，在当今混乱的环境中，这种压力似乎在增加，因为：

■　客户正在需求小批量、高品质并在一定程度上定制化的产品。

■　项目生命周期和新产品开发时间被压缩。

■　事业环境因素对项目执行的影响越来越大。

■　客户和干系人希望更积极地参与项目的执行。

■　公司正在与供应商建立战略伙伴关系，每个供应商的项目管理成熟度可能不同。

■　全球竞争迫使企业接受来自不同项目管理成熟度水平的客户的项目。

当干系人希望加速决策过程时，这些压力往往会减缓决策过程。放缓的原因是：

■　项目经理被期望在其有限的知识领域内做出决策。

■　项目经理不愿承担项目的全部责任和所有权。

■　项目管理组织的管理层级过多。

■　风险管理被提升到更高的组织层级。

■　项目经理的领导能力受到质疑。

方法论和框架都是一种机制，通过这种机制，我们可以获得在使用度量指标和KPI时获得的最佳实践和经验教训。图1-1说明了方法论或框架的一般用法。一旦确定了客户和干系人，就可以输入需求、商业论证和伴随的假设。该方法论作为一种指南贯穿《PMBOK®指南》的过程组即启动（Initiation，I）、规划（Planning，P）、执行（Execution，E）、监控（Monitoring and Controlling，M）和收尾（Closure，C）。该方法论还为我们提供了针对特定客户来识别度量指标、KPI和仪表盘报告技术的指南。

有些人认为，一旦交付物被提供给客户并且项目进行了收尾，那么项目就完成了。但事实并非如此。今天，越来越多的公司在方法论的生命周期阶段的末尾增加了另一个生命周期阶段，名为“客户满意度管理”。增加这个阶段的目的是与客户和干系人会面并讨论从项目中学到了什么，包括有关最佳实践、经验教训、度量指标和KPI的知识。这样做的目的是了解在未来的项目中哪些地方可以让该客户做得更好。今天，公司维护度量指标和KPI库的方式与维护最佳实践和经验教训库的方式已经一样了。