集成项目实施主要风险规避点(集成项目实施主要风险规避点有哪些)

在软件行业中,一个成功的大型集成类软件项目需要从多个方面进行管理把控,如:技术管理、人员管理、进度管理、沟通管理、风险管理等;

项目风险规避一直都是项目管理的重要问题之一,不同类型的项目会有不同风险产生,有效的风险管理可以大大降低项目中风险事件的发生几率,将对项目的负面影响减少到最低。

本文主要从集成项目的特性入手,进行剖析存在的风险及规避方式。

集成项目实施主要风险规避点(集成项目实施主要风险规避点有哪些)

一、集成项目特性

很多项目在风险分析上,除掉不可抗力,项目类型的特性往往也是风险点产生的诱因之一,在具体列举集成项目有哪些风险之前,首先了解下集成项目具备哪些特性,根据特性逐步分析。

1. 场景多

集成类项目为多种类型项目的统称,根据不同的应用场景,可以拆分或组合成不同的解决方案,如:统一应用集成方案、统一门户集成方案、数据治理集成方案、SOA综合集成方案等。

而对于同一种方案,根据不同用户的业务特殊性和行业要求,通常不会直接用标准方案进行项目实施,都会不同程度上的对产品功能进行定制或扩展,对方案进行对应的调整,提供差异化的解决方案,包括产品的组合、技术架构等,也就是所谓的个性化定制。

2. 产品杂

软件集成项目中,主要用来解决异构应用系统之间的功能、信息、数据的有效传递,过程中对用户、数据等进行有效的治理。

所集成的产品为客户购入的不同厂商、不同平台、不同技术、不同语言的应用,甚至是与其它集成类平台产品相结合,多品牌产品共同进行项目的实施,需要对所用产品本身的兼容性、开发程度、厂商的配合性等进行综合平衡。

3. 牵扯广

进入集成项目阶段的企业很少处在信息化建设初期,通常已经具备较为完善的IT基础设施环境,所处阶段称之为整合阶段,处在整体信息化建设的中后期,项目中会接触不同行业客户的各类软件、平台产品;

这就需要对不同行业、业务场景、厂商的软件/平台类产品有对应的了解和实战经验,要求对不同软件、平台、硬件、网络都有涉猎;

同时IT领域技术发展迅速,项目中一定会接触到前沿技术的应用及融合,这些都很考验实施方产品、方案及团队的软硬实力。

4. 周期长

如上所述,集成类项目与应用系统实施项目周期不同,集成类项目虽然也需要使用对应的产品,但并不像市面上大多数HR、财务、库存等应用系统一样,现场实施安装1-2天后即可完成;

根据不同项目类型,需要实施人员驻场实施3-8个月,难度较高的项目甚至需要分阶段、分期数进行,涉及前期需求调研、功能设计,中期实施开发、上线测试、后期项目终验、运维服务等一系列工作,项目进行中不可预见因素较多,一定程度上加大了项目的实施难度。

二、项目风险剖析

当一个事物的特性越明显,其中隐藏的一些问题也会相对明显,在大型集成项目的实施过程中,不可预见的因素很多,需要经常面临已知、未知的风险,若想从源头管控这些风险,就需要对风险加以分析、管控和防范。

1. 场景多

具体表现为业务场景多,需求不同,解决方案所用产品也各不相同,造成需求理解偏差,产品搭配不合理,业务把控不准,需求蔓延等现象。

1.1 需求理解偏差

  • 需求场景类似,但具备行业性及差异化,造成需求把握不准;
  • 需求调研不全面、设计不严谨,没有涵盖客户全面需求;
  • 没有发现客户潜在需求或表述不明确的需求,没有进行需求引导;
  • 需求整理之后没有与客户反复确认,造成需求纰漏;
  • 缺乏详细功能设计,实现方式、技术难点、约束条件不明确;

