项目延期的问题有很多，需求管理失控是重要的因素

（一）项目延期，源于开始

身为一个项目经理，项目延期是一个无法绕开的话题。项目进展过程中，千奇百怪的问题都会发生，项目延期几乎是不可避免的。

但是做好项目管理，尽量避免项目延期,或者及时的弥补项目延期带来的损失，是每个项目经理的责任。所有有人戏称项目经理（Project Manager）PM是Poor Man的缩写，由此可见项目经理有多难做！

导致项目延期的问题有很多，其中需求管理失控是重要的因素之一。

小张是一名非常有经验的项目经理，目前在开发的项目进度进展到一半了，难得一切进展正常，有几个小问题也被小张妥善的解决了。结果今天客户来开会，要求大幅修改项目方案，相当于之前2个月的工作全部要重做，但是客户仍然要求项目完工时间不变。否则就取消这个项目。

有经验的项目经理，除非出现不可抗力，通常来说项目出现大幅度延误的概率很低。但是赶上需求变更，再有经验的项目经理也得认栽。小张的遇到事情，想必大家都不陌生。很多项目经理出于对商务的妥协，客户永远是上帝，最后通常都只能咬牙接受。紧接着就是疯狂的项目组加班。这种情况下，成本、质量、进度中总有至少一个要被牺牲。其结果，想必是任何人都不愿意看到的。

01

需求管理？看起来很美好而已

项目的需求管理，一直就是一个难点。PMP也有专门的章节来讲解。

按照PMP的指南，项目的范围管理包含如下几个部分：

1.收集需求，及筛选。统一需求入口与需求语言。

2.定义范围。

3.创建工作分解结构（WBS），对每条需求都分解成为可以执行的部分

4.核实范围，确认每条需求都有记录有被执行并测试。

5.控制范围，管控项目需求变更。当需求变更要发生之前需要进行完整的风险评估，通过需求变更决策并进行书面记录。

每个项目组基本都是按照这个思路来进行操作的。但是在之前的这个案例中，无论小张沟通技能多么高超，流程管控如何严格，也不管需求变更项目的成本上升多少。项目的最终命运不过3种：

1.接受需求变更，项目组赶工尽量追回进度，和客户索取需求变更的成本和损失，同时承担质量风险。

2.拒绝项目变更，项目按照原计划进行，客户自己面对市场竞争带来的高商业风险。

3.拒绝项目变更，项目终止。

这三种选择都有可能存在，最终的选择还是要综合判断变更成本和项目未来的商业价值比较了。

为什么总是发生需求变更这样的事情呢？

02

从开始就是错的

所有的项目，都是有自己的使命的，有的为了经济利益，有的为了实现前瞻科研等等。项目建立初期，愿望都是美好的，相信客户也希望能一次性理清自己的需求，并减少变更，因为所有的乙方的成本（金钱、时间、质量），实际最终总会转嫁到甲方的身上。但是事与愿违，项目一旦启动，需求变更就拉起了序幕。

在《做项目，不得不这么干！》中，作者提到“我们正处在一个不断变化的环境中，换句话说，唯一不变的就是变化，而且变化的速度越来越快。快速变化的环境，项目本身的不确定性，都导致项目变更不可避免。出于同商业环境保持一致，不断出现新的机会、新的问题、新的威胁或新的法律，所以项目变更不可避免。项目的任务、期望及组织的最终目标，都应根据业务变更作出修改。”

小张的项目出现了大幅度的项目需求变更，就是因为客户的项目任务无法满足其组织的目标，被新的商业环境所逼迫，不得不选择做出需求变更。从项目的开始，客户针对自己面临的商业竞争环境及组织目标，项目目标的一致性的理解就出现了偏差，不幸中万幸的是，客户在项目的中期就发现了这个错误。如果到最后才发现的话，就回天乏力了。

需求变更真的没有办法避免吗？的确是！但是可以采取积极的措施来降低发生需求变更的风险。

03

前期很重要：用波特理论来看需求分析

管理学中常用的波特五种力量模型确定了竞争的五种主要来源，简单来讲，这五种力量包括：供应商（上游）讨价还价的能力、购买者（下游）讨价还价的能力、潜在进入的威胁、替代品的威胁、同行业公司的竞争 

