PMI-ACP®认证
适合敏捷开发项目 敏捷项目管理最佳实践
网络课程
PMI-PBA®认证
重视项目商业分析 商业价值与需求分析能力
NPDP®认证
产品管理国际认证 全球产品管理最佳实践
网络课
PMP®认证
单项目管理经典指南 年轻项目经理首选
北京 | 直播 | 录播
PgMP®认证
大型复杂项目全球标准 定位高级项目管理层
网络班
PfMP®认证
链接战略与项目 实现组织资源投资回报
全球直播
软考项目管理
信息系统项目管理师 系统集成项目管理工程师
计划 | 报名 | 经验
版面信息
本版版主
俱乐部导航
联盟·近期活动
社区热点
精彩专题
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
推荐信息
社区圈子
联系社区管理员
几年前,一个资深经理打电话给我,说道:“我们有个项目出问题了。在启动的时候,我们充满了希望,但是现在看来已经不可能了。”我问了几个问题,发现他们之前从来没有做过类似的项目。相对以前,这个项目的规模更大,使用新的开发语言,基于新的平台,而且日程安排更短。 整个公司的未来都押在这个项目的成功上,问题是它比以前做过的项目都要复杂,而且要求也更高。他们唯一的策略就是“希望”。 他们没有安排任何关于项目所在领域、使用的开发语言或新操作系统的培训。他们对这个项目希望能够达到的时间要求,也是以前从未做到的。 仅有希望,不足以交付一个成功的项目。
讲求实效的项目经理会这样做: ·识别风险并记录下来。风险可能来自于技术(新的开发语言、新的平台)、日程安排(时间过短、人太少),很多时候两者皆有。 ·不到万不得已,不要选择瀑布式生命周期。为什么?因为你没有任何数据足以成功支持瀑布式需要的前期计划过程。要是你从未做过类似的项目,用迭代进行原型化,或者通过迭代开发几个功能,看看会是怎么样一个情况。 ·可以用“哈德逊湾式启动”看看是不是能做出些什么东西。要使用即将使用的新的开发语言、操作系统、数据库以及类似新技术,这样做效果尤其好。“哈德逊湾式启动”能够让团队了解要做的东西,而且可以揭示一些目前尚未发现的风险。 ·确保大家具备相关的技术能力,还有解决问题必备的领域知识。有必要的话可以进行培训。让大家学习项目中要用的开发语言,这些投入比起白白浪费时间所付出的成本要低。 ·考虑所有工作都采取迭代的方式进行,特别是项目规划和日程安排。 ·由于缺少经验和专业知识,可以寻求相关的帮助和信息。跟团队成员一起商量如何能让别人了解他们的工作进展。 ·制订里程碑条件(里程碑也可以是迭代的)。在管理层复审会议上审查这些条件。即使管理层或出资人不愿意做复审,项目经理也可以主导这些会议。如果不知道怎么样才能让项目正常运转,可以按里程碑周期性审查项目进度。 不要指望仅凭希望就能得到好的结果。 作为项目经理,你的工作就是要计划、再计划,并努力工作,以得到最好的产出。以下这些实践可以帮你达到目的。 ·使用有时间盒限制的迭代,这样所有的人都可以看到项目的进度。 ·使用速度图表展示项目进度。要让大家都能很明白地看到进度(或匮乏的资源)。这样一来,特别是在需要帮助的时候,这些数据可以拿来使用。 拒绝女王——项目经理应该小心的游戏之三 有些老板就是不愿意面对现实。你告诉他们:“我们无法达到你对时间上的要求。”他们就好像根本没听见,看着你,然后告诉你:“我相信只要你上心,就一定能按时搞定。”你坐在那里哑口无言,他们却高高兴兴地走了,好像项目在他们给出的日期前一定可以交付。出现这样的状况,你就是碰见“拒绝女王”了。 有不少原因会引发“拒绝”。我所见过最常见的原因,就像上面提到的经理,他希望鼓励项目团队。有时,人们拒绝是因为他们害怕项目无法在截止日期之前完成,他们不会管你说什么,这就是鸵鸟效应。有时,公司高层相信:如果设定模糊或是不可能的日期,项目团队就可以早于他们自己预想的时间完成项目。 可以用下面的方式应对“拒绝”。 ·找出为什么你的经理表示拒绝。尝试用一些与上下文无关的问题,以此来理解项目背后的原因。比如,你可以问:“对这个项目来说,要怎么样才算成功?” ·写下项目的风险及其潜在影响。用高、中、低来讨论严重程度和暴露程度,不要用数字。不拿你制订的日程当回事的人,对这些风险数字也不会认真。 ·展示你所能做到的事情,并测量团队在项目中的实际开发速度。没错,这里用迭代是非常方便的,而且速度图表可以告诉别人项目的真实现状。 ·保证参与项目工作的每个人都有相关领域的专业知识。 如果管理层认为“拒绝”是鼓励团队的方式,建议他采取其他的鼓励技巧。通常,这意味着让他去干点儿其他对团队有益的事情(比如通过谈判去缩小需求的范围),或者将他的注意力吸引到别的项目上去。管理层可能认为拒绝现存问题或潜在问题可以鼓励团队,其实这反而会对团队形成障碍。将他们的注意力转移到其他项目上是一种很有用的技巧,可以让他们不再总盯着你的项目。 只要项目经理能够接受现实,“拒绝女王”就不一定能造成灾难。 有个团队试图说服项目经理接受项目的现实。失败几次后,他们放弃了,并且决定自己组织起来,忽略项目经理的存在。他们不再参加项目团队会议,并且将项目经理的话抛在脑后。他们开发了项目的部分功能,并且产生了一些数据(不过不是速度图表)。几个月之后,大家都看出来项目经理根本不了解目前的状况,此人也因此被炒了鱿鱼。可这时,项目团队也已经损失了很多时间,他们很难再控制什么时候交付哪些功能了。 现实总是会在某个时候跟“拒绝”面对面,这不可避免,而且这就是“拒绝女王”为什么只是规划游戏,而不会总是造成灾难的原因。当管理层看到了真正的现实之后,项目经理要确保自己有部分可以工作的产品、可以展示的数据,让管理层可以跟你讨论接下来能够做些什么。此时也是讨论“有哪些事情可以不做”的好时机,这样你就可以完成当前的项目,并且为后续项目做更好的规划。 如果项目经理总是遇到“拒绝女王”,那么在进行管理的时候,可以把下面的方法集成进去,大家也就可以看到实际进展了。 ·使用有时间盒限制的迭代,这样所有的人都可以看到项目的进度。 ·制订排定优先级的产品待办事项。团队可以按照功能的业务价值,从高到低逐个实现。等到出资人如梦初醒,终于意识到项目无法按他给出的日期交付时,团队也已经开发完成了若干高优先级的功能,这样项目经理也会得到一些有价值的东西。 版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明 http://bearwhisper.blogbus.com/logs/33058078.html