2003-项目管理即将发生变化之年

以切实的形式来完成标准

2003年伊始，团队开始致力于提炼现有的模型，主要是为用户优化模型界面，并准备收集测试结果并针对测试结果采取行动。这个模型的一个重大挑战就是它的规模和复杂度。模型应该在一种无压力的情况下打包和公开。这样，在2003年早些时候做出的最重要的一个决定就是OPM3应该以一种多介质的方式向公众公开，一部分用书本的形式，就像最初设想的那样，但模型的主要内容要用CD形式以目录结构展示。这就解决了页码计数的问题（比如：成本、格式因素），但是也显示出很有可能很好地来安排和阐述最佳实践、能力、成果、关键性能指标、度量和相关数据。

在向beta测试委员会提供模型之前，必须完成为保证模型质量而始于2001年的工作。最首要的是，为了保证最佳实践、能力、成果、关键性能指标、度量具有合理的依赖关系、得到好的表述、在语调、时态和文字上保持一致，在这个目录上有大量的工作要做。为了完成这个工作，领导小组授权了一个专门的组，命名为极限评审组（Extreme Review Team (ERT)），贯穿所有步骤去布置整个基线网络。这个组大约花了两个月的时间用成对组员工作方式，分析和修改了变动中的内容以确保交给beta测试员前的质量。

与此同时，领导小组的约翰•斯雷科特和其他人开始辅助技术作者Paul Wesman去完成这样的任务——在书的陈述部分切实地描述这个模型和OPM3的概念。雇佣一个技术作者来做主要标准的撰写工作，其目的在于为该团队提供专业的写作技术并确保最终的产品的风格一致。在2003年的头六个月里，团队主要忙于繁重的撰写、重写、编辑和补充陈述内容。通过这些努力以及后来ERT（极限评审组）的努力，到2003年6月为止，OPM3团队将会提交一个完整的OPM3产品给BETA测试员进行第一次的完全测试过程。

从2002年底到2003年上半年，BETA 测试组，在Tom Keuten的带领下在那些愿意花费必要的时间和人力来测试模型功能和在如何修改/改进产品的方面给出有价值的反馈的工业组织中进行了鉴别、资格认定，并定夺了最后的名单。到2003年中为止，随着陈述和目录部分接近尾声，BETA测试组也在各个顾问组的支持下完成了它的BETA测试组名单。

随着2003年下半年的来临，团队平稳转向终点线，进行最后发布工作。在这个课题的后几个月，由丽莎•克鲁斯韦斯基领导的本地扩大评审组[Home Stretch Review Team(HST)]将作为先头部队指导三轮独立测试，测试的执行者是多个组织，包括从若干企业中招募的beta测试组。最后，经过3轮的修改和评审，团队将向PMI提交模型并发表。尽管还有很多事情需要做，并且时间紧张，但在这个整体性的对OPM3做冒险尝试的背景下，认为这是该课题的结束阶段的想法对我们来说也许是更有鼓励作用的。

标准必须按照进度计划提交给发起人。

专业化机会

在OPM3团队当中有着这样的信心，那就是团队所做的工作将会为这个领域未来的发展提供一个跳板，并且可以在运用项目管理的过程中通过让各个企业公司去学习、评价和最终改进他们获得组织级成功的方式来达到直接迅速的影响。这些成果已经足够让OPM3团队满意的了，但是他们同样也在期待在美国项目管理协会中通过其他专家对此成果的应用来进一步接近项目管理成熟度的目标。团队同时也相信OPM3会成为产生其他标准的平台，比如，它包含了项目组合管理的基础。

最后的思考

在整个OPM3课题的生命周期中，团队经历了很多高潮和低谷，就像在启动这个课题的1998年标准委员会所经历的过山车般的高低环转一样。OPM3的领导层一直提醒团队要“保持主要的事情始终是主要的”。在这个开发原始OPM3过程的结束点，也是推动项目管理专业领域的漫长征程的起点，这个才是我们主要的事情。OPM3的第一个发布就是为了创造这样一个环境来提炼和扩展关于组织级项目管理的知识体系以及改进组织能力以达到他们在项目管理中所贯穿的战略目标。
    OPM3的成果是成百志愿者劳动的结果，他们在整个课题的生命周期中贡献力量，他们是值得承认和感谢的。没有他们，OPM3不会成为现在的样子，（象现在这样）建立在千百年项目管理经验的基础之上。我们要感谢每个离开家庭和朋友花费时间在这上面的人，以及感谢那些对这个专业领域的进步做出贡献的重大活动。