波特五力模型用于竞争战略的分析，可以有效的分析客户的竞争环境。项目需求调研时，不妨使用此模型来分析一下客户在市场中处境，有助于项目的需求收集及分析。

1．购买者：注意客户和用户的差别。

项目里面的决策方，通常是甲方，也就是客户，但是通常客户未必是此项目的真正使用者，用户才是。客户购买产品或服务后，再提供给自己的终端用户使用。

需求管理，首先就要明白客户背后的用户，这样才能准确的理解客户需求背后的问题。购买者讨价还价的能力，使他们对企业的产品规格的影响力不同。

需求的变化，或者前期调研模拟时没有准确定位，这种情况下购买者对客户的影响力越大，发生需求变更的可能性越高。所以需求调研时多想想客户背后的用户，模拟他们的使用场景来分析，使得需求调研更加精准。

2. 竞争对手：注意客户的竞争对手在做什么。

对客户的需求影响最大的，除了他们的最终用户，还有他们的竞争对手。竞争对手推出产品的规格和节奏对项目的需求有很大的影响。客户的企业竞争力强，在行业处于领先地位，那么竞争对手的产品规格和节奏对客户的影响力就小，反之则在需求分析时就要着重调研及分析竞争对手的行为，来预测项目的前景，明确开发出来的项目是有价值的，和企业的发展目标一致。

3.来自供应商的变更威胁：

供应商也是每个项目中不容小觑的合作伙伴，尤其是核心部件的供应商。每个供应商的都有各自的成本优势和服务（响应速度）优势，都对企业产生不小的影响。比如设计时使用了某供应商提供的零件，验证完成后供应商提出因缺货问题，需要修改设计来匹配另外一种零件。如果你正在做饼干，只有一个人卖面粉，你别无选择，只能从他们那里买。如果卖面粉的今天供应不上面粉，那么你只能改卖米糕。这就是供应商对产品可能会产生的影响。

4.潜在的新进入者及替代品的威胁

从2007年，第一代iPhone推出以来，以大屏幕、多功能为特点的智能手机渐渐改变了我们的生活，成为了现代生活中必不可少的一个工具，许多红极一时的产品都被手机慢慢取代了，或者被边缘化，或者干脆被淘汰了。比如MP3、卡片相机、收音机等等。iPhone的成功也影响了全球手机公司的产品形态。固守的企业渐渐消亡，比如芬兰巨人诺基亚。目前生存完好的类似企业，基本都是追随苹果脚步，不停调整的产品思路。

与此同时，被殃及的照相机厂家也遭遇了寒冬，松下、奥林巴斯、佳能纷纷砍掉低端卡片相机产品线，越来越多的制造商涌入高端相机市场，或者进度专业的B2B市场。

这就是典型的一个行业的新进入者及替代品对行业里面其他产品的影响。项目需求分析的同时要注意关注行业的新玩家和替代品的产品方向，这亦是企业的竞争来源之一，同时也是导致项目需求变更的一大来源。

04

会执行的项目经理千篇一律懂需求的项目经理万里挑一

项目经理最主要的工作之一就是执行，执行项目的计划，按时按质量的完成项目任务。执行力，是每个项目经理必须具备的才能。相信每个工作3年以上的项目经理，执行能力都不会有问题。

能否成为顶级的项目经理，只有执行力是远远不够的。需求管理能力，是重要的指标之一。一个项目是否能够成功，对需求的准确把握在成功因素中要超过一半以上的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。正如下图所示，项目需求变更越晚，代价就越昂贵，风险也就越高。 

生命周期中随时间而变化的变量影响

所以项目前期，项目经理就要站在更高的角度思考，使用经营的思路来看项目。和客户讨论需求的时候，不能盲目的随从，而是要对其提出对需求多加思考和分析。你觉得客户的想法有问题，其实就是一个提供服务的机会。不仅可以体现出专业度，亦可避免后期潜在的需求变更威胁。


（二）项目延期，都有原因

作为外包大师项目组的一员，每个项目接手后，我们都希望项目能够顺顺利利按照预期交付给客户，然而，实际操作起来难度相当大……

尽管我们已经有了经验丰富的项目管理团队，有着完善的项目管理流程，但是延期的事件还是时有发生。针对延期项目的反思，发现延期项目往往存在以下一些原因。

