栖息谷-管理人的网上家园

[推荐]OPM3发展史

[复制链接] 18
回复
3376
查看
打印 上一主题 下一主题
楼主
跳转到指定楼层
分享到:
发表于 2007-5-24 18:16:58 | 只看该作者 回帖奖励 |正序浏览 |阅读模式

作者:John Schlichter,Ralf Friedrich,Bill Haeck 

本文节选自约翰•斯雷科特(John Schlichter,拉尔夫•福莱德瑞驰(Ralf  Friedrich, 和比尔•哈克(Bill Haeck) 在荷兰Den Haag市举行的2003PMI全球大会欧洲年会上提交的论文。

1998 勇于开拓之年

1998,一项旨在为工业和政府开发一个国际标准的项目获得了授权,这个项目将通过无偿志愿者的努力来完成。与其他这样的努力不同,从许多方面讲,这个项目都是史无前例的。该标准将帮助组织评估和提高他们的项目管理能力和那些通过项目实现组织战略所必需的能力。该标准应该是一个项目管理成熟度模型,为项目、计划和组合管理的最佳实践制定完善标准,并说明达到那些最佳实践所必需的能力。开发成熟度模型的志愿者团队及时地得到了来自不同行业不同地域的专业人士的广泛参与,这是历史上开发一个成熟度模型时没有出现过的事情。这些特征就已经使该项目成为同类中的第一个了。另一个事实则进一步将该团队与其他团队区分开了,即,它几乎是以一个虚拟团队的方式运作的,团队中的大部分成员彼此从来没见过面。本文记录了他们经历的历程以及开发组织项目管理成熟度模型(Organizational Project Management Maturity Model,即OPM3TM)的故事。

OPM3项目授权的决策过程

19985月,由比尔·邓肯(Bill Duncan)领导的美国项目管理协会(PMI)标准委员会决定设计一套项目管理系列标准。在1998年,标准委员会的成员来自于不同行业、不同地域,成员们的个性也不同,他们兴趣广泛,技能各异,处于不同的年龄段。在标准委员会会议后的那天傍晚,有些委员会成员竟要到过山车公园寻求刺激,这在某种程度上表明了打算开发OPM3的喜悦心情。

1998 PMI标准委员会讨论了已由许多PMI成员提出的关于制定一个项目管理成熟度模型标准的可能性方面的问题。“成熟度”这一概念早已随卡内基-梅隆大学软件工程学院(the Software Engineering Institute of Carnegie-Mellon University)在19861993年间开发的用于软件领域的“能力成熟度模型”(CMM)的成功而家喻户晓。PMI标准委员会决定授权一个项目来开发这种标准。虽然PMI的《项目管理知识体系指南》(即 PMBOK® Guide )当时已被广泛应用于管理单个的项目,但是还没有致力于提高组织中项目管理的标准。Eric Jenett 主张标准委员会必须清楚并说明一个组织需要这样一种成熟度模型标准的原因。在最初的联合项目主管Marge Combe Paul Dinsmore 的合作下,该委员会决定第一项任务是分析已存在的成熟模式,该任务被分配给了约翰斯雷科特 。

约翰斯雷科特立即重新考虑Eric Jenett 提出的关于为什么组织中需要这样一种标准的问题,并引导他的团队创建一种标准来帮助组织开发通过项目来实施战略的能力。这样一来,项目管理可以被开发成一种帮助组织达到其战略意图的方法。这一目的有别于《项目管理知识体系指南》的关注单个项目的观点。PMI成熟度模型不会是一个简单的基于《项目管理知识体系指南》的“能力成熟度模型”(CMM)。

1998年的项目管理职业状况

1998年,PMI成员不足5万,取得PMI的项目管理专业人士(PMP)资格认证的人还不到1万。在1998年至2003年的OPM3项目生命周期内,PMI成员增加至10万人以上,PMP也超过5万。

19
发表于 2007-7-7 11:17:29 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
18
发表于 2007-7-2 10:59:46 | 只看该作者
顶上去啊,这个帖子介绍的好,把OPM3的发展体系介绍的非常清晰,感谢楼主的分享![em01][em01]
17
 楼主| 发表于 2007-6-26 08:18:25 | 只看该作者
新东东大家就是关注的少啊。
16
发表于 2007-5-25 11:19:13 | 只看该作者
上 善 若 水 ,厚 德 载 物 .我 欣 赏 这 种 品 格 .
15
发表于 2007-5-24 23:16:22 | 只看该作者
新东东,先好好了解吧。谢谢了。
14
发表于 2007-5-24 22:59:24 | 只看该作者

听好地

13
 楼主| 发表于 2007-5-24 18:30:59 | 只看该作者

尾注:

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,项目管理研究院年度研讨会学术刊物,那什维尔,田纳西,美国。

源自项目管理者联盟

[此贴子已经被作者于2007-5-24 18:32:48编辑过]
12
 楼主| 发表于 2007-5-24 18:26:08 | 只看该作者

教训2002

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

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

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

教训2003

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

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

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

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

 

[全文完]

11
 楼主| 发表于 2007-5-24 18:25:48 | 只看该作者

教训2000

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

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

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

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

教训2001

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

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

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

将世界的政治方面的东西排除在项目之外是非常重要的。哪怕这实施起来常常很困难。

使用高级回帖 (可批量传图、插入视频等)快速回复

您需要登录后才可以回帖 登录 | 加入

本版积分规则   Ctrl + Enter 快速发布  

发帖时请遵守我国法律,网站会将有关你发帖内容、时间以及发帖IP地址等记录保留,只要接到合法请求,即会将信息提供给有关政府机构。
快速回复 返回顶部 返回列表