案例五：合作项目的风险

8.5 案例五：合作项目的风险
   阅读以下关于信息系统项目管理过程中风险管理方面问题的叙述，回答问题1至问题3。
8.5.1案例场景
    中培信息技术有限公司(Z公司)为某省某运营商建立一个商务业务平台，并采用合作分成的方式。也就是说所有的投资由Z公司方负担，商务业务平台投入商业应用之后运营商从所收取的收入中按照一定的比例跟Z公司作分成。
    同一时间，平台有两个软件公司(Z公司)和Z公司)一起进行建设，设备以及技术均独立，也就是说同时有两个平台提供同一种服务，两个平台分别负责不同类型的用户。
    但是整个项目进行了10个月，并经历了一个月试用期之后。准备正式投入商业应用的第一天，运营商在没有任何通知的情况下，将该商务业务平台上所有的用户都转到了Z公司竞争对手Z公司的平台上去了，也就是停止使用Z公司的商务业务平台。
    整个项目Z公司投资超过两百万，包括软、硬件，以及各种集成、支持、差旅费用，等等。现在Z公司所有的设备被搁置但不能搬走，并没有被遗弃，运营商口头声称还会履行合同，按照原来的分成比例给Z公司分成。但是Z公司无法得知每个月的使用情况、用户多少，所以根本无法知道他们究竟应该拿到多少分成。所以，运营商的口头承诺根本如同鸡肋。
    在出事当天，项目经理王刚呆若木鸡。
    【问题1】(8分)
    请用200字以内文字描述该项目存在的主要问题和原因。
    【问题2】(8分)
    请用300字以内文字描述发生这样的事情，项目经理有没有责任？如果有责任，那么具体有哪些责任？
    【问题3】(9分)
    请用400字以内文字结合你本人的实际项目经验，说明如果你是王经理，你觉得应如何避免这样的事情发生？
8.5.2案例分析
    【问题1】
    类似本案例这种结局的项目很多，风险管理不再只是纸上谈兵，而应有具体的量化评估体系，具体的风险应对对策。由此可见国内企业在项目管理的实施上还没有深入。有很多是整体环境和管理层的问题，但项目经理也具有不可推卸的责任。
    其一，国内企业对项目管理的实施很浅薄：一个普遍现象就是购买所谓专业的项目管理软件来做项目管理，以为这样就可以解决一切问题，就很专业很规范了。但企业本身的管理体系和软件的项目管理思想格格不入，至少没有融合，或者是根本没有深入，在这种背景下的项目管理充其量也就是定期搞个报表哄哄领导。所以一旦项目出现任何风险就会岌岌可危。
    其二，项目管理体系不健全：由于企业管理层对项目管理知识的匾乏，导致公司没有一个比较健全的项目管理体系，正是因为缺乏项目生存环境，所以项目经理们在实施项目的时候四处碰壁，无可奈何。当然这并不是为项目经理推脱责任，这个道理就好像外企的职业经理人空降后全都天折了一样。别忘了项目经理的权利最重要，项目经理没有决策权，做什么都白做。
    其三，项目管理的量化时代迟迟没有到来：这个案例的直接原因就是风险管理的缺乏，如果有一个好的风险预警体系，这种问题应该很早能预料到，能够增加一些防范措施。我们现在所谓的风险管理只是象征性地列个risk list，没有一个很好的量化和评估过程，基本只是个文档。所以这样的管理都是些面子过程。项目经理的职责是跟踪监控，那么没有具体的数据，所谓的监控只能沦为例行公事。
    其实，导致这种状况的原因可能还有些更深层次的外部因素，比如国内企业目前基本是以市场为导向，而中国处于一种市场经济的发展阶段，市场化并不成熟，各种因素导致了企业为了市场而急于求成，本来就缺乏规范管理的企业就更谈不上项目管理了。
    当然种种原因不足以说明我们的项目管理就不能进行了，在这个案例中，项目经理负有不可推卸的责任，你的风险列表里是否已经识别到了这种合同风险或市场风险呢？如果有，那么你是否采取过什么沟通手段和措施。也许你没有根本解决这个问题权利，但你有努力挽救这种结局的责任和义务。
    【问题2】
    软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题，以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度地减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。
    在项目风险管理中，存在多种风险管理方法与工具，软件项目管理只有找出最适合自己的方法与工具并应用到风险管理中，才能尽量减少软件项目风险，促进项目的成功。
