案例背景

　　“接不接这个‘半截’项目?”几天来，小李一直在琢磨着这个问题。在IT圈儿里，接手半截项目的事情时有发生，因为成功率不高，因此这种事情一般让接手人谈虎色变。

　　小李是一个新任命不久的IT公司项目经理，被部门经理刘总派去接手一个已经完成一半的项目，原来的项目经理小张由于公司安排，调到其他项目中了。部门经理刘总表明，目前项目大部分功能已经开发完成，单元测试和集成测试已经完成，因为用户新提出的需求，尚有少部分模块需要进行重新开发。

　　按照部门经理的介绍，重点针对需要修改的模块，小李制定了一个较为明确的项目计划，在不修改其它模块的基础上，只需要30天就可以完成项目，并提交给了部门经理刘总。

　　但是接手项目不久后，小李发现事实远不像项目经理刘总说的那样，除了明确要修改的模块以外，由于原来的测试人员水平和负责态度很差，其他模块其实存在大量的问题，整个项目模块都需要修改。而且，由于原来的项目经理水平有限，没有留下什么文档，小李和项目组其他成员只能按照销售经理的口头需求和以前的程序，一点点地修改所有的程序，项目的范围变大了很多。

　　小李找部门经理刘总说明了情况，刘总才发现他也被原来的项目经理小张欺骗了，于是他相应地给小李增加了一些资源，但是小李认为现有的资源还是不足以按时完成项目。而且，目前的项目情况和当时部门经理刘总的许诺差距太大，所以小李产生了一定的情绪。

　　项目由于范围扩大，而且期间又有客户的新需求，所以延期了一个月的时间才完成。

　　事后，小李被公司的CEO找去，批评他缺乏预见风险的能力以及项目延期的事情。小李认为部门经理刘总当初没有了解清楚项目状况并误导了他，再说项目的范围扩大了很多，延期一个月完成已经是不错了。小李认为自己当了部门经理刘总的替罪羊。

　　小李、刘总，小张这几个人都犯了什么错误，小李应该如何做才能做好一个“半截”的项目，并得到领导的承认呢?

　　最大的错来自企业高层

　　昆山泓森信息科技管理顾问有限公司执行总裁黄绍良：

　　IT部门也缺乏一套完善的开发体系和管理体系，只从个别的进度汇报来衡量项目的进度，未能从交付和用户确认的监控手段来证实汇报的真实结果。

　　一个项目发生超支，延误导致未能如期交付的时候便需要有人负责，任何错误及罪过都直接指向当时负责该项目的项目经理。所以我常常劝告那些老是抱怨公司未赋予足够权力的项目经理，这是他们的“福气”。在这个案例中CEO不指责刘总，不指责被调职的项目经理，单单批评小李便是最好的说明。

　　其实最大的“错”来自企业的高层管理人员(包括CEO)和部门经理刘总。这个案例说明国内一个常见的IT企业通病，就是企业管理层对IT部门缺乏一个明确的绩效衡量和管理方法，同时IT部门也缺乏一套完善的开发体系和管理体系，只从个别的进度汇报来衡量项目的进度，未能从交付和用户确认的监控手段来证实汇报的真实结果。

　　接不接手半截项目

　　除非我们离职，否则我们不能拒绝半截的项目。其实在实际的情况下，大部分的项目经理都没有选择的权利，但是在没有选择的权利下还是有选择的能力，例如利用足够的数据说明你手上的项目已经让你喘不过气来，再向领导说明新增加的项目对现项目的冲击，影响和风险，建议其他可行的方法，让领导去决定是否应该把这个半截的项目让你负责。

　　往往这些动作不会影响最终的决定，就是需要接受这个半截的项目，但总可以把其他手上的项目往后推延，让你有足够的时间来对这半截项目进行评估和计划。

　　接手一个半截项目

　　在20多年的项目管理生涯中，我的经验让我深切理解，不要相信任何人告诉你的项目一切内容，必须确认、确认再确认，来认证那些信息和结果。从这个案例的描述中可以想象到，该项目缺乏一套完善的开发体系和管理体系，开发过程中很多行政交付(包括范围变动管理、风险管理、项目计划和进度报告等)和技术交付(包括系统架构设计、模块功能规格、原代码和测试报告等)都没有到位。

