【TOC卫星八讲】第三讲 项目管理和工程Project Management & Engineering

但凡接触大小项目和工程人员，千万别错过这一讲，对项目管理而言，TOC的项目管理胜过PMP（戏称拍马屁）课程。《关键链》这本书所讲的内容就是TOC的项目管理，是一本很值得读的书，建议没有看过的童鞋找来读一读。

项目不同，抱怨大同小异：

1.  项目通常无法在原本的到期日完工。

2.  变更太多。

3.  即使预先说好，到需要时仍然会资源短缺。

4.  需要的东西往往无法准时送达。

5.  项目与项目间的优先级会引发争议。

6.  超出预算。

7.  重做的工作太多。

步骤一：改变什么？/问题是什么？识别核心问题并分析

每个项目都承诺了三个不同的任务：

第一是到期日，我们什么时候完成项目。第二是内容，我们要完成什么任务。第三是预算或价格。

冲突图：

背后隐藏了一个假设：原本的承诺是确实可行的。

纵使知道隐藏的假设是错的，原本的承诺不可行，解开了冲突图，但是对于解决项目问题根本没有帮助。因为不这么承诺，企业根本接不到这个项目或无法在市场上立足，甚至导致公司破产。因此，这根本不是解决方法！

必须找出另一种方式来解开冲突图，这个惊人的解决方法，能在现阶段的运作模式下，将不可行的承诺变成可行。

假设这是让整个项目准时完成最好的方法，假定把重心放在局部绩效就能得到整体绩效。

理想VS实际：理想的正态分布存在于教科书中，实际的正态分布如同有人找你说：“我想占用你两分钟时间”，而实际平均时间是15分钟。

理想正态分布图

实际分布图

 

不确定性是项目典型特征，是它的本质。

机率分布的中间值与实际预估的时间之两者差距，就是我们加进的安全时间。

 

墨菲定律(Murphy’s Law):一切可能发生的问题，都必然发生

学生症候群（Students’ Syndrome):如果告诉学生下周考试，学生会反应时间不够。若老师心软说考试推迟到下下周，但实际上学生又有几个一下课就回去开始准备考试呢。在预估时间时会尽量留足安全时间放大需求时间，却并不会立即开始着手去做，且刚开始想着后面还有的是时间进度非常缓慢。

帕金森法则（Parkinson law): 工作会去填满所有可以利用的时间。在项目开始时极力争取要更多的时间，比如说争取要20天，最后谈判下来被砍了2天，变成18天，项目初期进行得很顺利，预估只需用9天便可完成，但这时绝对不会以9天能完成去做，而是放慢速度把这18天给用满，就算是提前了也概不会说出来的，毕竟一旦讲出来，下次的项目时间会被砍得更多。在费用上的体现也极其明显，月初或年初时控制得很紧，到月底或年底时发现没有花完就想方设法地花完，这是人性使然。

实际分布图:考虑了学生症候群和帕金森法则后，项目的实际状况如下图红色曲线

 

因此，不论我们放了多少的安全时间，学生症候群和帕金森法则就会把它消耗掉。

多任务整合: 在项目中，我们常常需要对多任务进行整合，只有所有的子任务互不影响，且只有子任务完成了才能进行下一步的任务，因此，即使有些子任务提前完成了，但仍须等到最后完成的子项才能进行整合。

如上图，A-E为F的前置子任务，F整合这五个任务，而这五个任务有四个为提前完成，只有E为延后了10天完成，看上去A、B、C、D提前累加起来45天完成，但最终对任务还是被拖后了至少10天。

再上图的基础上再假定A-E按时完成的完成的概率是50%，那么F准时开始的概率是多少呢？

F按时完成的概率 = 50% * 50% * 50% * 50% * 50% = 3.125%

多任务要用同一资源: 在许多项目中，会有某个资源不只用在一个地方，这个资源在其它地方也不可或缺。如下图资源Y用于项目两个不同的模块中。