教训1998

最初，最主要的挑战是去赢得达到OPM3目标的民心。一个主要的教训是：人们是因为听到和感受到某些人传达的可能性才参与进来的。一旦有了某种对OPM3的意识，接下来的挑战就是获得对一个策略的接受和承诺。尽管领导层的责任是明确的，领导层发现该课题的组织结构需要在某种程度上非正式化。他们发现褒奖应该是个人化的（通过赞扬和认可的方式），而控制系统应该是强有力的（家长式作风的）。

另 一个教训是：在一个堆积有许多兴趣点的志愿性项目中，在绝大多数志愿者完成对这个目标任何重大的贡献以前，去为志愿活动建立期望值、规则、以及期限是很关 键的。势在必行的两件事其中一个是：当一个用户群出现时对最初建立的关系的完整性给予充分的尊重；另一个是去维护信任，否则这个协会将会分裂或者失败。当 然还必须辨明对志愿者无私美德的修辞，这种精神来源于这样的事实，那就是为这个群体的存在和健康，个人兴趣必须在一个志愿者群体中得到培养，以便在企业和 个人的网络之间产生互相依赖的双赢关系，否则，他们彼此之间并不会去分享他们最好的想法。知识产权将仍然是面向PMI志愿者的战略性兴趣的一个领域。

教训1999

在一个志愿的、真实的环境当中，并不是每个志愿者都是一个好的领导者。需要如下的技能：非常良好的沟通能力、良好的贯彻能力，以及动力。当然冲突矛盾也应该得到管理，还必须加强标准化的工作方式。

改变志愿协议的规则将导致项目延迟。版权分配的引入就曾经导致了课题的一个很大的延迟。

如果没有专职支持，管理如此规模的志愿性项目的基本过程将无法成功实施。需要对志愿者劳动力的管理给与很大的关注。

覆盖了来自各种行业的志愿者以及他们的各种观点的项目需要来自领导层小组对计划、对团队以及对关于项目前景和目标的讨论的持续关注。需要常常提醒每个人：“保持主要的事情始终是主要的事情”。

用一种能够让大的组织象小团队那样快速反应并具有灵活性的结构来组织团队。为了使这种分布式的运作能够成功发挥作用，必须将权力下达到更小的团队，而且它们之间必须互相连接以保证互相间有效的沟通。使得具有这种组织结构的项目或课题成功的必要因素包括：

●         共享的状态：协同合作中的所有部门需要共享状态视图，但不一定是完整的共享数据。

●         共享的计划和目标：通过了解彼此的计划和目标，可以找到避免冲突且仍然满足目标的其他途径。

●         共享的解决过程： 为了建立合作实施的方式，协同合作需要一个协议，或者“道路的规则”，包括优先权的定义和沟通及活动的职责。

教训2000

在一个志愿性的环境当中，大的反复是常见的。工作需求变更、家庭生活变化以及世界上的各种事件都会导致志愿者们参与能力的变化。现实世界加剧了这个问题，因为团队成员们并不是同在一处的，这就使得组织协调更加具有挑战性，要使工作人员们保持参与和集中精力是极其困难的。

在这个OPM3课题当中，最初的工作是复杂而抽象的，而且很多志愿者是直到2003第 一季度才了解这个模型如何以一个现实和实用的形式出现。现在比起过去更加容易解释是在如何开发这个模型的，可是在常常需要返工的过程中，很难让成员们保持 参与紧密联合的、相互依赖的以及概念性的工作。许多志愿者并不习惯这种工作，他们没有看到他们付出劳动后的充分的进展。这个也是造成工作反复的原因。

OPM3课 题主要是个研究项目，类似做探索工作。在最初，精确地划定课题的工作范围不大可能，因为是在研究中显示出那些需要在标准中实现的重要事实的。在开始并没有 明确的解决方案，而且初始问题的解决方案同时也在这种开放式的形式中也带来了新的问题，需要团队成员去解决在这个创造性的过程当中出现的模糊不清的问题。 每次出现一个新的问题，领导层就必须再次召集志愿者去面对这个新的挑战，这个就不像重新指挥有偿工作人员那么容易了。现实环境使得这件事情甚至更加困难， 因为所有的沟通都是通过电子方式的。电子邮件和文档无法保证实时讨论，也无法在电话中去衡量团队的工作动力。在这样的条件下去开发和维护一个进度计划几乎 是不可能的。