　　作为一个项目经理，依赖部门经理对项目的了解来继续执行项目的开发是小李犯的错误。小李的处境是相当典型的例子，国内外都有相同的情况发生。我过去在接手一个半截项目的时候，首要是把项目的现状和对项目范围的理解与最终用户确认。因为只有最终用户才知道他们最终的需求。在确认的过程中，可能让客户有计划增加项目的范围，这些不明确的范围便需要与被调走的项目经理确认(这个案例说前项目经理被调派去管理另一个项目，所以还有机会跟原项目经理核对整个项目的范围)，如果前项目经理的理解与最终用户的最终需求发生冲突的时候，便需马上提升这些争议到管理层，对争议进行仲裁和做出决定。而不是等事情发生后才汇报刘总争取资源和时间。

　　一个项目经理接手一个半截项目与接手一个新项目没有任何不同，只是一部分技术工作可能已经完成。接手一个半截项目不代表项目经理不需要考虑建立项目范围，考虑项目交付方法、项目风险和管理方法。

　　做好项目经理的工作

　　前项目经理对项目范围的理解和最终用户对项目的交付需求让高层决议后，便成为这个半截项目的范围，对这范围建立新的基线、计划、质量指标、沟通计划、工作分派和执行风险和进度管理。在过程中更需要有效地监控范围变动，争议，沟通，风险和进度。任何对项目发生影响的情况，需要马上与有关人员进行沟通、协调和达成协议。要是未能达成共识，便需马上提升让管理层知道。这样可以有效地让管理层投入项目中，帮助你解决项目中地困难，同时让管理层也担上一部分的责任。

　　保护你自己

　　除了让管理层投入项目中，项目经理更需要严谨记录及执行范围变动，风险评估及应变方法、资源及进度管理。纵然在项目完成后，负责的刘总离职，你还有足够的记录和证据让CEO理解项目的延误“错不在你”。

　　项目管理知识体系除了告诉大家一个项目该如何管理外，每一个模块的行政交付都是保护项目经理本身利益的最有效武器，尤其是风险管理。

　　一个成功的项目经理不是他本身的职责赋予多少行政权力，是如何利用他本身的能力来影响高层及一切资源，来达到你交付的目标。

　　每个人都有责任

　　肯曼管理顾问有限公司高级顾问黄晓刚：

　　从这个案例分析来看，这个IT公司是一个很明显的职能性组织的公司。IT项目隶属于部门管理，部门经理有很大的决策权。

　　另外一点，该公司并没有建立一套科学有效的IT项目管理的规范和制度。比如：小张离开项目组，没有任何交接手续，没有文档资料。在这个问题上，小张、刘总、小李都应该负有不同程度的责任。

　　首先分析小张的问题。小张作为前任项目经理，有责任在项目启动初期，根据公司现有的IT项目管理水平，对上级提出建议，建立和完善适合本公司需要的、或者本项目需要的IT项目管理方法或制度。这个案例中明显反映了该公司在范围管理(比如变更管理)、人力资源管理(比如团队建设)、质量管理(比如程序质量、文档产品管理等)、风险管理(比如范围变动、人员变动、进度变化等)存在很多的问题。

　　另外项目后期更换项目经理是不多见的，是否更换需要提前进行风险分析，决定更换后需要向项目管理委员会或上级提出变更申请，进行变更处理程序。

　　其次分析刘总的问题。刘总作为部门经理，在新的项目经理没有到来之前，有两种交接形式。一种是：如果刘总不具备项目管理知识基础，可以在小张离开之前，提示小张必须在新岗位工作期间，为项目交接工作保留一定的时间，重返该项目完成交接。另一种是：如果刘总具备一定的项目管理经验和背景，可以要求小张完成该项目状态的工作总结报告，同时将项目暂时移交给他或项目核心骨干或项目助理，等到新的项目经理到位时，再进行转交。

　　刘总还犯了一个错误，就是在项目交接变更过程中缺少和CEO的沟通，导致后来CEO责备小李。严格意义上讲，在大多数的职能型组织中，CEO直接指责项目经理是不妥当的。只有在一种情形下这种指责是成立的。那就是该公司具备自己的项目管理委员会，并且项目经理需要定期向项目管理委员会沟通的，同时CEO是项目管理委员会的成员。

　　最后分析小李的问题。小李如果项目管理经验丰富，在接受“半拉子项目”前，应该首先对该项目进行是否接受的摸底调研工作，全方位了解项目现状、项目范围、进度、团队、产品质量、沟通机制、存在的风险，然后基于调查的资料和数据，制定未来的项目计划。

　　第二步才是向刘总进行沟通汇报，并且阐述如果接受这样的“半拉子项目”，自己作为项目经理的职业原则和操作方法，为什么要制定这样的计划，为什么需要补充人力资源，如何控制范围，如何控制进度，如何满足项目质量等等。同时别忘了提醒刘总需要向项目管理委员会或CEO报告。自己也需要向用户进行沟通，解释项目管理方式和未来的项目计划，并且告知客户在项目后期提出范围变更对双方存在的风险。