1.2 项目需求蔓延

  • 实施方没有进行需求封闭,理顺当下项目实施范围;
  • 实施方没有讲明或客户方不明确需求变更对项目的影响;
  • 项目实施前存在待建系统,随着系统建成产生集成需求(通常很多客户不愿承认这种现象为需求蔓延);
  • 客户方随着项目深入,加深对项目的理解,从而提出更多需求;

1.3 产品方案不配

  • 实施方不具备支撑解决方案落地的产品,二次外包,无法把控项目进度;
  • 实施方个别产品无法匹配客户需求,外采结合打单,产品之间不兼容;
  • 实施方产品不具备当前客户个性化需求,扩展能力差,缺乏二次开发能力;

2. 产品杂

具体表现为百家产品,品牌各异,每个项目需要进行多方面协调、沟通,一旦沟通协调不力、各方配合不到位就会造成项目推进困难,项目进度缓慢等现象。

2.1 各方配合不力

  • 客户方各部门之间的数据源头与协作业务梳理等工作配合性差;
  • 伙伴对产品/项目的技术支持、项目进度推进、节点推进验收等配合性差;
  • 被集成商担心产品影响力受损,不愿响应或配合提供接口或数据;
  • 被集成商最近与客户没有商机上的往来项目,不愿参与配合工作;
  • 客户使用产品版本过低或时间过久,联系不到原厂商或旧版本不在维护范围;
  • 内部团队成员间默契较弱、自我意识强配合能力差、分工不利造成项目延期;

2.2 相关意识缺失

  • 不会利用多方沟通渠道去协调解决问题,选择默默承受问题,不愿沟通解决;
  • 关键时刻不能站出来与客户或被集成厂商进行谈判,表明情况和立场;
  • 不愿表明事实真相,试图用拖延或简略汇报掩盖;
  • 沟通过程中出现偏差,造成信息失真,不利于沟通事项的顺利推进;
  • 沟通方法存在问题,缺乏沟通技巧、交互不明确、无引导性、无重点;

2.3 协调能力不足

  • 对于项目中的困难,无法有效协调内部或外部人员对项目进行协助支持;
  • 对项目过程中人与人之间的关系和矛盾处理能力弱,处事过于激进或平和;
  • 无法明确掌握每个阶段所需要协调的重点事宜,错失协调或沟通的良机;

3. 牵扯广

具体表现为项目涉及行业多、业务广,需要接触不同层面的技术产品或架构理念,如果业务知识浅显、技术能力、实战经验欠缺,就无法顺利交付项目。

3.1 业务知识欠缺

  • 实施人员对客户所在行业业务不了解,无法有效理顺客户业务流程;
  • 没有回归业务,比起业务更重视技术功能上的实现,从而脱离项目本质;
  • 对客户所用系统不了解,包括系统的功能、语言、版本、数据库等信息;
  • 功能无法与业务进行正确的对照,无法辨别客户需求中的错误,被动实施;

3.2 实战经验薄弱

  • 没有承接过类似行业或集成类型的项目,整体业务及项目流程不够熟悉;
  • 实施人员对项目所用实施产品熟悉度不够,无法灵活运用;
  • 实施人员对于项目里程碑、沟通方式、人际关系、协调合作等拿捏不准;
  • 按照计划进行不变通,没有充分为预见风险或为解决潜在的风险预留时间;

3.3 产品功能缺陷

  • 产品功能远达不到项目中要求,无法直接用于项目,需要后期扩展;
  • 实施过程花费时间解决产品功能缺陷,或用其它不熟练的工具弥补产品缺陷;
  • 在项目中孵化产品新功能或升级产品功能,产品扩展开发工作量增加,时间成本花费较多;
  • 产品存在安全性问题,无法满足项目中安全方面需求;
  • 与其它同类型产品集成、兼容性差,实施厂商缺乏底层代码级管控能力;

4. 周期长

具体表现为项目规模较大、周期较长,无论是人力、物力都会有一定程度的消耗,容易受地理环境、周围因素、消极情绪等影响。

