搜索
CIO：接不接手半截项目案例背景“接不接这个‘半截’项目？”几天来，小李一直在琢磨着这个问题。在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与小张进行项目交接。即使项目没什么文档，那么部门经理刘总可能通过小张的汇报了解项目的大致情况，但是对于项目的具体状况以及存在的问题可能不是很了解，这就需要新任项目经理和原项目经理花费足够的精力做好交接工作。另外，刘总许诺大