　　第三步才能在上级或项目管理委员会签字授权情况下，正式接受这个项目。

　　为了保证完成这个“半截”项目，接下来小李需要注意以下几个重点。

　　要快速建立一套简单有效的项目管理机制，并且通报项目团队新老成员。

　　一定要控制项目范围，在项目后期进行范围变更，或者客户提出大的需求更改，一般是不可取的。尽量用一些替代办法来满足需求的变更，从而使项目进度不至于延期。

　　要检查项目质量，与客户需求中提出的质量要求进行核对。尽量控制满足项目质量而不是超越，从而也能为进度控制带来好处。

　　要加强沟通。对项目新老团队成员要进行融合;对部门经理刘总要做到多种形式的汇报、建议和反馈;对客户要沟通的不仅仅是需求上的把握理解，还要进行项目管理方法和知识方面的沟通，从而为项目的顺利完工创造条件。当然，还要注意保持与项目管理委员会或CEO的恰当形式的沟通。

　　我认为，有了以上这些控制要点，小李在项目后期的工作就会变得更加顺利，“半截”工程也不是什么难事。最终，项目的进度也会控制得很好，即使延期一些，也会得到客户、上级领导和团队成员的理解。

　　管理制度存在重大缺陷

　　项目管理咨询专家周名：

　　项目是复杂的，IT项目更为复杂，没有完善的文档记录，后续工作根本没法高效的继续。该公司的项目管理相关制度需要完善。

　　该项目问题较多，除去原项目经理小张，新任项目经理小李，部门经理刘总的工作出现问题外，该公司的项目管理制度和流程也有重大缺陷。

　　首先来分析较为直观的各个责任人的问题。

　　每个人都难辞其咎

　　原项目经理小张的项目管理较为糟糕。项目管理文档缺乏，对项目小组成员的工作监督考核不到位，向上级反映情况时较为草率，项目在未完成的情况下调任其他项目时，不顾及继任者可能遇到的巨大问题而提供建议报告等问题，反映出小张还不是一名合格的负责任的项目经理。

　　新任项目经理小李经验不足，也存在很多的问题，集中体现在如下方面：轻易接受上级关于项目的介绍，不做细致的调查了解;急于求成，大致获取项目状况便着手制订计划;由于工作问题产生情绪;计划中忽略模块之间的耦合性。

　　不过小李对工作的负责态度是值得肯定的，而且，虽然由于接受了不准确的信息而产生认识和实际的巨大偏差导致自己计划失策引起了较大的情绪，但是还是坚持了“先解决问题，后追究原因”的工作原则，难能可贵。

　　部门经理刘总问题较大，难辞其咎。首先，没有严格要求下属项目经理做好项目文档管理工作;其次，轻信下属的工作汇报，不对其进行校验确认;最重要的是，其在所管项目出现项目经理调换情况时，工作严重不到位，组织新旧项目经理进行项目交接应属于其本职工作，但却没有做导致项目的严重问题。

　　这些责任人工作出现问题不只是由于其本人的能力和责任感问题，更重要的是由于该公司的项目管理制度和流程存在较为严重的问题。

　　小李接手项目后，发现项目没有留下什么文档，只能通过销售经理的口头需求和以前的程序来进行工作。项目管理文档缺乏甚至没有，不只是原项目经理小张的问题，更重要的原因可能是，该公司的项目管理制度中没有对项目管理文档的要求，或者要求不清晰明确，或者没有相应的考评审核机制。

　　项目是复杂的，IT项目更为复杂，没有完善的文档记录，后续工作根本没法高效的继续。该公司的项目管理相关制度需要完善。

　　小李接手项目时，不是和原项目经理小张进行项目交接，而是从部门经理刘总处获取资讯。现在通讯技术如此发达，即使小张已经被派往国外，小李也可以通过电话或者Email与小张进行项目交接。

　　即使项目没什么文档，那么部门经理刘总可能通过小张的汇报了解项目的大致情况，但是对于项目的具体状况以及存在的问题可能不是很了解，这就需要新任项目经理和原项目经理花费足够的精力做好交接工作。

　　另外，刘总许诺大部分功能开发完成，并通过了单元测试和集成测试，小李接手后却发现这些模块存在大量的问题。为什么上级负责人获取的信息和实际差距如此之大呢?这也是公司关于单元测试和集成测试的管理不到位的表现，工作没有考评，没有审核，就好像一个黑匣子，导致项目风险甚大。

　　对于IT项目来说，项目经理的水平和态度也很大程度上决定了项目的成功和失败，部门经理的决策也对项目出现重大变故时能否妥善正确处理有重大影响。因此，由于部门经理和项目经理同时出现较为严重的问题，项目失败也在情理之中。

