《突破项目管理的瓶颈1》由会员分享,可在线阅读,更多相关《突破项目管理的瓶颈1(6页珍藏版)》请在金锄头文库上搜索。
1、突破项目管理的瓶颈关键链系统整理一、问题:虽然在项目中加入了大量的安全时间,但项目还是会延期。1)先来观察一下我们身边的项目,一般来说,都存在以下问题:(1)成本超出预算(2)时间超出期限(3)项目的规模或设计内容被牺牲。2)在项目失败时,正式的解释都说是其他人的错,比如天气,供应商,环境等(事业环境因素)。但是项目经理给出的原因往往是:(1)公司高层制定不切实际的日程(2)公司因成本而选择不可靠的供应商(3)组建项目团队太晚项目经理下属提出的原因:(1)过分依赖进展报告,事后才发现所报材料不正确。(2)监管不足(3)项目成员频繁的被调派去处理各种突破事故。(4)太多无谓的“协调会议”阻碍项目
2、的进展。所有问题都有一个共同点,就是它们都是其他人的错,我们听见的都是相互攻击。员工的地位越低,矛头越是指向公司内部,而不是外部。 有一点可以肯定,就是我们不应该忽视底层经理的申诉。如果他们说的是对的,那就是说,大部分错误就出自公司内部。换言之,公司内部应该可以把项目管理的更加妥善。当然我们也不能忽视公司高层的意见。他们提出的问题都是一些不确定问题,一些在项目开始时难以预料的东西。不确定因素是所有项目的典型特征。结论:在所有项目中,不确定因素就是大部分问题的主要根源,所以人们为此增加了很多安全时间作为保障。二、问题:项目的安全时间是怎么进入估算中的呢?1、预估时间是根据以往的惨痛经历来制定的。
3、每个领班都会说如果万事俱备,那么准时完成它负责的部分并不困难,虽然他们不会用概率表达,但大概也有8,9成以上的机会完成。但是同时他们都会强调:他们的答案是基于两个假设: 1)他们不被其他人连累而导致延误。2)同一时间没有太多工作要他们分心。2、涉及管理层越多,完工时间预估会越长,因为每层都会加紧各自的安全因素。每当任务有多个步骤组成,而步骤由不同的人负责时,项目负责人便会要求每人做出各自完工时间预估,加起来以后,他也会加上自己的安全时间。即:如果一个人预估自己的任务为5天,下一任务也需5天,项目负责人会说项目总需13天。即:5+5=13。3、预料到高层会削减整体完工时间,各自预先加大安全事件。
4、如果公司高层一半都会在要求削减项目所需时间,比如两成,那么大家就会一开始便把预估时间加大两成半。三、将以上的安全时间通通加起来,安全时间必然占项目预估完成时间的绝大部分。但为什么项目还是不能如期完成呢?1、那是因为同样有三个因素到安全时间被毫无意义的消耗掉。假设有两个连续的步骤,预估时间都是10天。如果第一个步骤实际用了12天,那么第二个步骤就会推迟2天开始。但如果第一个步骤提前2天完成的话,第二个步骤不会提前两天开工。原因大致有如下几个: (1)提前完工不但不会带来奖赏,而且可能导致老板削减预估时间。(2)为下一个步骤分配的资源无法到位。(3)下一步骤的人清楚地知道时间是足够的。一个步骤的延
5、误会全部转嫁到下一个步骤中,而提前完工赚得的时间通常会被浪费掉。同样,当有多个步骤并行的时候,当中最大的延误会转嫁到下一个步骤,但当中任何提前完工(节约的安全时间)却完全起不了作用。这个问题有一个深层次的原因:学生综合症。2、问题:如果项目中出现了下面的情况,多半就是安全时间被浪费了。(1)担当者有时忙有时闲。(2)很多步骤就正好在预估时间完成,分毫不差。还有一个就是多任务,这大概是安全时间的最大杀手。同时开会让每个项目吃尽苦头!结论:以下三个原因会令早完工的所赚的安全时间付诸流水。 (1)学生综合症(2)多任务(3)各步骤之间的依存关系令延误累积四、关键路径和非关路径例:很明显,【兴建建筑物
6、-发挥各种功能-在建筑物内安装各种机器】是关键路径,共需150天。由于关键路径决定了整个项目的完工期,关键路径上的任何延误都会延误整个项目,所以项目经理一定要特别留意它。这是常识。这里的问题是另一条路径挑选供应商,应该在什么时候开始呢?方案1:晚开始这种方法可以推迟投资(实际上包括钱,物,人等各个方面)。方案2:早开始这种方法可以规避风险,避免由于非关键路径上的延迟引起关键路径的延迟。当然实际的项目通常有很多路径,远比这例子复杂。如果所有路径都在最早的起步日期开工,项目经理会疲于本命。这一点考虑应该远比押后投资更重要。当然如果一条路径采取迟的起步日期,它就完全没有空当时间,也就是说这条路径上的
7、任何延误也会导致项目延误。也就是说:如果项目经理采取早的起步日期,他们就无法专注,如果采取迟的起步日期,专注也根本不可能。必须有方法解决这个问题。换一种思路,这里需要一个合适的控制机制来让项目经理保持专注。其实项目都有控制机制用来衡量项目的进展,但问题是,等到进展报告显示有麻烦时,通常已经太迟了。在几乎所有的项目中(即使是有里程碑的项目),使用的衡量方法都没有把关键路径和非关键路径区分开来。这种方法会鼓励尽早启动每条路径,从而导致项目经理从醒目的最开始就不能专注了。因为根据这种衡量方法,一条路径取得的进展,会补偿另一条路径的延误,这实际上就是鼓励一条路径快速进展,虽然另一条路径正被延误。因为这
8、些路径最终会合拢,导致其他路径上赚取的进展,最终都要等待那条延误的路径。五、为了解决上述问题,本书中引入TOC五步法步骤一:识别制约因素通常在一个项目中,制约因素就是关键链。步骤二:决定怎样挖尽制约因素的潜能不浪费关键路径上的时间,因为关键路径上的任何延误都会拖累项目。对策是把每个步奏的预估时间削减,这样就可以释放出足够的时间来建立一个项目缓冲。比如说把每个步骤的时间减少一半,然后将减少的时间的一半作为项目缓冲。步骤三:其他一切都迁就制约因素这有这样才能真正挖尽制约因素的潜能。不懂得迁就,其他路径遇到的麻烦便会直接连累制约因素,令他损失时间,换言之,没有好好保护制约因素。迁就制约因素的方法就是
9、在每条接驳路径与关键路径回合的地方插入时间缓冲,即接驳缓冲。方法就是在每条接驳路径上,将各步骤原来的预估时间减少一半。然后将减少的时间总和的一半作为该路径的接驳缓冲。另外,在某些时候,关键路线上的步骤准备就绪,唯独欠缺相关资源,因为他正忙着其他事情。为了避免这类冲突,可以使用资源缓冲。步骤四:将制约因素松绑通过增加金钱或者资源等,使第一步找到的制约因素不再是制约因素。步骤五:回到步骤一关于资源缓冲,虽然不能为了保护关键路径而让资源在工作开始前一周(比如说)就待命,但是可以在关键路径的工作开始之前发出警号,提醒人们将要到关键路径上工作。最重要的一点是让人们知道,他们必须放下手头所有工作,转而执行
10、关键路线上的工作。在使用这种方法以后,对项目的监控就以以下方式进行:1)对于关键路径就监控项目缓冲,对于非关键路径就监控接驳缓冲。2)是用百分比方式还是绝对时间作为衡量标准都是可以的。3)监控对象不包括尚未开工的步骤,也不包括已经完工的步骤。TOC方法的要点:1)说服各部门消减他们的预估完成时间。2)消除所有的里程碑,换言之,个别步骤不再有目标完工日期。3)适时报告完工预估时间。同时,项目延期对于公司的影响绝不是增加在项目团队上的开发经费,而是公司因为产品推迟上市而少获得的利润以及失去的市场份额。六、关键链当项目按照前面的方法进行监控时,会碰到一个问题:假设其中一条非关键路径(比如3号)进展的
11、实在太慢了,会令整个接驳缓冲耗尽,并已经开始影响了项目缓冲,但(原先的)关键路径却很正常。如果按照一般的管理方式来讲的话,关键路径发生了转移。由于在非关键路径进入关键路径的位置放置了接驳缓冲,改变关键路径,就意味着改变很多接驳缓冲的位置。项目会搞的天翻地覆。但是如果不这样做,在每次关键路径出现严重延误时,就要重整整个项目。在有些情况下,关键路径是到处跳的。每隔一段时间就会遇到这个问题。在非关键路径上,本来一切好端端的,接驳缓冲丝毫未动,突然间问题来了。在想要开始某个非关键路径上的某个步骤,但它需要的资源却不在了。这个资源在另一条也在延迟的非关键路径上工作。例如下图中的情况。下图中有X的步骤是需
12、要专家X执行的步骤。X是多个步骤争夺的资源(resource contention),以致它负荷过重,照成延误。而延误有一条非关键路径传给下一条,连各接驳缓冲也消化不了,所以关键路径会到处跳。在软件开发中,环境准备,成果物评审环节和这个非常类似。为了解决这个问题,让我们首先回到关键路径的定义:需时最长的一串依存的步骤。但是也不要忽视X产能的短缺,不要忽视因公用一个资源而导致两个步奏互相依存的情况。产能极为有限,不可能同时进行两个步骤,只能先后进行,这就是依存关系。这样一来,步骤间的依存关系可以由步骤所在的路径造成,也可以由步骤所共用的资源造成,根据这两类依存关系去找那串需时最长的步骤。一般说来,最长的一串依存的步骤,由不同的部分组成,一部分由于路径本身,另一部分由于资源分配。为了加以区分我们应该先调整一下用词,关键路径仍然称关键路径,即最长的一条路径,但是我们知道最关键的是制约因素,即最长的一串有依存关系的步骤,由于我们必须承认,依存关系也可以是资源引起的,我们就用一个新名词来代表这一串制约因素所在的步骤:关键链。在上面的例子中由于关键链已经成成了制约因素,就必须更改接驳缓冲的位置。下图是调整后的结果。直观图:关于6,13,11,4,2各个步骤的顺序问题,就算用不同的次序编排X的运作,其实区别并不大。即使有区别也不会超过项目的的不确定因素。完全可以靠项目缓冲来吸收。