假设准时完成每项任务的机率是50%，紫色箭头指向的任务能准时开始的机率是多少？是50%吗？答案不是50%，因为其必须考虑前置任务的准时完成概率和资源Y在另一个模块准时完成的概率，因此其准时开始的概率是：

50% * 50% = 25%

典型的项目：每种颜色代表不同的资源。

上图项目所放的估计时间，准时完工率为50%，则项目的总时间70天，若以80%的准时完工率，则估计时间会增加一倍，即以140天作为完工天数承诺给客户。电脑模拟出完工的概率如下图：

模拟结果：

1.  1%是<120天完成

2.  黄红框为50%所在，意味着50%的概率是超出承诺的140天

3.  有>10%的概率超过190天完成。

不良多工：一个资源要同时进行多个项目。

如下图，一个资源同时要进行三个项目，每个项目在该资源的完成时间是30天，理想的状况是A项目是在第30天完成，B项目是在第60天完成，而实际的状况会先做A、B、C三个项目之间轮流各做几天，一直在这个三个项目之间换来换去，最后项目之前0切换得到的完成时间如下图所示。真实的情况因项目里的换线时间很久，会比这个更糟，没有人赢，所有人都被拖垮。

三个项目同时进行的模拟结果，单个项目为典型项目，其80%的任务准时完工率，项目时间是140天。

由上可知，把焦点放在每项任务上，以确认整个项目能否准时完成的假设是错的。

步骤二：解决方案是什么？（What is the solution?）

所举实例：F16战斗机在以色列的维修与保养

F16战斗机飞行的时间越长，需要维护时间越长，每架飞机的实际维护内容各有不同，并非书本全有。

改善前：

假设整个部门有70位工程师。如果碰到书上没写的问题，就会把零件送到这个部门，指派一位工程师，他必须指示该做些什么。然后他要到工作站和装配线追踪进度，等到他签名确认完成，这时他的工作才告一段落。现在，每架飞机都会出现上百种书本上没写的问题。可以想象整个情况有多复杂。这个部门的工作量很大。只要一有问题，就指派给一位工程师，然后呢？这位工程师先看一下，然后送到工作站或装配线，接着他要到那里去解释和监督。他到了装配线，现在他们正忙着做其它的事情。他该怎么做？只好回去处理另一个问题。然后他再去工作站看看，他们正在忙。他该怎么做？回去处理下一个问题。前置时间延长。要记得，前置时间延长，在同一段时间新问题还是源源不绝到来。更多问题会指派到他身上。如果他手边有更多的问题，就要进行更多的多任务，如此一来，前置时间就会变得更长。前置时间变得更长，就会有更多问题。极其严重的恶性循环！实际上，这70位工程师，每人至少要负责50个问题。当然，在不良的多任务情况下，前置时间会延长。从指出问题的那一分钟起到结案，平均时间是135天。

他们想尽办法要解决这个问题。例如，只有这个部门的70位工程师，加班时数完全不受限制。但是人们可以加班工作的时数是有限的。他们的效率会下降。他们可以聘请更多的工程师，但是资格符合的工程师人数有限。这些是经验最丰富的优秀工程师。

改善后：

解决方法很简单：每个工程师最多只能负责三个问题。也就是说，问题送到这个部门，但是还不要指派给工程师。每位工程师只能被指派三个问题。什么时候才能再指派新的问题？只有在他完成一个问题后，才能再指派一个新的给他。如果他的第一个、第二个、和第三个问题卡住了，要怎么办？首先，你可以了解前置时间因此缩短了多少。我处理第一个问题，我来找你，你正在忙；我处理第二个问题，我来找你，你很忙；我处理第三个问题，我来找你，你非常忙碌。但是我不必处理其它的问题。我现在要做什么？我会站在你旁边。现在会出现什么情况？你一小时后有时间。而在以前的情况下，我一个月后才会再来找你。

改善结果：

第一个月大概是135天。

然后往下降，五个月后，平均时间不到30天。

