CIO：接不接手半截项目(1

1、CIO:接不接手半截项目案例背景“接不接这个半截项目？”几天来，小李一直在琢磨着这个问题。在IT 圈儿里，接手半截项目的事情时有发生，因为成功率不高，因此这种事情一 般让接手人谈虎色变。小李是一个新任命不久的 IT 公司项目经理，被部门经理刘总派去接手一个 已经完成一半的项目，原来的项目经理小张由于公司安排，调到其他项目中了。 部门经理刘总表明， 目前项目大部分功能已经开发完成， 单元测试和集成测试已 经完成，因为用户新提出的需求，尚有少部分模块需要进行重新开发。按照部门经理的介绍， 重点针对需要修改的模块， 小李制定了一个较为明确 的项目计划，在不修改其它模块的基础上，只需要 30 天就可以

2、完成项目，并提 交给了部门经理刘总。但是接手项目不久后， 小李发现事实远不像项目经理刘总说的那样， 除了明 确要修改的模块以外， 由于原来的测试人员水平和负责态度很差， 其他模块其实 存在大量的问题， 整个项目模块都需要修改。 而且，由于原来的项目经理水平有 限，没有留下什么文档， 小李和项目组其他成员只能按照销售经理的口头需求和 以前的程序，一点点地修改所有的程序，项目的范围变大了很多。小李找部门经理刘总说明了情况， 刘总才发现他也被原来的项目经理小张欺 骗了，于是他相应地给小李增加了一些资源， 但是小李认为现有的资源还是不足 以按时完成项目。而且，目前的项目情况和当时部门经理刘总的许诺差距

3、太大， 所以小李产生了一定的情绪。项目由于范围扩大， 而且期间又有客户的新需求， 所以延期了一个月的时间 才完成。事后，小李被公司的CEO找去，批评他缺乏预见风险的能力以及项目延期的 事情。小李认为部门经理刘总当初没有了解清楚项目状况并误导了他， 再说项目 的范围扩大了很多， 延期一个月完成已经是不错了。 小李认为自己当了部门经理 刘总的替罪羊。小李、刘总，小张这几个人都犯了什么错误， 小李应该如何做才能做好一个 半截”的项目，并得到领导的承认呢 ?最大的错来自企业高层昆山泓森信息科技管理顾问有限公司执行总裁黄绍良:IT 部门也缺乏一套完善的开发体系和管理体系，只从个别的进度汇报来衡 量项目的

4、进度，未能从交付和用户确认的监控手段来证实汇报的真实结果。一个项目发生超支， 延误导致未能如期交付的时候便需要有人负责， 任何错 误及罪过都直接指向当时负责该项目的项目经理。 所以我常常劝告那些老是抱怨 公司未赋予足够权力的项目经理， 这是他们的“福气”。在这个案例中CE（不指 责刘总，不指责被调职的项目经理，单单批评小李便是最好的说明。其实最大的“错”来自企业的高层管理人员（包括 CEO和部门经理刘总。 这个案例说明国内一个常见的 IT 企业通病，就是企业管理层对 IT 部门缺乏一个 明确的绩效衡量和管理方法，同时 IT 部门也缺乏一套完善的开发体系和管理体 系，只从个别的进度汇报来衡量项目

5、的进度， 未能从交付和用户确认的监控手段 来证实汇报的真实结果。接不接手半截项目除非我们离职， 否则我们不能拒绝半截的项目。 其实在实际的情况下， 大部 分的项目经理都没有选择的权利，但是在没有选择的权利下还是有选择的能力， 例如利用足够的数据说明你手上的项目已经让你喘不过气来， 再向领导说明新增 加的项目对现项目的冲击， 影响和风险， 建议其他可行的方法， 让领导去决定是 否应该把这个半截的项目让你负责。往往这些动作不会影响最终的决定， 就是需要接受这个半截的项目， 但总可 以把其他手上的项目往后推延， 让你有足够的时间来对这半截项目进行评估和计 划。接手一个半截项目在20多年的项目管理生涯

6、中，我的经验让我深切理解，不要相信任何人告 诉你的项目一切内容，必须确认、确认再确认，来认证那些信息和结果。从这个 案例的描述中可以想象到， 该项目缺乏一套完善的开发体系和管理体系， 开发过 程中很多行政交付（包括范围变动管理、风险管理、项目计划和进度报告等）和 技术交付（包括系统架构设计、模块功能规格、原代码和测试报告等）都没有到 位。作为一个项目经理， 依赖部门经理对项目的了解来继续执行项目的开发是小 李犯的错误。 小李的处境是相当典型的例子， 国内外都有相同的情况发生。 我过 去在接手一个半截项目的时候， 首要是把项目的现状和对项目范围的理解与最终 用户确认。 因为只有最终用户才知道他们

7、最终的需求。 在确认的过程中， 可能让 客户有计划增加项目的范围， 这些不明确的范围便需要与被调走的项目经理确认 （这个案例说前项目经理被调派去管理另一个项目， 所以还有机会跟原项目经理 核对整个项目的范围） ，如果前项目经理的理解与最终用户的最终需求发生冲突 的时候， 便需马上提升这些争议到管理层， 对争议进行仲裁和做出决定。 而不是 等事情发生后才汇报刘总争取资源和时间。一个项目经理接手一个半截项目与接手一个新项目没有任何不同， 只是一部 分技术工作可能已经完成。 接手一个半截项目不代表项目经理不需要考虑建立项 目范围，考虑项目交付方法、项目风险和管理方法。做好项目经理的工作前项目经理对项

8、目范围的理解和最终用户对项目的交付需求让高层决议后， 便成为这个半截项目的范围，对这范围建立新的基线、计划、质量指标、沟通计 划、工作分派和执行风险和进度管理。 在过程中更需要有效地监控范围变动， 争 议，沟通，风险和进度。任何对项目发生影响的情况，需要马上与有关人员进行 沟通、协调和达成协议。要是未能达成共识，便需马上提升让管理层知道。这样 可以有效地让管理层投入项目中， 帮助你解决项目中地困难， 同时让管理层也担 上一部分的责任。保护你自己除了让管理层投入项目中， 项目经理更需要严谨记录及执行范围变动， 风险 评估及应变方法、资源及进度管理。纵然在项目完成后，负责的刘总离职，你还 有足够的

9、记录和证据让CEO!解项目的延误“错不在你”。项目管理知识体系除了告诉大家一个项目该如何管理外， 每一个模块的行政交付都是保护项目经理本身利益的最有效武器，尤其是风险管理。一个成功的项目经理不是他本身的职责赋予多少行政权力， 是如何利用他本身的能力来影响高层及一切资源，来达到你交付的目标。每个人都有责任肯曼管理顾问有限公司高级顾问黄晓刚：从这个案例分析来看，这个 IT 公司是一个很明显的职能性组织的公司。 IT 项目隶属于部门管理，部门经理有很大的决策权。另外一点，该公司并没有建立一套科学有效的 IT 项目管理的规范和制度。 比如：小张离开项目组，没有任何交接手续，没有文档资料。在这个问题上，

10、小 张、刘总、小李都应该负有不同程度的责任。首先分析小张的问题。 小张作为前任项目经理， 有责任在项目启动初期， 根 据公司现有的 IT 项目管理水平，对上级提出建议，建立和完善适合本公司需要 的、或者本项目需要的 IT 项目管理方法或制度。这个案例中明显反映了该公司 在范围管理（比如变更管理）、人力资源管理（比如团队建设）、质量管理（比 如程序质量、文档产品管理等）、风险管理（比如范围变动、人员变动、进度变 化等）存在很多的问题。另外项目后期更换项目经理是不多见的，是否更换需要提前进行风险分析，决定更换后需要向项目管理委员会或上级提出变更申请，进行变更处理程序。其次分析刘总的问题。刘总作为部

11、门经理，在新的项目经理没有到来之前， 有两种交接形式。 一种是： 如果刘总不具备项目管理知识基础， 可以在小张离开 之前，提示小张必须在新岗位工作期间， 为项目交接工作保留一定的时间， 重返 该项目完成交接。 另一种是：如果刘总具备一定的项目管理经验和背景， 可以要 求小张完成该项目状态的工作总结报告， 同时将项目暂时移交给他或项目核心骨 干或项目助理，等到新的项目经理到位时，再进行转交。刘总还犯了一个错误，就是在项目交接变更过程中缺少和 CEO勺沟通，导致 后来CEC责备小李。严格意义上讲，在大多数的职能型组织中，CEOS接指责项目经理是不妥当勺。 只有在一种情形下这种指责是成立勺。 那就是

12、该公司具备自 己的项目管理委员会，并且项目经理需要定期向项目管理委员会沟通的，同时 CEC是项目管理委员会的成员。最后分析小李的问题。 小李如果项目管理经验丰富， 在接受“半拉子项目” 前，应该首先对该项目进行是否接受的摸底调研工作， 全方位了解项目现状、 项 目范围、进度、团队、产品质量、沟通机制、存在的风险，然后基于调查的资料 和数据，制定未来的项目计划。第二步才是向刘总进行沟通汇报，并且阐述如果接受这样的“半拉子项 目”，自己作为项目经理的职业原则和操作方法， 为什么要制定这样的计划， 为 什么需要补充人力资源， 如何控制范围， 如何控制进度， 如何满足项目质量等等。 同时别忘了提醒刘总

13、需要向项目管理委员会或 CEC报告。自己也需要向用户进行 沟通，解释项目管理方式和未来的项目计划， 并且告知客户在项目后期提出范围 变更对双方存在的风险。第三步才能在上级或项目管理委员会签字授权情况下，正式接受这个项目。为了保证完成这个“半截”项目，接下来小李需要注意以下几个重点。要快速建立一套简单有效的项目管理机制，并且通报项目团队新老成员。一定要控制项目范围， 在项目后期进行范围变更， 或者客户提出大的需求更 改，一般是不可取的。 尽量用一些替代办法来满足需求的变更， 从而使项目进度 不至于延期。要检查项目质量， 与客户需求中提出的质量要求进行核对。 尽量控制满足项 目质量而不是超越，从而

14、也能为进度控制带来好处。还要进要加强沟通。 对项目新老团队成员要进行融合； 对部门经理刘总要做到多种 形式的汇报、建议和反馈； 对客户要沟通的不仅仅是需求上的把握理解， 行项目管理方法和知识方面的沟通， 从而为项目的顺利完工创造条件。 当然，还要注意保持与项目管理委员会或 CEO勺恰当形式的沟通。我认为，有了以上这些控制要点，小李在项目后期的工作就会变得更加顺利， “半截”工程也不是什么难事。 最终，项目的进度也会控制得很好， 即使延期一 些，也会得到客户、上级领导和团队成员的理解。管理制度存在重大缺陷项目管理咨询专家周名：项目是复杂的， IT 项目更为复杂，没有完善的文档记录，后续工作根本没

15、 法高效的继续。该公司的项目管理相关制度需要完善。该项目问题较多， 除去原项目经理小张， 新任项目经理小李， 部门经理刘总 的工作出现问题外，该公司的项目管理制度和流程也有重大缺陷。首先来分析较为直观的各个责任人的问题。每个人都难辞其咎原项目经理小张的项目管理较为糟糕。 项目管理文档缺乏， 对项目小组成员 的工作监督考核不到位， 向上级反映情况时较为草率， 项目在未完成的情况下调 任其他项目时， 不顾及继任者可能遇到的巨大问题而提供建议报告等问题， 反映 出小张还不是一名合格的负责任的项目经理。新任项目经理小李经验不足， 也存在很多的问题， 集中体现在如下方面： 轻 易接受上级关于项目的介绍，

16、 不做细致的调查了解； 急于求成，大致获取项目状 况便着手制订计划；由于工作问题产生情绪；计划中忽略模块之间的耦合性。不过小李对工作的负责态度是值得肯定的， 而且，虽然由于接受了不准确的 信息而产生认识和实际的巨大偏差导致自己计划失策引起了较大的情绪， 但是还 是坚持了“先解决问题，后追究原因”的工作原则，难能可贵。部门经理刘总问题较大， 难辞其咎。 首先，没有严格要求下属项目经理做好 项目文档管理工作；其次，轻信下属的工作汇报，不对其进行校验确认；最重要 的是，其在所管项目出现项目经理调换情况时， 工作严重不到位， 组织新旧项目 经理进行项目交接应属于其本职工作，但却没有做导致项目的严重问题

17、。这些责任人工作出现问题不只是由于其本人的能力和责任感问题， 更重要的是由于该公司的项目管理制度和流程存在较为严重的问题。小李接手项目后， 发现项目没有留下什么文档， 只能通过销售经理的口头需 求和以前的程序来进行工作。 项目管理文档缺乏甚至没有， 不只是原项目经理小 张的问题，更重要的原因可能是， 该公司的项目管理制度中没有对项目管理文档的要求，或者要求不清晰明确，或者没有相应的考评审核机制。项目是复杂的， IT 项目更为复杂，没有完善的文档记录，后续工作根本没 法高效的继续。该公司的项目管理相关制度需要完善。小李接手项目时， 不是和原项目经理小张进行项目交接， 而是从部门经理刘 总处获取资

18、讯。 现在通讯技术如此发达， 即使小张已经被派往国外， 小李也可以 通过电话或者 Email 与小张进行项目交接。即使项目没什么文档， 那么部门经理刘总可能通过小张的汇报了解项目的大 致情况，但是对于项目的具体状况以及存在的问题可能不是很了解， 这就需要新 任项目经理和原项目经理花费足够的精力做好交接工作。另外，刘总许诺大部分功能开发完成， 并通过了单元测试和集成测试， 小李 接手后却发现这些模块存在大量的问题。 为什么上级负责人获取的信息和实际差 距如此之大呢？这也是公司关于单元测试和集成测试的管理不到位的表现， 工作 没有考评，没有审核，就好像一个黑匣子，导致项目风险甚大。对于IT项目来说

19、，项目经理的水平和态度也很大程度上决定了项目的成功 和失败，部门经理的决策也对项目出现重大变故时能否妥善正确处理有重大影 响。因此， 由于部门经理和项目经理同时出现较为严重的问题， 项目失败也在情 理之中。如何做半截项目“半截”项目和普通项目相比， 涉及问题更多， 更为严重， 项目成功与失败 不仅受制于新任项目经理的能力， 而且受制于前任项目经理的项目管理状况， 以 及两任项目经理的交接情况。笔者也刚中途接手一个对日大项目的一个阶段子项目， 可谓“半截”项目， 下面 就以此为例，谈谈笔者对于“半截”项目管理的一些体会。笔者接手的那个半截项目主要工作是进行 UT测试（单元测试）。该项目是 一个设

20、计为四层结构（P层-C层-F层-D层）的复杂的JAVA项目。UT测试分为 两部分：一部分是用JUNIT工具进行单层测试，另一部分是对单一模块进行功能 测试。单层测试需要首先按照日方要求设计 PCL（测试式样书）。成员们对设计PCL 不熟悉，对JUNIT工具应用也不熟悉，对如何使用JUNIT工具实施PCL中的测试 案例更不熟悉。项目极为紧张， 工作量巨大， 日方时间逼得很紧 （严守纳期是对日外包项目 的一大特点，纳期即工期） ，而很长一段时间十几个人的项目组工作似乎没有什 么进展，公司领导焦头烂额。在此情况下，笔者刚结束另一项目，正好被安排来 接手此项目。很显然这是一个苦差使。 项目出现了技术瓶

21、颈， 组员筋疲力尽， 工作热情不 高，领导不断施压， 情况比案例更为糟糕。 所幸笔者在做另一个项目时也曾跟踪 过这个项目的进展，对使用的技术也有一定的理解。首先，笔者请示上级安排和前任管理者进行工作交接。 笔者拟定了一个交接 谈话提纲，内容包括当前组内成员的状况，包括前任管理者及项目组中对 PCL 和JUNIT了解最深刻的组员对这两种技术的认识，包括当前每个功能模块的单元 测试状况等等。 时间紧急， 在接受工作的当天晚上， 笔者加班和前任管理者就此 在会议室进行了长达 5 个小时的交流。最终，交接完成，技术上达成了共识，不 仅可以把我的理解加入进去， 而且可以很好的保留现有的一些工作成果， 一切都 较为明朗了。其次，笔者设计了一个简易的调查表格， 主要是对于技术的认识以及对当前 项目状况的认识， 当然还包括收集对策和建议的内容。 第二天上午发给了各个组 员，然后召集大家开会讨论。会议持续了很久，最后大家都统一了认识，特别是 对技术的认识， 在工作热情方面也有明显的改善， 笔者基本掌握了每个组员的具 体情况。然后，笔者安排了解最为深入的组员和笔者一起设计 PCL模版，并整理出一 份对PCL质量的检查表，然后使用JUNIT工具模拟了测试，整理了工作流程。笔 者也综合各个组员