CIO：接不接手半截项目

1、.：.；CIO：接不接手半截工程案例背景 “接不接这个半截工程？几天来，小李不断在琢磨着这个问题。在IT圈儿里，接手半截工程的事情时有发生，由于胜利率不高，因此这种事情普通让接手人谈虎色变。 小李是一个新任命不久的IT公司工程经理，被部门经理刘总派去接手一个曾经完成一半的工程，原来的工程经理小张由于公司安排，调到其他工程中了。部门经理刘总阐明，目前工程大部分功能曾经开发完成，单元测试和集成测试曾经完成，由于用户新提出的需求，尚有少部分模块需求进展重新开发。 按照部门经理的引见，重点针对需求修正的模块，小李制定了一个较为明确的工程方案，在不修正其它模块的根底上，只需求30天就可以完成工程，并提交

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

3、围扩展，而且期间又有客户的新需求，所以延期了一个月的时间才完成。 事后，小李被公司的CEO找去，批判他缺乏预见风险的才干以及工程延期的事情。小李以为部门经理刘总当初没有了解清楚工程情况并误导了他，再说工程的范围扩展了很多，延期一个月完成曾经是不错了。小李以为本人当了部门经理刘总的替罪羊。 小李、刘总，小张这几个人都犯了什么错误，小李应该如何做才干做好一个“半截的工程，并得到指点的成认呢? 最大的错企业高层 昆山泓森信息科技管理顾问执行总裁黄绍良： IT部门也缺乏一套完善的开发体系和管理体系，只从个别的进度汇报来衡量工程的进度，未能从交付和用户确认的监控手段来证明汇报的真实结果。 一个工程发生超

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

5、截的工程。其真实实践的情况下，大部分的工程经理都没有选择的权益，但是在没有选择的权益下还是有选择的才干，例如利用足够的数听阐明他手上的工程曾经让他喘不过气来，再向指点阐明新添加的工程对现工程的冲击，影响和风险，建议其他可行的方法，让指点去决议能否应该把这个半截的工程让他担任。 往往这些动作不会影响最终的决议，就是需求接受这个半截的工程，但总可以把其他手上的工程往后推迟，让他有足够的时间来对这半截工程进展评价和方案。 接手一个半截工程在20多年的工程管理生涯中，我的阅历让我深切了解，不要置信任何人通知他的工程一切内容，必需确认、确认再确认，来认证那些信息和结果。从这个案例的描画中可以想象到，该工

6、程缺乏一套完善的开发体系和管理体系，开发过程中很多行政交付包括范围变动管理、风险管理、工程方案和进度报告等和技术交付包括系统架构设计、模块功能规格、原代码和测试报告等都没有到位。 作为一个工程经理，依赖部门经理对工程的了解来继续执行工程的开发是小李犯的错误。小李的处境是相当典型的例子，国内外都有一样的情况发生。我过去在接手一个半截工程的时候，首要是把工程的现状和对工程范围的了解与最终用户确认。由于只需最终用户才知道他们最终的需求。在确认的过程中，能够让客户有方案添加工程的范围，这些不明确的范围便需求与被调走的工程经理确认这个案例说前工程经理被调派去管理另一个工程，所以还有时机跟原工程经理核对整

7、个工程的范围，假设前工程经理的了解与最终用户的最终需求发生冲突的时候，便需马上提升这些争议到管理层，对争议进展仲裁和做出决议。而不是等事情发生后才汇报刘总争取资源和时间。 一个工程经理接手一个半截工程与接手一个新工程没有任何不同，只是一部分技术任务能够曾经完成。接手一个半截工程不代表工程经理不需求思索建立工程范围，思索工程交付方法、工程风险和管理方法。 做好工程经理的任务 前工程经理对工程范围的了解和最终用户对工程的交付需求让高层决议后，便成为这个半截工程的范围，对这范围建立新的基线、方案、质量目的、沟通方案、任务分派和执行风险和进度管理。在过程中更需求有效地监控范围变动，争议，沟通，风险和进

8、度。任何对工程发生影响的情况，需求马上与有关人员进展沟通、协调和达成协议。要是未能达成共识，便需马上提升让管理层知道。这样可以有效地让管理层投入工程中，协助 他处理工程中地困难，同时让管理层也担上一部分的责任。 维护他本人 除了让管理层投入工程中，工程经理更需求严谨记录及执行范围变动，风险评价及应变方法、资源及进度管理。纵然在工程完成后，担任的刘总离任，他还有足够的记录和证据让CEO了解工程的延误“错不在他。 工程管理知识体系除了通知大家一个工程该如何管理外，每一个模块的行政交付都是维护工程经理本身利益的最有效武器，尤其是风险管理。 一个胜利的工程经理不是他本身的职责赋予多少行政权益，是如何利