4.1 交付体系混乱

  • 没有完备的项目交付体系,对项目中的人员管理、沟通管理、技术管理、计划管理、文档管理、风险管理、交付管理能力弱;
  • 缺少项目整体/细分计划,随着项目各个里程碑节点进行与变动,对应计划调整、应对能力差;
  • 没有综合项目管理机制,在不断的摸索中完善机制,无法识别和管理风险;
  • 难点攻克时期,缺少团队人员支撑,内部协调能力弱,无良好的应对手段;
  • 缺少项目考核机制,对于项目奖惩不明确,关键问题难以问责及及时总结;

4.2 人员产生变动

  • 项目周期长,长期出差缺乏归属感与公司脱节,造成热情耗尽消极怠工或人员离职,寻找更好的出路;
  • 无法适应在项目中来自客户方与公司内部所带来的压力,自认能力不足,失去挑战精神,不愿意再去承担重任;
  • 拖期过长,需要将项目人员进行召回,替换能力相符的人员进行补充;
  • 人员岗位所致,需要同时兼顾多个项目,项目稳定后撤场换人;
  • 项目成员之间能力、短板差异较大,无法胜任当前工作,内部进行人员替换;
  • 家庭原因、自身生病或不可抗力因素导致调岗或离职;

4.3 超出预期成本

  • 进度不顺利,实施方租房、人天成本(通常在项目估算金额前会对相关费用打出余量)超出预期,导致项目利润减少或变负;
  • 项目周期内建设成果无法正式运行或见效,客户方产生不满情绪,消极配合;

三、项目风险规避

对于项目风险从根本上讲,是不可能完全消除的,总会有一些未知的、不确定性的风险等待项目成员;

因此风险总是存在的,面对风险能做到的就是尽最大限度的去规避,规避不是指知道存在的风险之后,刻意避开不去触碰即可,而是需要掌握应对的方法,解决已知风险,并通过一系列的措施将未知风险控制在一定范围内。

通过上述对项目风险的剖析,总结归类从以下几个角度针对性进行集成项目风险规避。

1. 建立项目体系

注重项目体系的建立,保证项目从初期到各个里程碑节点,后期验收运维等一系列过程进行监督、把控、保障项目的平稳交付,以便于更好的攻克项目难题,应对风险,保障进度。

  • 建议将公司产品、团队、过程进行一体化管理,注重项目案例的沉淀及相关交付物的归档,建立一套相同场景可复用的标准体系;
  • 建立项目PPMO管理委员会,设立关键人员,从项目初期售前开始介入,包括需求调研、项目实施进行专项支撑,直到项目验收运维;
  • 对项目的每一个环节都严格制定标准,如:集成标准、接口标准、计划标准、文档标准、验收标准、项目管理标准、制度标准等;
  • 设立项目双周滚动周报、人员日报机制,严格把控项目人员工作计划及内容,及时发展项目中出现的问题,加以控制解决;
  • 加强客户的项目参与度,从项目开始,每周定时为用户发送项目周报,并定期召开项目会议,保持良好的沟通,信息一致,及时沟通存在问题;
  • 对于项目中需要攻克的难点,由公司指派专人进行专项支撑,项目人员负责进度推进,专项人员进行解决并告知成果;
  • 建立项目考核制度,明确项目中的奖惩规则,规则是可追溯可考核的;

2. 需求分析到位

