项目说明及应对措施.docx
- 文档编号:13064099
- 上传时间:2023-06-10
- 格式:DOCX
- 页数:19
- 大小:23.45KB
项目说明及应对措施.docx
《项目说明及应对措施.docx》由会员分享,可在线阅读,更多相关《项目说明及应对措施.docx(19页珍藏版)》请在冰点文库上搜索。
项目说明及应对措施
A案例项目介绍
XXXXX是一家私人企业,总部位于大连,CMT集团有180多辆集装箱卡车并在大连、沈阳、长春等地都设有集装箱场站、仓储中心,原有操作模式都是分散的单据,基本都依靠手工EXCEL的方式来操作业务,造成单据重复、丢失的情况时常发生,并且无法及时了解各场站的集装箱堆存情况,各仓储的存储情况,需要建立一个涵盖不同地区的多点应用,并可进行统一调度和管理;且要求系统根据集装箱运输特点,能够满足干线、配送、返箱、集港等业务的管理要求,以期促进公司主体业务的发展,达到公司品质、成本、交付的卓越服务理念
项目从2013年10月8日调研开始,到2014年12月31日,前期调研有些波折,设计、开发过程中间没有甲方的过多干预,进行的相对比较顺利,实施过程比较艰难。
目前业务、商务部分功能已经上线使用。
运输部分还未上线使用。
在项目实施过程中碰到如下问题,在实际操作过程中效果不理想。
A案例项目中遇到问题的场景:
一、及客户间存在的问题
1、需求范围确认
现象:
在合同签署时,合同中对系统的范围界定一般都比较粗犷,在调研以及后续实施过程中甲方会提出乙方认为在合同中不包含的需求。
目标:
形成一份双方都比较认可的《业务需求说明书》。
处理方式:
在项目中实施过程中尽量使需求控制在合同范围之内,一些功能简单,便于实现的甲方其它要求,还是尽量给予实现,一些大的功能需求都是直接回绝甲方。
结论:
效果不理想,起码甲方董事长对我们的系统不满意。
第一组:
1
在合同签署前业务顾问参及,便于后续进行SOW制定,界定范围。
2
合同上明确详细的功能清单或者工作清单。
3
制定协商机制,如:
可以说明根据后续文档界定项目范围及边界。
1
明确核心干系人。
2
明确范围后,评估风险,将超出范围内容同客户说明,从成本及进度各方面说明,是否可以将超出部分放到下一期;或者寻求销售及高层协助。
第二组:
1
合同签订前对甲方企业诚信度做评估;
2
项目实施人员参及合同签订,明确合同开发范围;
3
合同签订前应进行详细的调研,明确需求;
4
事先分析项目干系人;
5
合同规定分期验收付款,或分期签订合同;
1
应立即组织甲乙双方会议确定甲方相关责任人;
2
补充细化SOW,双方责任人签字确认;
3
建立对等沟通的组织架构;
4
编写详细的需求规格说明书,甲乙双方责任人确认签字;
5
必要时可暂停、终止部分合同内容;
1
里程碑节点不完成,项目部继续往下执行;
2
细化需求,分解WBS;
第三组:
1
签订合同前,对需求进行评估;
2
编写工作说明书或可行性报告;
3
明确干系人;
1
召开启动会,明确组织架构;
2
明确需求变更流程;
3
通过公司高层沟通;
1
明确需求范围;
2
增加风险意识;
第四组:
1
确定双方项目组织架构,落实到人;
2
签合同前,需求范围界定有技术人员参及;
3
范围界定以SOW为准,将SOW作为合同附件;
4
事前要调查客户信誉度;
1
项目经理力不从心时,请销售、领导参及;
2
以会议的形式确认需求变更内容,形成文档,群发干系人;
3
把不在项目范围的内容,具体表述在文档中;
4
项目经理经评估可以给出项目中止建议;
1
明确需求范围;
2
增加风险意识;
2、流程差异
现象:
在需求调研过程中,甲方的董事长要求流程标准化,岗位职责清晰,由于是私人企业,业务员每个人都身兼数职,所以业务员对系统的要求就是流程简单,不需要过多的环节控制,最好是直接将结果填写进系统即可。
这样就出现较大的差异。
目标:
开发出一套甲方相对认可的业务系统。
处理方式:
在项目需求调研时按照甲方董事长的主要想法去做的需求设计,在开发过程中有些功能模块尽量做到了批量操作,节省一部分环节。
结果:
无法达到业务员想要的效果,如果做成业务员想要的效果在甲方董事长那里就无法通过,系统也就无法进行实施,这也是造成系统无法全部上线的原因之一。
第一组:
1
在项目前期,明确具体业务及流程的确认人。
2
提前约定阶段性汇报机制,项目过程中,将工作情况汇报给相关方,用于暴露目前项目的近况及问题。
1
甲方内部出现分歧时,主动推动甲方组织会议,尽快解除分歧实现内部流程统一,避免进度延误。
2
引导客户,并根据实际情况提供合理的建议及流程方案,供甲方确认,如请乙方专业顾问进行流程的建议。
3
强调项目启动期间的约定,只有需求或者流程统一确认签字后才能进入下一阶段,提醒客户。
4
根据项目的实际情况,同客户交流,是否可以先确认无争议的需求及流程。
1
通过方案及技术手段,优化功能,解决部分冲突
第二组:
1
编写流程解决方案;
2
领域专家介入系统实现;
1
领域专家及对方董事长及业务人员沟通;
2
制定详细的业务操作流程;
3
董事长确认操作流程;
4
开会讨论业务流程,双方确定业务流程,上下一致,签字确认;
5
必要时寻求公司PMO及领域专家支持。
1
演示系统,征求董事长及业务操作人员意见,确定并签署流程。
第三组:
1
预先做好流程方案,需对方确认。
1
召集客户方领导和业务人员开会。
2
开会方式,我方提出问题背景,对方业务人员先发言,对方领导发言,给出流程统一方案。
我方再提出优化方案。
3
会议纪要发对方确认。
第四组:
1
及时暴露出现的问题,不能等,不能不理。
2
在甲方内部达成一致,确认完业务流程,再开发。
1
由甲方组织会议,说出各自想法。
2
甲方无法决策时,乙方可以派出领域专家给出建设性意见。
3
实施阶段发生差异,乙方项目经理对进度、成本提出建议。
3、阶段性签字的延误对工期的影响
现象:
业务需求说明书在需求调研完毕后2013年10月31日提供给甲方进行签字确认,甲方最终签字的日期为2014年1月16日。
项目因为业务需求未签字,设计、开发工作都延期,对项目整理工期影响较大,项目本身工期就比较紧。
目标:
促成客户及时进行签字确认,保证项目工期。
处理方式:
在将业务需求说明书提交给甲方后,甲方没有进行签字,项目组撤回到公司,为了不影响整体进度,在公司进行开发,后经公司领导到甲方进行沟通,甲方承诺给签字后项目组又到甲方驻场开发。
结果:
签字确认严重滞后,工期延误。
第一组:
1
制定里程碑计划,用于表名各重大事项的时间节点。
2
明确各业务签字确认人。
3
提前明确进入下一阶段的约束,并写明无法签字确认的后果。
1
首先要了解清楚甲方不签字的真实原因。
2
分析不签字的原因,找出突破点。
3
进行应对措施,正式通知签字人,根据之前约定,明确最晚签字时间及延期签字的后果及相关责任。
4
邮件、电话、短信等方式不断提醒。
1
说明情况,寻求领导的帮助。
第二组:
1
合同中约定双方责任人及其职责;
2
变更须通知双方责任人及相关干系人;
3
合同中约定变更流程。
应对
1
重新评估不签字确认对项目计划的影响;
2
重新评估更换后的项目经理的能力,不行建议更换;
3
后续项目经理确认前任工作,确保项目的延续性;
4
组织工作交接餐,欢迎新人,欢送旧任;
1
第三组:
1
合同中约定签字时间,里程碑点;
2
合同中约定签字延期造成的后果对方负责;
3
确定对应的签字人员。
应对
1
及时反映在周报,明确问题清单;
2
高层协调,保留证据。
第四组:
1
提前约定多少个工作日内不答复默认为确认通过;
2
经常邮件提醒对方;
应对
1
明确告知客户延期签字对项目的影响,并同时发送促签单;
2
缩减项目组成员,降低成本;
3
保留由于客户原因造成工期延误的证据,备用;
4
提示公司做风险评估;
5
寻求支持:
发生急议时,及对方协商并向上层领导汇报,若协商无果,请销售、公司高层、法律逐级解决;
4、制定的实施计划不能如期推进
现象:
跟甲方一起制定的实施计划,最终没有按计划推进,也就对项目整体计划产生影响。
在推进实施过程中,甲方董事长给配合实施的人员安排其他工作任务,调离实施配合地点。
目标:
能促使甲方配合我们同时推进项目。
处理方式:
,项目组通过沟通、邮件的方式催促甲方进行实施推进。
结果:
没有明显效果,项目实施推进延期。
5、甲方项目负责人频繁更换对项目的影响
现象:
项目从调研开始到实施过程中,甲方的项目负责人变更了5人,4人离职,每个人对项目整体都不了解,对项目计划按期完成也会产生较大影响。
目标:
协调处理对项目的影响降的最低。
处理方式:
在项目过程中,我们针对重要的问题、事件都是跟姜总进行确认,由于姜总本身是负责财务的,并不是全部精力都投入的系统中来,一些小的问题和其他负责人进行确认。
结果:
这种处理方式在甲方财务经理辞职前后的时间里,姜总就没有过多的时间来推进系统,其他负责项目的IT部人员想推推不动。
也影响到系统上线实施。
第一组:
1
合同中约定人员变更流程,如:
提前一周通知,两周时间交接工作。
2
声明人员变更对项目的影响(进度、质量、成本)。
1
通知甲乙双方项目干系人。
2
要求甲方指定项目全程的协调人。
3
如果发生变更,进行成本、进度、质量、风险的评估,双方确认。
4
制定A,B角方法,用于人员备份,应对人员突发变更情况。
第二组:
1
合同中约定双方责任人及其职责;
2
变更须通知双方责任人及相关干系人;
3
合同中约定变更流程;
应对
1
重新评估更换后的项目经理的能力,不行建议更换
2
后续项目经理确认前任工作,确保项目的延续性
3
组织工作交接餐,欢迎新人,欢送旧任
1
第三组:
1
制定人员变动流程;
2
明确备份人员;
3
合同中明确责任;
应对
1
建议客户方做好交接工作;
2
主动及交接人员沟通做好交接工作;
第四组:
1
明确约定双方项目人员,不能频繁变更;
2
制订人员变更流程,变更前双方要通过协商,更换的人员资质相当;
3
甲方项目经理时间要有保障;
应对
1
明确告知甲方变更人员对项目的影响,有量化说明;
2
人员变更时要有邮件通知;
3
甲方人员能力或时间不能满足要求时及时提出
6、需求变更
现象:
甲方在某些需求发生变更的情况下也不会提供需求变更单,比较担心的是如果提供需求变更单了,我司会依据此单据向甲方收费。
目标:
正常的需求变更需要甲方提供需求变更单,并在需求变更单上签字。
处理方式:
当面沟通让客户提供书面变更,或者提供邮件修改确认。
结果:
效果不好,客户一般都愿意当面描述问题,当让他们在提供书面或者发邮件的时候会极大的不愿意,所以这方面的资料就比较少。
二、项目团队内部问题
1、出差问题
现象:
由于家庭因素,项目组成员不愿意长期出差。
目标:
正常出差,保证项目工期。
处理方式:
及项目组成员沟通,讲述IT项目性质及项目的重要性,尽量做到如果家里有事情需要处理时能够让项目组成员能够回家处理事情。
结果:
项目组成员离职。
2、积极性问题
现象:
在工作中,由于各种原因,项目组成员工作积极性不高。
目标:
调动项目组成员积极性,提高工作效率。
处理方式:
及项目组成员沟通,了解其造成工作积极性不高的原因,积极协调解决。
结果:
不是很理想。
3、意见不统一
现象:
在项目中某些功能模块的设计、开发中,项目组中会出现多种不同的意见,这种不同意见的产生也会造成某些员工的工作积极性不高。
例如:
项目组一次讨论场内装箱、工厂装箱操作完成后作业单数据的处理方式,需要将其中的一个作业单做成重箱,一个做逻辑删除。
项目组成员中设计人员及开发组核心成员有2种处理意见,一种是从货物的角度考虑,一种是从集装箱的角度考虑,2种处理方式最后展现结果一样,处理方式稍有差别,当时在讨论过程中大家情绪都比较激动,都很难说服对方。
目标:
统一意见,满足项目要求。
处理方式:
项目经理把项目组所有成员聚集起来一起沟通讨论此问题的解决方案,对于出现的2种意见,双方都把自己处理方式的优点讲解出来,由于最后系统展现结果一样,没有本质上的差别,都很难说服对方,由于项目工期紧张的原因,最后项目经理拍了使用其中一种方式。
结果:
虽然大家都按照最终的结论都开发了,但是没被接纳意见的人员还是有较大情绪的。
第一组:
1
前期同客户沟通,尽量本地化处理,避免驻场开发。
2
增加项目乘员沟通,提前了解员工及员工意愿情况。
1
建立轮换机制,避免相关人员长期在外。
2
建立灵活的出差补助机制。
对于长期出差的同事进行物质和人文的奖励。
3
将项目进行模块化,并外包,或者客户方找人进行本地化开发。
4
针对项目内部出现意见不统一,开发进行讨论,集中决策,如:
项目经理排版或者是投票制。
5
将意见不统一的点进行拆分,明确无分歧的部分,一步一步去解决分歧。
第二组:
1
加强企业文化教育,增加员工归属感;
2
建立异地虚拟化开发环境,充分利用视频电话等交流设备;
3
事先评估项目组成员出差难度;
应对
1
定期组织项目组人文建设活动,人文关怀;
2
建议公司提高出差补助费;
3
营造出差地良好的生活工作环境,关心员工生活起居,必要时可让其家属到场探望;
4
针对意见不一致,项目组可以建立处理意见分歧的机制,先讨论,后拍板;
第三组:
1
在组建团队的时候,挑选愿意出差的项目组成员;
应对
1
分析不愿出差的原因,找到解决办法;
2
更换项目组成员;
3
细化讨论方案,找出优缺点,进行比较,选定方案;
4
增加出差补贴;
第四组:
1
项目组建时就考虑人员结构;
公司人力资源要考虑人员梯队建设,不同年龄段要合理搭配。
项目组组建时,要根据出差情况,将可以出差或不能长期出差人员搭配。
2
长期出差补贴标准提高;
对于项目需要长期出差情况,可以提高补贴标准,区别于一般短期出差补贴。
3
人员要有轮换机制;
建立长期出差轮换机制,不能让一个人承担。
应对
1
高层多些关怀(人文+物资):
项目高层要定期,分阶段进行公司文化远景及个人成长关怀、团队活动。
同时通过纪念性礼物等实物进行激励;
2
及时奖励(物资加假期):
为提高项目组成员积极性,可以在项目不同阶段小额奖励。
例如代码评审BUG数量少的可以有一定奖励。
对于出差较多的,可以轮休调整为假期;
3
一般问题项目经理决策,大问题提交公司职能部门决策。
设计项目内部业务或技术项分歧问题,项目经理在双方不能解决时,果断决策。
涉及技术框架等问题,上报公司技术架构组决策;
三、项目组及其他干系方存在的问题
1、借调人员
现象:
项目中需要其他项目组成员协助解决问题。
目标:
协调成功,问题解决。
处理方式:
及该成员项目经理沟通,确认后再及该成员进行沟通。
如果该成员满负荷工作则及部门领导进行沟通,协调其他人协助解决问题。
结果:
基本都能解决。
四、及上级沟通存在的问题
1、角色对等
现象:
在参及项目的角色权利不对等,该项目客户董事长及上层管理人员很关注该项目,有时候会参及需求和设计环节的讨论和确认。
目标:
上级领导在某些会议上参及、支持。
处理方式:
甲方提前定的开会计划,及时通知上级领导,有些临时的回忆只能项目经理参加。
结果:
对于甲方董事长及上层管理人参会,我司上级领导没参及,我方作为项目经理参及会议在参及讨论或决策时明显很弱势。
第一组:
1
启动会中对项目经理进行授权,明确项目经理的权利,并通知甲乙双方。
2
提前约定需要高层参及决策的事项。
1
对于需要乙方高层参及的决策及会议时,可以采用电话、视频会议的的方式进行。
2
根据项目情况,项目经理进行甲乙双方高层的沟通,并安排甲乙双发进行定期沟通。
3
PMO根据里程碑进行成本和进度管控,进行风险提醒。
第二组:
应对
1
项目启动会应明确项目经理的职责和权限,授权项目经理;
2
经常开系统业务沟通会,不开大会,高层无需参加;
3
定期联络双方高层,沟通项目进展情况;
4
加头衔;
5
跟对方领导开会,要据理力争,不卑不亢。
第三组:
应对
1
授权项目经理有决策权;
2
高层不能及时到现场,可采用多种沟通方式,如电话会议等;
3
每一个里程碑点,做好风险点评估,提交公司,做好和公司高层的提前沟通工作;
第四组:
1
约定高层出现的场合、角色、身份;
2
提前了解客户方领导风格,选派匹配人员;
3
启动会上授权;
应对
1
及甲方项目经理沟通,不同场合出现合适身份人员;
2
会议前,提前确定日程、内容等;
3
及时向公司汇报;
2、对于项目中间出现的风险如何选择是继续、终止。
现象:
项目在进行过程中出现多次停顿的情况,对于项目进行过程中出现的风险如何评估项目是继续还是终止?
目标:
保证项目按期实施。
处理方式:
经过沟通后项目还是继续推进下去。
结果:
项目没有按期实施。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 说明 应对 措施