还需要再多聘请几位工程师呢？ 0位。

而且还出现一个现象：加班时数几乎变成0。

改善原因：

前置时间可以在不影响产能的情况下大幅缩短，因为拖垮前置时间的不是实际的工作时间，而是从开始到结束的时间。

在不良的多任务情况下，前置时间与任务实际处理的时间并不相关。

解决不良多任务的唯一方法是：大量减少每个资源需要处理的任务数目。

步骤三：如何实现改变？（How to cause the change?）设计实施细节解决方案

找项目中的瓶颈资源：回答以下问题来找出项目中的瓶颈资源。

1.   这些项目最可能在哪里卡得最久？

2.   项目最可能在哪里造成不良的多任务？

3.   在哪里充分运用资源最重要？

4.   哪里最不能浪费资源？

答案是：在工作量最重的部门。

通过任务错开解决不良多工问题：

1.  工作量最重的部门，就是我们要开始把项目错开的地方。错开的方式叫做鼓。

2.  不要把资源分得太散，否则就会造成不良多工。

3.  根据工作量最重的部门来错开，就可以错开所有的部门，在每个地方都减少了不良的多任务。

4.  如果还有很多不必经过任务最重的部门的项目，替它们另外挑选一个部门。

5.  当移动一项任务，整个项目都会跟着移动后，其它任务也会跟着移动。

通过把项目错开的调整，三个项目同时进行，项目A为最高优先级，模拟出与之前同样的项目、同样的资源、和同样的墨菲的仿真结果。项目A明显有很大的改善，项目B和项目C也不会比原先差。

学生症候群和帕金森法则：

我们不在乎某个任务是否准时完成，只在乎整个项目是否能如期完成。也就是说，我们真正应该保护的是谁？不是每个任务，而是整个项目。

也就是说，如果我们想保护所有任务的绩效，而不是个别任务的绩效，我们需要的保护会少于个别保护的总和。

如此一来，我们可以成功地消除学生症候群和帕金森法则。

如果想保护整个项目而非个别任务的绩效，就必须把每项任务内的安全时间拿出来，放到最后面。

拿掉每项任务50%的时间，把从每项任务拿掉的时间相加以后的一半放在最后，不必是全部的时间，至于另一半则是省下来的前置时间。

关键路径：相互依存的任务中的最长路径。下图中的关键路径如黑色虚线所示，总共经过六个任务：A、F、B、G、H和E。

 

关键路径的依存关系只是结构相依，还有另一种资源依存关系。如果完全不同的任务要用到同样的资源，则这个任务必须等到另一个任务完成后，才能利用资源。

关键链：在相互依存的任务中，最长的环链，这里的依存关系可以是结构上或资源上的关系。

关键链便是项目的瓶颈，控制了完成项目要花的时间。

建立项目缓冲：从每项任务拿出一部分的安全时间，即把估计时间减为一半，把它放到最后面还会有剩余。但是必须要记得，不要消耗项目完成缓冲。

如下图绿色为缓冲时间，则项目的承诺完成时间由140天缩减为115天。但会有很多的缓冲时间在后面。

规则是项目完成缓冲应该是项目全部时间的三分之一。

建立接驳缓冲：大部分的任务都在其它路径上，也就是说，墨菲大多出现在关键链以外的地方。但是因为每件事都整合在一起，如果关键链以外的地方受到耽搁，就会影响关键链。不要让其它路径因墨菲而延迟，去影响了关键链的时间。在任何地方只要有项任务进入关键链，必须在接驳的入口处设置缓冲和安全时间，即接驳缓冲。

接驳缓冲是把其它路径的时间扣掉一半，然后放在与关键链接驳的入口处。缓冲大小的规则与项目缓冲规划一致，即每条路径全部时间的三分之一。

下图绿色为项目缓冲，蓝色为接驳缓冲。

 

关键链项目管理的核心：把重点放在缓冲，让它真的能保护我们想保护的两个地方。

一个是充分应用限制，充分应用关键链，创造出项目完成缓冲。