1. 需求问题

需求是一个项目最终交付的依据。

一个项目的最终需求基本是通过RPD文档双方进行确认，外包大师有标准的RPD文档输出，里面包含了产品的核心目标、主业务流程、功能清单、所有页面、交互逻辑、数据逻辑、异常逻辑、接口逻辑等。


但是在如此规范的文档下还是会不断出现需求扩散、变更甚至于主体业务流程调整的问题，经常我们认为一个简单的调整，会不小心就动了业务的主体，导致整体项目延期情况发生。

在遇到需求问题情况，我们项目经理会组织所有参与项目需求的干系人进行需求评审会议，一般会议步骤如下：

a. 需求变更发起人提出相关问题

b. 所有干系人进行需求分析和确认

c. 需求优先级确认

d. 项目经理重新制定项目排期计划

e. 输出需求变更单

（需求变更单）
需求变更看似简单，但是往往会成为项目按期交付的最大拦路虎，因此建议的客户通过以下几种方式尽可能减少需求变更：

a. 明确自己产品的核心目标和用户群体

b. 需求分析阶段前期把重心放在主体业务流程的确认，主体流程一旦确认尽可能不再做调整

c. 项目的需求变更，尽可能在前期提出，项目越往后期，变更对工期的影响会越大

2. 进度管理

项目过程管理的核心依据是项目计划，一个没有计划的项目势必会延期。

外包大师项目团队有非常专业的计划管理手段，从介入项目了解需求后开始制定项目里程碑计划，一般项目的里程碑计划会包含几个大节点，需求调研、需求设计、UI设计、项目开发及测试、项目验收。每个具体里程碑节点也会相应输出到每一天的执行计划。


漂亮的项目计划并不代表着项目能够按期交付，过程节点的跟进才是致胜的关键。计划的制定代表着我们已经开始在和时间赛跑，每一天进度的实时跟进和汇报，能够在计划产生延期后第一时间发现和解决造成延期的问题，并通过快速跟进、赶工等项目管理手段追赶进度。

3. 实时沟通

项目在启动前，就要和项目干系人之间不断地沟通，项目管理透明化是沟通的依据。经验告诉我们，所有人站在同一个维度才能更好的提高沟通效率。


外包大师对内沟通方式：

a. 每日站会汇报昨天工作完成情况、今天计划工作内容和问题

b. 统一的项目管理工具（jira+wiki），分派任务和查看进度、并使用SVN做项目公共文档资源的存放。

c. 完整的项目管理流程和规范，团队所有成员都按照统一的标准和规范执行，降低内部沟通成本

外包大师对外沟通方式：

a. 每日汇报工作进度

b. 每周阶段性总结项目进度

c. 阶段性输出和演示可交付的成果

在避开需求问题、进度管理，以及实时沟通的项目延期三大坑后，最终面临的是项目顺利交付。从项目的开始到结束，不是哪个项目经理或者某个角色能够擅自决定的，这些都需要项目所有干系人的努力和配合。

所以，当一个项目终于可以告一段落时，我们不妨回顾一下这个项目的过程，看看哪个环节还可以改进得更完美。不管怎么说，一个项目的成功，与团队内每一个成员的努力都分不开的，在回顾的同时，也要怀抱一颗感恩的心。


（三）拒绝项目延期有方法

已知：1个产品经理，2个程序员，1个设计师，1个测试，3个需求，1个deadline。通过这些条件，我们可以很简单的计算出项目delay的概率是100%。（没错，真的很简单啊喂！！！！！）

那么问题来了：求产品经理的心理阴影面积！

其实理论上讲，把控项目进度，并，不是产品经理的职责。传统的软件公司和大型互联网公司都有专职的项目经理，然，大多数中小互联网公司并没有这个职位，于是，这个光荣而MMP的任务，自然就落到产品经理头上了。

俗话说：久病成良医，项目delay的多了，自然也就有办法了。有着多年的项目delay经验（这条可以写入简历，呵呵.jpg）的老K，总结了点经验分享给大家：

  什么原因导致的delay？

首先，要找项目delay的原因，大部分的项目delay，无外乎是以下几个原因：