　　如何做半截项目

　　“半截”项目和普通项目相比，涉及问题更多，更为严重，项目成功与失败不仅受制于新任项目经理的能力，而且受制于前任项目经理的项目管理状况，以及两任项目经理的交接情况。

　　笔者也刚中途接手一个对日大项目的一个阶段子项目，可谓“半截”项目，下面就以此为例，谈谈笔者对于“半截”项目管理的一些体会。

　　笔者接手的那个半截项目主要工作是进行UT测试(单元测试)。该项目是一个设计为四层结构(P层-C层-F层-D层)的复杂的JAVA项目。UT测试分为两部分：一部分是用JUNIT工具进行单层测试，另一部分是对单一模块进行功能测试。单层测试需要首先按照日方要求设计PCL(测试式样书)。成员们对设计PCL不熟悉，对JUNIT工具应用也不熟悉，对如何使用JUNIT工具实施PCL中的测试案例更不熟悉。

　　项目极为紧张，工作量巨大，日方时间逼得很紧(严守纳期是对日外包项目的一大特点，纳期即工期)，而很长一段时间十几个人的项目组工作似乎没有什么进展，公司领导焦头烂额。在此情况下，笔者刚结束另一项目，正好被安排来接手此项目。

　　很显然这是一个苦差使。项目出现了技术瓶颈，组员筋疲力尽，工作热情不高，领导不断施压，情况比案例更为糟糕。所幸笔者在做另一个项目时也曾跟踪过这个项目的进展，对使用的技术也有一定的理解。

　　首先，笔者请示上级安排和前任管理者进行工作交接。笔者拟定了一个交接谈话提纲，内容包括当前组内成员的状况，包括前任管理者及项目组中对PCL和JUNIT了解最深刻的组员对这两种技术的认识，包括当前每个功能模块的单元测试状况等等。时间紧急，在接受工作的当天晚上，笔者加班和前任管理者就此在会议室进行了长达5个小时的交流。最终，交接完成，技术上达成了共识，不仅可以把我的理解加入进去，而且可以很好的保留现有的一些工作成果，一切都较为明朗了。

　　其次，笔者设计了一个简易的调查表格，主要是对于技术的认识以及对当前项目状况的认识，当然还包括收集对策和建议的内容。第二天上午发给了各个组员，然后召集大家开会讨论。会议持续了很久，最后大家都统一了认识，特别是对技术的认识，在工作热情方面也有明显的改善，笔者基本掌握了每个组员的具体情况。

　　然后，笔者安排了解最为深入的组员和笔者一起设计PCL模版，并整理出一份对PCL质量的检查表，然后使用JUNIT工具模拟了测试，整理了工作流程。笔者也综合各个组员的具体情况和项目工作情况，制订了详细的计划，包括加班的具体计划。

　　之后，各个组员根据制订的工作计划，按照设计的模版和工作流程开始紧张的工作，笔者每天根据检查表抽查各个组员的工作成果，并实际察看每个组员的测试工作，发现的问题及时纠正，并对工作计划进行了微调。几天后，一切都在控制之中，项目开始有条不紊的前进。

　　最后，在日方规定的时间期限之前，项目组顺利完成了UT阶段的所有工作，同时根据公司要求整理了项目文档，PCL、测试报告、BUG票等完整的文档很好的反映了工作情况。项目成功了，项目组完成了一个看似不可顺利完成的艰巨任务。

　　半截项目不可怕

　　回顾案例，如果该公司对项目文档管理等管理制度制订很完善，如果前任项目经理完整的对项目的文档进行了管理，并对成员的工作情况进行了考核，如果部门经理安排两任项目经理做好了交接工作，如果新任项目经理在详尽的调查研究，摸清情况后制订较为完善的计划并在适当时予以调整，并统一组员的认识，同时制定一套考察组员工作结果的制度和表格对工作进行确认，确保组员正确的做事，另外根据具体的工作情况，考虑制订合适的加班计划并付诸实施保证工期，那么这个“半截”项目就不大可能失败，CEO出面也就不是批评新任项目经理，而是予以表扬。

　　对于“半截”项目，问题多是自然的。但是，只要接手者具备项目管理的丰富知识、技能和经验，操作正当，把能够控制的因素控制、管理起来，那么只要项目的时间、成本要求不是不可实现的，只要项目的变更不是不可控的，那么“半截”项目是不可怕的。关键在于前后两任项目经理如何去做事。

　　实事求是，尽己所能，妥善考虑，正确做事，是“半截项目”成功的基本要求。只要可控，“半截”项目不可怕!