9、用他本身的才干来影响高层及一切资源，来到达他交付的目的。 每个人都有责任 肯曼管理顾问高级顾问黄晓刚： 从这个案例分析来看，这个IT公司是一个很明显的职能性组织的公司。IT工程隶属于部门管理，部门经理有很大的决策权。 另外一点，该公司并没有建立一套科学有效的IT工程管理的规范和制度。比如：小张分开工程组，没有任何交接手续，没有文档资料。在这个问题上，小张、刘总、小李都应该负有不同程度的责任。 首先分析小张的问题。小张作为前任工程经理，有责任在工程启动初期，根据公司现有的IT工程管理程度，对上级提出建议，建立和完善适宜本公司需求的、或者本工程需求的IT工程管理方法或制度。这个案例中明显反映了该公

10、司在范围管理比如变卦管理、人力资源管理比如团队建立、质量管理比如程序质量、文档产品管理等、风险管理比如范围变动、人员变动、进度变化等存在很多的问题。 另外工程后期改换工程经理是不多见的，能否改换需求提早进展风险分析，决议改换后需求向工程管理委员会或上级提出变卦恳求，进展变卦处置程序。 其次分析刘总的问题。刘总作为部门经理，在新的工程经理没有到来之前，有两种交接方式。一种是：假设刘总不具备工程管理知识根底，可以在小张分开之前，提示小张必需在新岗位任务期间，为工程交接任务保管一定的时间，重返该工程完成交接。另一种是：假设刘总具备一定的工程管理阅历和背景，可以要求小张完成该工程形状的任务总结报告，同

11、时将工程暂时移交给他或工程中心骨干或工程助理，等到新的工程经理到位时，再进展转交。 刘总还犯了一个错误，就是在工程交接变卦过程中短少和CEO的沟通，导致后来CEO指摘小李。严厉意义上讲，在大多数的职能型组织中，CEO直接指摘工程经理是不妥当的。只需在一种情形下这种指摘是成立的。那就是该公司具备本人的工程管理委员会，并且工程经理需求定期向工程管理委员会沟通的，同时CEO是工程管理委员会的成员。 最后分析小李的问题。小李假设工程管理阅历丰富，在接受“半拉子工程前，应该首先对该工程进展能否接受的摸底调研任务，全方位了解工程现状、工程范围、进度、团队、产质量量、沟通机制、存在的风险，然后基于调查的资料

12、和数据，制定未来的工程方案。 第二步才是向刘总进展沟通汇报，并且论述假设接受这样的“半拉子工程，本人作为工程经理的职业原那么和操作方法，为什么要制定这样的方案，为什么需求补充人力资源，如何控制范围，如何控制进度，如何满足工程质量等等。同时别忘了提示刘总需求向工程管理委员会或CEO报告。本人也需求向用户进展沟通，解释工程管理方式和未来的工程方案，并且告知客户在工程后期提出范围变卦对双方存在的风险。 第三步才干在上级或工程管理委员会签字授权情况下，正式接受这个工程。 为了保证完成这个“半截工程，接下来小李需求留意以下几个重点。 要快速建立一套简单有效的工程管理机制，并且通报工程团队新老成员。 一定

13、要控制工程范围，在工程后期进展范围变卦，或者客户提出大的需求更改，普通是不可取的。尽量用一些替代方法来满足需求的变卦，从而使工程进度不至于延期。 要检查工程质量，与客户需求中提出的质量要求进展核对。尽量控制满足工程质量而不是超越，从而也能为进度控制带来益处。 要加强沟通。对工程新老团队成员要进展交融；对部门经理刘总要做到多种方式的汇报、建议和反响；对客户要沟通的不仅仅是需求上的把握了解，还要进展工程管理方法和知识方面的沟通，从而为工程的顺利完工发明条件。当然，还要留意坚持与工程管理委员会或CEO的恰当方式的沟通。 我以为，有了以上这些控制要点，小李在工程后期的任务就会变得更加顺利，“半截工程也