需求因素：产品经理对需求的把握不精准，在开发期间频繁改需求，因此导致项目delay。（程序猿：偷着乐吧，和谐社会救了你！）

技术因素：如果一个技术团队缺少有经验的技术大牛，那么，他们给出的预估开发周期，通常，是绝对不靠谱的。另外一种技术因素就是，在测试过程中遇到阻断性Bug，短时间内无法解决。

老板因素：没错，特别是创业公司，老板绝对是极其不稳定的X因素。一个不靠谱的老板，提出一个不靠谱的想法，外加一个不靠谱的deadline...来感受一下一个老板的，极其清新脱俗的逻辑思维：

  怎么办？怎么办？怎！么！办！啊！

首先，对自己，需求把控是产品经理最核心的能力之一，是在整个职业生涯中都要去不断提高的。去读书，去学习，去思考，去交流...哎，对了，老K的交流群欢迎你加入哦！在公众号回复：加群。

其次，对技术，靠谱的研发周期=技术提出的周期*1.5 + 两三天的缓冲。。。最根本的解决办法，就是，找个靠谱的技术啊！！（偶尔也可以对老板提个需求）

再次，对老板：我只能说，立场鲜明的，拒绝老板提出的，SB需求，是产品经理的基本职责之一。前提是你得确认需求不靠谱，再就是你得能说服老板。。都看造化。。

  怎么合理的确定项目周期

首先在需求确认时，切记谨慎，把所有用户场景在脑子里多过几遍。另外，小步快跑的迭代方式，也能有效避免项目delay。

其次，需求评审时，稍微复杂点的需求，至少讲3遍，确保技术能听明白。

再次，要求技术拿出详细的排期，详细到每天做什么，然后，整个排期酌情乘以一个系数（1.2-2），外加2-3天的缓冲，就是基本靠谱的开发周期了。

最后，项目进入开发期，每天下班前开短会，确认当日的开发任务的完成情况，然后，视情况加班或提前回家吃鸡！

如果在开发或者测试阶段，发现项目有大概率会delay，这时候，就要MMP了。。解决办法就是：为确保迭代能够如期上线，可以灵活的砍掉部分，不重要或不紧急的需求。

总结一下就是：需求要少点，评审多几遍，技术给排期，自己加个钟，每天看进度，灵活砍需求！

最后，很重要的一点，项目如期上线是手段而不是目的，如果为了能够如期上线而导致产品各种问题或体验不好，那纯属舍本逐末。


（四）项目总是延期交付，有哪些原因

在软件项目中，有很多都是无法按时交付的，原因可以说是各有千秋，解决方案当然也有多种多样，今天我根据自己的经验来分析一下项目延期的一些常见原因以及我能给出的解决方案。
需求理解不清

造成项目延期的最大原因是需求分析阶段没有正确理解客户需求。技术人员一般都是非常自负的，觉得你说的需求我都理解了，甚至在客户还没把需求完全讲清楚之前，就已经开始写代码了，以显示他的能力和能耐。我在前面一篇文章中提到了沟通能力对于技术人员的重要性，在这里就是非常典型的场景。

客户描述需求是从自身的理解和角度出发的，客户跟技术人员是完全不同的两个视角，这就势必会让技术人员得到的需求并不是客户最真实的需求。那么客户在什么时候会发现开发实现的产品跟自己需求有偏差呢，越早发现对项目进展越有帮助，但真实情况是技术没把产品完全做出来之前，客户来确认的东西都是不真实的，等客户发现需求理解不对的时候，要再做调整就已经来不及了，离最初要求的交付时间已经很近很近了，只能接受项目延期的事实，或者接受一个需求不对的产品。

对项目的难度估计不足、工作量估计有偏差

在初步拿到需求的时候，技术人员对需求里面的逻辑和细节理解是不够的，往往会对项目的难度估计不足，绝大部分技术人员在对需求评估工作量的时候都是比较乐观的。例如一个功能他评估出来的时间会是他自己实现的时间，但很少会去考虑如果出现意外需要处理呢？需要跟其他模块的联调呢？出现Bug后的多次修复时间呢？可能很多时间他都不会考虑进去的，而仅仅考虑自己独立实现的工作量。

需求变更