项目风险管理是指为了达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控，如图8-3所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生命周期内，风险识别是一个连续的过程。
    (1)风险识别：风险识别包括确定风险的来源，风险产生的条件，描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次就可以完成的事，应当在项目的自始至终定期进行。
    (2)风险量化：涉及对风险及风险的相互作用的评估，是衡量风险概率和风险对项目目标影响程度的过程。风险量化的基本内容是确定哪些事件需要制定应对措施。
    (3)风险应对计划制定：针对风险量化的结果，．为降低项目风险的负面效应制定风险应对策略和技术手段的过程，风险应对计划依据风险管理计划、风险排序、风险认知等依据，得出风险应对计划、剩余风险、次要风险以及为其他过程提供的依据。
    (4)风险监控：涉及整个项目管理过程中的风险进行应对。该过程的输出包括应对风险的纠正措施，以及风险管理计划的更新。
每个步骤所使用的工具和方法详见表8- 1。

    【问题3】
软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IT项目开发中常见的风险有如下几类：

    1．需求风险
    (l)需求已经成为项目基准，但需求还在继续变化。
    (2)需求定义欠佳，而进一步的定义会扩展项目范畴。
    (3)添加额外的需求。
    t4)产品定义含混的部分比预期需要更多的时间。
    (5)在做需求中客户参与不够。
    (6)缺少有效的需求变化管理过程。
    2．计划编制风险
    (1)计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致。
    (2)计划是优化的，是“最佳状态”，但计划不现实，只能算是“期望状态”。
    (3)计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上。
    (4)产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大。
    (5)完成目标日期提前，但没有相应地调整产品范围或可用资源。
    (6)涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
    3.组织和管理风险
    (1)仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长。
    (2)低效的项目组结构降低生产率。
    (3)管理层审查决策的周期比预期的时间长。
    (4)预算削减，打乱项目计划。
    (5)管理层做出了打击项目组织积极性的决定。
    (6)缺乏必要的规范，导致工作失误与重复工作。
    (7)非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
    4.人员风险
    (l)作为先决条件的任务(如培训及其他项目)不能按时完成。
    (2)开发人员和管理层之间关系不佳，导致决策缓慢，影响全局。
    (3)缺乏激励措施，士气低下，降低了生产能力。
    (4)某些人员需要更多的时间适应还不熟悉的软件工具和环境。
    (5)项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低。
    (6)由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作。
    (7)不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性。
    (8)没有找到项目急需的具有特定技能的人。
    5．开发环境风险
    (1)设施未及时到位。
    (2)设施虽到位，但不配套，如没有电话、网线、办公用品等。
    (3)设施拥挤、杂乱或者破损。
    (4)开发工具未及时到位。
    (5)开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具。
    (6)新的开发工具的学习期比预期的长，内容繁多。
    6.客户风险
    (1)客户对于最后交付的产品不满意，要求重新设计和重做。
    (2)客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做。
    (3)客户对规划、原型和规格的审核决策周期比预期的要长。
    t4)客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更。
    (5)客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长。
    (6)客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。
    7．产品风险
    (1)矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作。
    (2)开发额外的不需要的功能(镀金)，延长了计划进度。
    (3)严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作。
    (4)要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作。
    (5)在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题。
    (6)开发一种全新的模块将比预期花费更长的时间。
    (7)依赖正在开发中的技术将延长计划进度。
    8.设计和实现风险
    (1)设计质量低下，导致重复设计。
    (2)一些必要的功能无法使用现有的代码库实现，开发人员必须使用新的库或者自行开发新的功能。
    (3)代码和库质量低下，导致需要进行额外的测试，修正错误或重新制作。
    (4)过高估计了增强型工具对计划进度的节省量。
    (5)分别开发的模块无法有效集成，需要重新设计或制作。
    9．过程风险
    (1)大量的纸面工作导致进程比预期的慢。
    (2)前期的质量保证行为不真实，导致后期的重复工作。
    (3)太不正规(缺乏遵循软件开发策略和标准的意识)，导致沟通不足，质量欠佳，甚至需重新开发。
    (4)过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作。
    (5)向管理层撰写进程报告占用开发人员的时间比预期的多。
    (6)风险管理粗心，导致未能发现重大的项目风险。
    软件项目管理从某种意义上讲，就是风险管理。我们尽量去定义明确不变的需求，以便进行计划并高效管理，但商业环境总是快速变化的，甚至是无序的变化。所以，软件企业在进行项目管理的过程中，必须采用适合自己的风险管理方法进行风险管理，以确保软件项目在规定的预算和期限内完成项目。
