《突破项目管理的瓶颈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的运作，其实区别并不大。即使有区别也不会超过项目的的不确定因素。完全可以靠项目缓冲来吸收。