这个也是造成项目延期的重要原因之一，前面讲的是需求理解不清楚，而更多的时候是客户对需求的描述，尽管在需求分析阶段都经过再三确认，但随着时间的推移和环境的变化，客户的需求也会随着变化的。一旦需求有变更，对技术人员来说是最麻烦的事情，可能从设计、编码、测试都需要重新再走一遍，前面做的几个星期的工作量都白干了。

沟通不到位

在理清了需求的情况下，整个软件项目是由一个团队来完成的，这其中就会涉及到人与人之间的沟通和协作。我们知道一个人自己做事情，所有事情的细节和顺序都会在自己脑子里，基本上不会出错的。但一个团队做事情，就要求团队所有人能像一个大脑那样干活，需要长时间的磨合以及各自状态、进度的随时暴露，很多团队很难做到这样协调的配合。一旦有需要合作的人之间沟通不到位，就会产生不必要的耗费，累计多了对项目按时交付也是有较大影响。

针对以上常见原因，按我自己的经验，有以下解决方案以供借鉴：

需求反复沟通确认

跟客户讨论需求的过程要尽可能细致，宁愿前期多花时间进行需求沟通和确认，也不要将需求的沟通放到研发开始之后。一般我会建议按照以下五个步骤进行需求沟通和确认：

1、让客户将需求讲解出来，详细讲解各个细节；

2、根据客户的讲解，将需求以原型文档的形式整理出来，在整理过程中及时跟客户确认疑问点；

3、将原型讲解给技术研发人员，确保客户的需求是在技术上可实现的，同时听取研发的意见和反馈，调整原型；

4、将调整后的原型跟客户讲解，以便客户理解原型的方式和所做的更改；

5、让技术研发人员对原型进行讲解，确保研发人员对需求的理解和客户的需求保持一致。

一般经过这5个步骤后的需求沟通确认，在实施过程中导致需求返工的可能性就比较小了。

正确评估工作量

根据需求进行工作量评估，是所有项目都需要进行的环节，我的经验是由研发人员对需求进行拆解，尽可能将工作任务拆解到1-2天的工作量，只要你能将任务拆分开，表示你对需求的理解透彻，表示你对工作量的评估相对较准确。类似庖丁解牛，在庖丁眼里，整条牛已经分成了若干个器官组合，他非常清楚哪块是什么器官，该怎么下刀子，在庖丁眼里，拆解一条牛需要多少刀、需要多少时间都是非常准确的。同样，在对需求的理解和工作量评估中，只有你能将需求、任务拆解到1-2天的工作量，那说明你对需求任务的理解才到位了，评估出来的工作量才相对准确。

另外，有一个业界常用的做法，就是在研发工程师评估出来的时间基础上，乘以1.5-2倍的系数，得出来的真正工作量时间也是相对靠谱的。

正确管理需求变更

有一句话说：唯一不变的是变化。项目过程中需求变更是非常常见的，而且是一定会存在的。作为项目管理者，对需求变更这个事情要有正确的认识。有些项目管理者对客户说，不允许变更，否则项目就延期。这样的做法可能可以保证项目按时交付，但客户满意度就很低了，因为客户的需求没有得到正确的处理和满足。

我的建议是这样：跟客户要从认知上达成一致，项目按时按质量交付是最重要的，相信客户也一定会认可这个目标。

在这个基础之上，我们要对需求变更进行管理，根据需求的重要性进行分级。如果某个需求变更不做进去，按时交付的项目版本可能就有瑕疵或者不能使用，那么我们就必须得把这个变更做到当前版本中。这时我们还需要去分析引起这次变更的原因，如果是我们自身的原因，那可能跟客户讲清楚后我们自己想办法把它消化掉，如加班啊、加人啊啥的（虽然加人一般是没用的）。如果是因为客户的原因引起的，那我们需要评估这个加进来的任务，对开发进度的影响有多大。需要跟客户沟通清楚，将这个变更的需求加进来，但为了保障项目的按时交付，需要从原有功能列表中减掉一部分优先级低的功能需求。

那些从当前需求拿出来的，或者变更部分不影响当前上线的，也需要排一个功能需求优先级，告知客户在确保这次按时交付后，会根据优先级顺序将这些需求功能尽快处理掉。

只要将这些原则性的东西跟客户沟通清楚，一般客户都是能理解的。

（五）项目进度延期，真相只一个