8.5.3参考答案
    【问题1】(8分)
    首先，Z公司由于被项目“合作分成”的利益所迷惑，所以对项目的可行性分析和风险分析做得很不够，才会出现全额承担项目费用的情况，将自己的成本控制得非常高，所以项目经理、行政主管都有错。
    其次，虽然Z公司自身承担高额的成本，但对于合同条款的管理没有严格约束，这是导致运营商出现平台停用后没有足够法律条款约束其的后果。所以律师、项目经理需要反省。
    最后，公司需要对项目的技术进一步审核，修正存在的问题，以免运营商提出种种没有达标的借口，并整理相关合同签订时，项目实施中，事后运营商出具的相关的文档为日后可能出现的官司准备。所以整个项目团队都要积极参与。
    【问题2】(8分)
    (1)从本案的商业模式来看，Z公司与运营方实际上首先都是投资方，运营方投入的是品牌和渠道，贵公司投入的是技术和资金，而从本案来看，Z公司好像将自己定位为一个项目执行方，那么一开始已经注定成功的可能性不大，出现这样的问题也在情理之中。
    (2)这个商业模式本身没有问题，有问题的是项目经理在出现了一个潜在的竞争者却“浑然不觉”，毕竟在利益和商业道德之间至少在目前多数人会选择利益，抛弃道德，这个是项目经理在做项目可行性计划时的失误，至少，可行性计划中对这方面的风险分析是有缺陷的。
    (3)项目经理不缺乏项目管理的经验，而缺乏必要的商业运作经验，本项目的失败项目经理要承担部分责任，毕竟在项目执行过程中一定会有很多“蛛丝马迹”表明运营商将会有违约的可能，这时候项目经理应该及时向自己的组织通报项目存在的风险，便于贵公司的高层及时与运营商沟通并约束对方履行合同，当然，本项目失败的根本原因在W公司的高层，至少他们应该承担项目失败成本85％的责任。
    (4)项目经理应提高自己的法律意识和商业意识。
    【问题3】(9分)
    首先，项目的风险管理应该在项目实施之前就应该做好，准备好风险出现时的应急措施。任何项目可能都存在风险性，如何圆满处理和化解风险才是项目经理在管理项目时应该考虑的。
    其次，项目经理如果在与运营商谈此项目之时，就参与进入的话，项目经理是有推卸不了的责任，因为项目经理应该知道项目各方的权责利问题，尽可能把项目风险把握在自己可控之中，并且有一定的法律依据。
    再次，“合作分成”这样的搭建平台的方式本身就具有很大的风险性，但是现在工作中这种合作方式又普遍存在的，这样就要求项目经理应该具有很强的自我法律保护意识，在签署项目合作协议时，应该规范合作各方的权责利，规避项目风险！