很多项目拖期或需求蔓延都来源于前期对于客户的需求把控不到位,没有明确、及时引导、封闭需求,所以在项目前期的需求调研及把控方面需要掌握一定的方式方法。

  • 进行深度调研,多方面与客户进行深入沟通,调研后及时撰写需求调研文档并进行内部详细评审,对于不明确内容进行校正,并与客户确认;
  • 对于不明确需求,反复与客户进行确认,直至双方没有异议,并认可,出具最终需求说明文档;
  • 有意识的控制及引导客户的需求范围,以专业角度给出建议,删除没必要的需求,保留有必要的需求;
  • 与客户一同进行外部需求评审会议,进行需求确认,并在会议中进行需求固化、封闭,双方认可后,将最终需求文件与客户签字确认;
  • 需求确认会议上表明什么是需求蔓延及哪些范围算在需求蔓延内,做好边界管控,并告知客户需求蔓延对项目造成的影响及需走的流程等事宜;
  • 需求明确后根据文档进行功能设计,详细且周全,从技术实现、应用功能、注意事项、攻克难点等多方面进行考虑;
  • 从客户角度理解需求及实现方式,模拟回归用户的真实用途,制定合理的准确的功能设计,之后进行内部评审,通过后即可实施;
  • 对于后期需求蔓延,有必要且可以容易完成的需求,可以顺手解决积累良好的印象,对于没必要的需求可以引导其放在二期进行;

3. 产品方案完备

很多公司的产品及方案都是在项目中不断打磨出来的,一个好的项目既能为公司带来利益,也会对公司的产品及方案有所帮助,但企业不能仅依靠在项目中去完善升级产品或方案,平时也要注重积累,不断的打磨升级。

  • 找准企业的基因及核心竞争力,对于核心产品的质量进行严格把控及打磨,制定详细的升级计划;
  • 新产品设计需要进行全方面考虑,包括产品的应用领域、客户需求、产品特性、核心特点、性能安全、灵活性、兼容性等一系列前提;
  • 具备升级意识,随着技术发展与项目中客户的需求进行完善产品,好的部分进行源码复用,成为产品的标准功能,升级产品能力;
  • 注重打造种类齐全且彼此之间可以相互支撑的产品套件,如不具备这种能力,至少保证产品线也能够组成至少一个完整的解决方案;
  • 寻找共同打单合作伙伴需要多方面选型,注重产品的把控性、整体性及与自身方案、理念的融合性;

4. 人才培养储备

人员的能力及稳定性是影响项目成败关键的问题之一,实施方需要在日常工作中对人员的项目管理能力、技术能力等各方面进行培训,而不是在项目中去现锻炼,项目中试错、学习、成长固然没有错,但应该有所准备和积累后再去执行。

  • 建立人员培训体系,快速培养项目人员的产品知识与基本技能,将日常工作当做项目形式,了解项目工作同时培养项目感觉;
  • 培养项目人员学习公司全线产品使用及原理,具备产品的快速扩展能力,同时了解对应的解决方案,便于在项目中对产品的组合与拆分,将客户的需求快速对应;
  • 培养项目人员自主提升意识,主动对项目涉及的行业知识、业务、相关信息化系统进行学习,加深知识储备与业务流程的理解;
  • 培养项目人员主动汇报与协调意识,积极主动汇报项目中存在的问题,及时与客户、伙伴、公司内部进行沟通交互,协调解决问题,同时加强能力、经验的积累提升;
  • 培养项目人员时刻具备项目风险意识,以项目计划为基础,将预知风险进行罗列(技术、产品、人员等),从而进行评估,并预留缓冲时间,对项目进行严格把控,每一个关键节点及实施情况烂熟于心,保证可追溯,及时发现风险;
  • 进行项目人员备份,尽可能避免将项目中所有重头工作全部交付于项目经理一人手中,项目实行正副经理制度,保持两者工作透明,便于一人离职平滑替换;平时加强同类型人才的培养与储备,建立人才梯队;
  • 对项目人员进行安全防范培训,明确项目出差过程中常见问题及解决方式;

集成项目的风险管理一直是各个实施方不断在研究和攻克的问题,项目中的风险严重的可以导致集成项目的拖期、超出预算、甚至做成烂尾;

而对于大型的集成项目来说,风险难以避免只能面对,在风险面前能做的就是不断完善现有的项目交付体系、人员培训管理体系、升级优化产品及方案,提高综合实力,根据经验加强项目中风险管控制度与预测能力,未雨绸缪在风险来临之际从容应对。

本文由@数通畅联 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash, 基于CC0协议

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2024年7月19日 下午1:58
下一篇 2024年7月19日 下午2:10

相关推荐