据麦肯锡国际研究院发布报告，当下，各种大型项目超进度20%以上，超投资更是达到80%以上，自20世纪九十年代以来工程行业生产效率实际在下降，承包商的利润率一直相对较低并且不稳定。而工程行业在应用技术和管理创新上也一直行动迟缓。例如：
●项目策划过程中现场和办公室工作协同程度不够，常常纸上谈兵
●承包商没有被激励进行风险分担和创新，绩效管理不合适，供应链实践也不精细
●行业从来不拥抱新的数字化技术，即使是长期回报显著也不进行前期投入
●研发费用和信息技术的投入大大低于其他行业
随着项目的复杂性和规模日益提高，这一问题更富挑战性。环境敏感性需求的提高意味着传统实践必须变革，富有经验的劳动力和管理人员的短缺会变得越来越严重，这就要求必须采用新的思维方式和工作方式。

规模大点的公司已经投入新的技术和改进实践方法来提高生产效率和项目交付方式，而一些中小规模的企业也在积极寻求各种突破方法，下面，参考微办公一家通信工程行业客户的项目管理方法。
天津市侍卓系统工程有限责任公司是天津市工商行政管理局批准注册的专业从事弱电系统集成及通信用户管线建设，并承揽公用通信网的用户通信管道、用户通信线路、综合布线、及其配套的设备机房工程建设的高科技企业，先后承担了天津移动通信公司、中国网通天津通信公司、天津房地产交易中心等单位的多媒体系统及通信管线系统等一系列工程，以最快的速度将世界先进的多媒体技术、安防技术、会议监控系统和产品引进并应用于社会的各个领域。
轻量级工具与高效服务支持，互联网工具选型的考量
通信工程业务的长足发展离不来对工程师和项目团队的高效管理。在对项目和人员管理的不断探索中，侍卓工程选择将微办公引入公司，搭建内部统一的协作平台。
在选择微办公之前，侍卓工程也尝试了解过其他工程管理软件，但是，和大多数企业一样，很难用得起来，甚至员工花3个月的时间学习并熟悉软件，但协作效率却依然没有得到提升。
传统的项目管理工具，首先界面不友好，体验比较生硬，而且免费的版本没有任何实施服务的支持，遇到问题都只能靠自己去网上寻求解决，而大家很喜欢用的微信，在日常短平快的沟通方面没有问题，但用作专业的工程类项目管理时，很多重要资料都无法沉淀，过期文件无法下载，带来很多管理上的不便。

上下联动横向协作，侍卓工程高速运转
目前，侍卓工程的项目人员、财务、采购、行政等都将日常工作放在微办公上进行，实现了全员上下联动横向协作，内部的沟通协作效率得到提升，日常的工作开展也更加顺畅。
对工程项目的管理是侍卓工程在微办公上的重要使用场景，创建工程项目，然后进行项目的分解，可跟进可控制进度的工作以任务的形式具体分解并指派到人，设置明确的开始时间和截止时间，在同一个项目组里也可以很方便地看到大家的协作过程，直观地看到当前关注的项目具体情况和进度瓶颈。

以前接受领导安排什么就做什么，团队成员多以被动接受的方式在工作，缺乏全局观，现在通过微办公这样的平台，通过项目来统一团队的目标，在目标一致的前提下各自分工，相互协作配合，员工也更愿意提建议以及开放透明的沟通，更好地促进团队工作的积极主动意识。
甚至有员工表示，自从公司用了微办公，每天上班就像打游戏，升级打怪做任务。
的确，用微办公来管理你的日常工作，每完成掉一项任务，都有种“升级”的感觉，不断升级，不断打怪，练就更强的技能！

好工具，和公司共同进步
对很多从事工程项目管理的人来说，勇敢去尝试才是一个管理者应该具有的魄力，所以，作为项目经理，不要再抱怨员工懒散团队难管了，不管自己的公司规模如何，人员怎样，既然做管理，就要善于接受外界信息，帮助自己的团队寻找到最适合的工具，提高工程效率。
侍卓工程和微办公的合作，是一个相互了解，不断深入的过程。好的工具可以陪公司一起进步，微办公的持续迭代能力，也将源源不断地满足企业因业务增长而产生的新需求，贡献高附加值的协同价值。