14、不是什么难事。最终，工程的进度也会控制得很好，即使延期一些，也会得到客户、上级指点和团队成员的了解。 管理制度存在艰苦缺陷 工程管理咨询专家周名：工程是复杂的，IT工程更为复杂，没有完善的文档记录，后续任务根本没法高效的继续。该公司的工程管理相关制度需求完善。 该工程问题较多，除去原工程经理小张，新任工程经理小李，部门经理刘总的任务出现问题外，该公司的工程管理制度和流程也有艰苦缺陷。 首先来分析较为直观的各个责任人的问题。 每个人都难辞其咎 原工程经理小张的工程管理较为糟糕。工程管理文档缺乏，对工程小组成员的任务监视考核不到位，向上级反映情况时较为草率，工程在未完成的情况下调任其他工程时，不顾

15、及继任者能够遇到的宏大问题而提供建议报告等问题，反映出小张还不是一名合格的担任任的工程经理。 新任工程经理小李阅历缺乏，也存在很多的问题，集中表达在如下方面：随便接受上级关于工程的引见，不做细致的调查了解；急于求成，大致获取工程情况便着手制定方案；由于任务问题产生心情；方案中忽略模块之间的耦合性。 不过小李对任务的担任态度是值得一定的，而且，虽然由于接受了不准确的信息而产生认识和实践的宏大偏导游致本人方案失策引起了较大的心情，但是还是坚持了“先处理问题，后清查缘由的任务原那么，难能可贵。 部门经理刘总问题较大，难辞其咎。首先，没有严厉要求下属工程经理做好工程文档管理任务；其次，轻信下属的任务汇

16、报，不对其进展校验确认；最重要的是，其在所管工程出现工程经理互换情况时，任务严重不到位，组织新旧工程经理进展工程交接应属于其本职任务，但却没有做导致工程的严重问题。 这些责任人任务出现问题不只是由于其本人的才干和责任感问题，更重要的是由于该公司的工程管理制度和流程存在较为严重的问题。 小李接手工程后，发现工程没有留下什么文档，只能经过销售经理的口头需求和以前的程序来进展任务。工程管理文档缺乏甚至没有，不只是原工程经理小张的问题，更重要的缘由能够是，该公司的工程管理制度中没有对工程管理文档的要求，或者要求不明晰明确，或者没有相应的考评审核机制。 工程是复杂的，IT工程更为复杂，没有完善的文档记录

17、，后续任务根本没法高效的继续。该公司的工程管理相关制度需求完善。 小李接手工程时，不是和原工程经理小张进展工程交接，而是从部门经理刘总处获取资讯。如今通讯技术如此兴隆，即使小张曾经被派往国外，小李也可以经过或者Email与小张进展工程交接。 即使工程没什么文档，那么部门经理刘总能够经过小张的汇报了解工程的大致情况，但是对于工程的详细情况以及存在的问题能够不是很了解，这就需求新任工程经理和原工程经理破费足够的精神做好交接任务。 另外，刘总许愿大部分功能开发完成，并经过了单元测试和集成测试，小李接手后却发现这些模块存在大量的问题。为什么上级担任人获取的信息和实践差距如此之大呢？这也是公司关于单元测

18、试和集成测试的管理不到位的表现，任务没有考评，没有审核，就好似一个黑匣子，导致工程风险甚大。 对于IT工程来说，工程经理的程度和态度也很大程度上决议了工程的胜利和失败，部门经理的决策也对工程出现艰苦变故时能否妥善正确处置有艰苦影响。因此，由于部门经理和工程经理同时出现较为严重的问题，工程失败也在情理之中。 如何做半截工程 “半截工程和普通工程相比，涉及问题更多，更为严重，工程胜利与失败不仅受制于新任工程经理的才干，而且受制于前任工程经理的工程管理情况，以及两任工程经理的交接情况。 笔者也刚中途接手一个对日大工程的一个阶段子工程，可谓“半截工程，下面就以此为例，谈谈笔者对于“半截工程管理的一些领

19、会。 笔者接手的那个半截工程主要任务是进展UT测试单元测试。该工程是一个设计为四层构造P层-C层-F层-D层的复杂的JAVA工程。UT测试分为两部分：一部分是用JUNIT工具进展单层测试，另一部分是对单一模块进展功能测试。单层测试需求首先按照日方要求设计PCL(测试式样书)。成员们对设计PCL不熟习，对JUNIT工具运用也不熟习，对如何运用JUNIT工具实施PCL中的测试案例更不熟习。 工程极为紧张，任务量宏大，日方时间逼得很紧严守纳期是对日外包工程的一大特点，纳期即工期，而很长一段时间十几个人的工程组任务似乎没有什么进展，公司指点焦头烂额。在此情况下，笔者刚终了另一工程，正好被安排来接手此工

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