由于以上这些原因，随着项目领导层对模型的预想在不断发展变化，达成团队发起人的期望值以及和公众一起来管理团队关系都是困难的。领导层总是承受着这样的压力——既要保护团队免受外力的影响，又要商议工作范畴和提交时间表，还要策划和控制项目的形象。

教训2001

要平衡这样的两个工作，一个是反映着新任务焦点的调整团队组织结构的工作，另一个是在现实环境中保持一个具有连贯性的形象的工作。在这样的环境中，真实的团队比非真实的团队对变化更加敏感。

OPM3的志愿者们可以因为组织级的项目管理过程的创新和其他改革而受到高度的鼓舞。为了保持这种士气，经常的电话会议和面对面的会晤是很重要的。

一个现实的、志愿性质的项目如果没有管理支持就会像一个齿轮里进了沙子的发动机，它不能良好运转，到最后会完全停止工作。尽管管理支持不是个非常辉煌的工作，对项目的成功来讲却是关键性的。可以由一个专职的志愿者或PMI成员来做这个支持工作。

教训2002

人力资源过程，比如培训、认可、奖励、以及资源计划都对真实项目非常重要。“内超系列”培训就证明了只要能够得到告知，他们必须被允许为自己学习，并必须有时间来实践他们学到的东西。

好的计划、文档化和标准化的过程在领导层变化的时候是允许延续的。对志愿性项目来说延续计划是很基本的。

尽管改变范围产生一定的损害，但对项目成功是必要的。在一个大型项目的早期阶段，项目必须接受不稳定性，并且常常发现必须执行的附加活动。后来当完成日期邻近的时候，为了达到预期完成时间的要求，项目可能不得不将这种发现从项目范围中去除掉。OPM3的情况是总可以在未来发布的连续版本中实现改进。

教训2003

2003年的教训不少，但特别突出的很少。首先，在这样的周期的课题上，领导层付出的汗水泪水巨大。摩擦一直持续到课题结束，但团队也从积极激进的、连续的计划中受益匪浅。在一个志愿性项目上，如果一个关键系统或者活动的知识依赖某个个人，对项目来说就会有非常大的风险。

第二，甚至在项目的最后阶段，我们发现我们仍然挣扎着要去维护一个健壮的进度计划，要使它又起作用又要相对不被打扰。一个激进的但平衡的进度控制机制的引入让我们可以在更紧张的控制下保持项目进度而不压迫团队。

第三，2003年更加肯定了这样的需要，就是反复的面对面会晤是最好的、有时是唯一的完成团队协调的途径。一次次的面对面会晤是解决过去看上去完全无法解决的问题的枢纽。在这些会议上产生主意和解决问题远比电话会议要高明得多，不论这些电话内容准备（安排）得多么好。

最 后一个但是非常重要的一个教训就是一个天生的研究项目不能按照标准项目那样执行。研究项目需要一个不同的计划和执行策略，而且如果是志愿者工作者则更难管 理。总的来讲，实践者因为一个研究项目所需的大量返工而感到沮丧。同时，研究项目的范畴随着对新事实的发现而变化。标准项目则更基于工业实践，而不是发 现。工业专家必须同意通用的实践并公开它们。这样范畴和进度更容易得到维护，返工会更少，从而出现受挫的情况也更少。OPM3在最后的一年成为了标准项目。在此之前，它作为一个研究项目，揭示着组织级项目管理的基本原理。

尾注：

1 PMBOK GUIDE指南后来得到美国国家标准研究院认可作为ANSI/PMI 99-001-2000。
2 Stan Rifkin已经在软件工程研究院工作多年并向Watts Humphrey报告，他曾经是《软件工程过程组指南》的作者之一，专门研究如何建立和维系一个组织（即SEPG），而该组织是在软件工程过程改进的组织级关键点。
3 Bredillet, C., Cooke-Davies, T., & Schlichter, J. (2001, 11月).  Beyond the PMBOK® Guide,项目管理研究院年度研讨会学术刊物，那什维尔，田纳西，美国。
4 Terry Cooke-Davies博士一直以来都在为建立由企业组成的知识网络工作，在网络上通过共享数据来发现、共享和创造项目管理的知识。
5 Bredillet, C., Cooke-Davies, T., & Schlichter, J. (2001, 11月).  Beyond the PMBOK® Guide,项目管理研究院年度研讨会学术刊物，那什维尔，田纳西，美国。

源自项目管理者联盟