另一个是为了让每件事配合限制，不要让墨菲进入这个敏感地区，创造出接驳缓冲。

通过设置了项目缓冲和接驳缓冲，相同的仿真机、相同的墨菲、相同的资源、相同的项目所模拟的结果：

优先级的设置：

每项任务分别会消耗多少缓冲，每项任务只消耗一种缓冲，如果在关键链上就直接消耗项目完成缓冲，否则就是消耗接驳缓冲，只会消耗一种，在非关键链上的任务只有在消耗完接驳缓冲才会消耗项目完成缓冲。项目完成缓冲的消耗会比接驳缓冲的消耗来得重要。所以不论是资源或管理资源的人必须知道每项任务分别会消耗多少缓冲，才能决定你必须在这里工作、你必须在那里工作。些信息必须在线上实时提供，让每个项目经理都能随时了解，哪一项任务现在消耗了最多的项目完成缓冲。

同样的仿真机、同样的项目、同样的墨菲、同样的资源，唯一的不同是，如果碰到同一个资源处理两项任务时，不用武断的方式来决定，模拟的结果（与上次的模拟结果一样）如下：

由于现实项目中可以赶工，实际的绩效会比这个模拟出来的结果更好。同时，还很理性地跟许多项目经理一起谈话。

绩效评估的方法：

1.  项目的进度到了哪里？完成了多少部分？关键链完成的百分比，就等于整个项目完成的百分比。

2.  已消耗的项目完成缓冲与已完成的关键链之间的比例。例如，一个项目完成了60%,消耗了30%的项目完成缓冲，这代表项目的情况很不错。另一个完成了关键链的10%，却消耗了一半的项目完成缓冲，说明该项目的情况非常糟，最好采取一些行动。

3.  建议实时查看项目完成缓冲消耗的比例。例如,以每个月为例，这个月的工作天总共21天。如果你工作21天，会消耗几天的项目完成缓冲？如果你消耗的项目完成缓冲少于7天，就代表情况改善，你创造了安全时间。如果你消耗的项目完成缓冲大于7天，就代表你多消耗了安全时间。因此你可以在悲剧发生前先采取反应，而且知道该把重心放在哪里。

项目会议如何开？资源把所有的项目都连结在一起，大家都知道该把重心放在哪里，都了解整个情况。

1.  第一个要报告完成了多少关键链的部分？

2.  第二个要报告已完成的关键链与已消耗的缓冲之间的比例。

如果比例很好，那就没事。

如果比例有一点问题，要看你现在消耗的比例是多少？

如果每件事情都很好，就到此为止，我们不必再得知任何与项目相关的信息。

如果情况不是这样，就要再看一件事：目前哪一项任务消耗最多的缓冲？应该采取什么行动来改正这种现象？

小结

1.  永远要牢牢记住，每项任务能否准时完成并不重要，最重要的是如期完成整个项目。

2.  检视每个项目，重新建构项目甘特图。必须跟所有相关的人员一起进行重新建构项目甘特图，因为要拿掉估计时间，然后把部分时间放到最后。在叫人们做这件事之前，请先向他们解释他们在做什么，而且把关键链的项目管理告诉每个人，否则没有人会合作。

3.  要记得，规则不是把估计时间减一半，而是项目完成缓冲占整个前置时间的三分之一，接驳缓冲也占整个接驳路径的三分之一。

4.  取得共识选定一个鼓，把项目选定一个鼓错开。这是负责多项目的高阶主管要做的决定。所谓的鼓，也就是你用来错开项目的资源，它不是瓶颈，它有相当多的额外产能，这一点不要混淆。但是当继续运作，经过了三代的项目，结果会变成真正的瓶颈。

5.  每位项目经理和资源经理，都能在线上实时得知缓冲的情况。

6.  在大型多项目管理中，软件必须是系统的一部分。

原创博客，转载请注明出处：中国式工业工程 http://blog.163.com/lanye_chloe/