IT项目实施与管理方案投标书DOC45页.docx
- 文档编号:10111739
- 上传时间:2023-02-08
- 格式:DOCX
- 页数:50
- 大小:74.22KB
IT项目实施与管理方案投标书DOC45页.docx
《IT项目实施与管理方案投标书DOC45页.docx》由会员分享,可在线阅读,更多相关《IT项目实施与管理方案投标书DOC45页.docx(50页珍藏版)》请在冰豆网上搜索。
IT项目实施与管理方案投标书DOC45页
IT项目实施与管理方案-投标书(DOC45页)
1.1项目实施与治理
1.1.1项目实施方法论
针对南京银行企业服务总线系统项目,高伟达公司基于对客户需求、业务目标、业务能力和IT环境的明白得,结合多年的软件开发和系统实施体会,将项目的实施周期划分为六个活动时期,保证在项目生命周期内,应用合理的项目治理和操纵技术。
通过用心于使客户投资回报最大化,和使客户的投资风险最小化的关键战略和战术领域,加快项目实施速度,使得项目成功地完成。
这些时期的特性是可循环往复性,使客户能够尽快地获得新的应用系统所带来的好处。
1.1.1.1项目定义时期
在那个时期,所有与分期实施相关的项目活动都被明确定义,项目的"项目利益相关者"被指定,项目经理和客户项目经理的角色和职责被传达给所有的"项目利益相关者"。
治理项目所需的项目操纵结构被定义,所有需要的项目规划文件被创建,客户的业务问题和被用来衡量项目成功的衡量标准被确认。
制定解决方案范畴,在一个高级别上定义哪些模块将被实施,估算预期需要的客户化程度,以及勾画出在产品之外需要开发的内容和要提交的技术成果。
解决方案范畴文档包括解决方案范畴概述,功能范畴,流程范畴,客户化问题,其他风险,外部依靠条件以及假设。
那个工作为以后项目决策,统一或达成"项目利益相关者"之间就有关项目参数的共识,提供书面的文档。
它阐述以SOW为基础的业务需求,同时把它转化成产品模块实施信息。
简而言之,那个时期组建项目团队,保证客户实施项目的成功。
公司人员与客户人员一道,组建项目团队,设定项目方法和范畴,并建立项目治理操纵。
要紧交付的成果有,解决方案范畴和项目治理操纵。
制定了项目质量检查打算。
1.1.1.2需求分析时期
在需求调研时期,在项目治理小组的指导下,由公司和客户组成的统一的项目团队将识别同时书面记录在开始设计客户解决方案之前所必须弄清晰的,需处理的问题。
项目团队书写、提炼满足客户业务目标所需的功能和技术要求。
要紧交付的技术成果为业务需求和差距分析。
专家服务顾问将进行一个配置检查,以保证系统有精确的规格,便于购买硬件和架构部署。
在有技术客户经理参与的情形下,通过完成初始的评估,来建立部署的基准,及通过给战略,管制,用户采纳,流程和技术各方面打分的评估来建立业务目标。
1.1.1.3项目设计时期
在设计时期,要紧的目标是设计一个能够最正确地满足客户明确的业务需求的解决方案,同时为培训和系统测试做预备。
在设计(Design)时期,项目团队利用应用系统屏幕流程和设计布局来映射在发觉时期确定的需求,设计解决方案的原型。
要紧交付的技术成果是解决方案设计文档和测试策略。
那个策略定义测试打算和测试要求,以保证一个系统部署的成功。
要紧的目的是提供一个高级的测试策略,以便使用自动化的测试工具和/或手工过程来实现功能测试,系统整合测试(SIT),用户验收测试(UAT)和性能测试。
专家服务顾问要执行设计检查,来评估由客户或集成商提供的书面设计文档,同时提供详细的建议清单。
设计标准包括,但不限于,应用系统性能,对升级的阻碍,应用系统爱护,与数据模型相关的问题和常规的最正确做法。
1.1.1.4项目开发时期
在开发时期,项目团队将开发应用系统,提供任何需要的扩展功能和外部接口,为客户部门部署和连续支持解决方案做预备。
项目团队配置应用系统、所有需要的扩展功能和外部接口。
要紧交付的技术成果有功能测试和系统测试。
这些流程整合和测试活动更好地保证介入的系统功能与客户组织的业务需求和谐一致。
专家服务顾问应该进行一个配置检查,来评估所有通过客户化改造的实施文档。
在那个检查过程中,所有如此的文件都将被评估,以使应用系统性能,应用系统升级,系统爱护工作量和常规最正确实践最优。
1.1.1.5项目验证时期
在验证时期,将完成新系统全部功能的测试。
那个时期分两个部分。
第一部分,项目团队进行一个对有生产数据的应用系统的全部功能进行测试。
在那个检测完成后,关键用户然后进行一个代表性的验收测试,以保证系统正确地处理用户的需求。
一旦全面的功能测试终止,将进行一个使用系统工具的,严格的性能测试。
这一时期要紧交付的技术成果为用户验收测试和性能测试结果,包括性能,容量和寿命测试。
适时的性能调整审计,可保证整个企业架构环境的性能最正确。
在那个检查中,专家服务将主动性地识别任何性能问题,如此将减少在运行时显现问题的风险,增加系统生产切换的信心。
在有技术客户经理参与的情形下,可执行一个实施预备就绪检查,以确认系统是否能够部署了。
那个实施预备就绪检查是用来评估实施风险,技术上是否预备停当以及部署策略。
现在,应该召开治理人员定向和谐研讨会,将责任转移给一线的职员,这些职员将开始支持业务流程和技术的推出。
在治理人员定向和谐研讨会上,项目团队与客户的治理团队一起工作,以获得坚持资助人的内部负责,并把正确的信号传达给组织的其他成员。
1.1.1.6部署上线时期
部署上线时期内的第一个活动是实施一个投产导航。
那个导航是被用来测试全面的生产部署,同时在客户业务环境中的一部分部门中进行的,例如一个地区或一个区域。
生产导航在机构的业务环境中部分部门里,为用户提供所有系统的特点。
来自于生产导航的反馈信息指导整个的部署。
同样在那个过程中,专家服务顾问应该进行生产预备就绪检查,通过主动地识别任何可能造成部署中断和使实施的系统解决方案的技术优点打折扣的所有问题,来协助系统的顺利推出。
现在,要召开流程实施研讨会,部署流程最优实践,来优化人,流程和技术的配合。
目的是在客户所有的一线机构中,使用变革和销售流程的最正确实践,使最初的赞助人和行政领导团队完全中意。
1.1.2项目治理方案
1.1.2.1项目治理概述
项目治理包括在项目生命周期中和谐所有项目治理知识领域所涉及的过程。
它确保项目所有的组成要素在正确的时刻结合在一起,以成功的完成项目。
进行项目整体治理时,必定涉及项目的范畴、质量、时刻和成本治理以及人力资源、沟通、风险治理等各个环节,项目治理一个复杂的工程,在此要紧针对南京银行企业服务总线项目的项目进度治理、变更治理、沟通治理、质量治理、风险治理等相关策略进行描述。
1.1.2.2项目进度治理
通过项目进度的治理最终明确项目开发时期的进度操纵活动和关键流程。
Ø项目经理:
◆依照软件开发打算编制详细的时期开发打算以及每项任务的边界时刻,并召集过程操纵人员、专题小组负责人审核该打算;
◆审核各专题小组拟订的每项任务的日程安排;
◆检查和操纵项目进度;
◆制定进度变更打算;
Ø过程操纵人员:
◆协助审核详细的时期开发打算和任务边界时刻;
◆监督项目进展;
Ø专题小组负责人:
◆协助审核详细的时期开发打算和任务边界时刻;
◆在听取小组成员意见的基础上,拟订每一项任务的日程安排;
◆负责检查和操纵任务的进度,并填写进度操纵表;
◆负责制订任务变更打算。
1.1.2.2.1.进度安排流程
Ø项目经理依照项目打算,明确该时期的边界时刻;
Ø依照项目打算中的任务PERT网络图,找出该时期的关键任务并进一步分解、细化,在此基础上绘制更具体的时期任务PERT网络图;
Ø拟订详细的时期打算;
Ø确定每一关键任务的边界时刻;
Ø召集各专题小组负责人审核拟订的打算,并修改;
Ø专题小组负责人确定任务的日程安排;关于大型的或时刻要求严格的项目,进度安排应以天为单位;
Ø征求小组成员的意见;
Ø交由项目经理和过程治理人员审核。
1.1.2.2.2.进度操纵流程
Ø项目经理和过程治理人员按照时期PERT图,标志时期中被跟踪的关键任务和里程碑,并将之告知专题小组负责人;
Ø专题小组负责人按照任务的日程安排,确定任务完成期间的关键时刻点,并将之告知专题小组成员;
Ø专题小组负责人经常与成员沟通,了解任务进展;并定期检查,填写任务进度表和下期打算表,及时发觉问题;
Ø项目经理定期组织专题小组负责人,召开项目状态会议,了解任务进展,及时发觉问题;项目过程治理人员参加会议或了解会议的记录;
Ø专题小组负责人在执行中发觉延迟,分析缘故:
◆人员紧张:
组内调配不了的,找项目经明白得决;
◆事先预估不足:
调整任务日程安排;假设解决不了,告知项目经理,会同过程治理人员,调整详细的时期打算;假如时期内消化不了的问题,那么项目经理按照«配置治理的程序»,变更软件开发打算。
1.1.2.3项目变更治理
针对项目变更治理组织变更操纵小组,由项目组经理、项目治理部人员、项目总监、客户、客户部成员组成,考虑并授权项目的重大修改〔修改工作量超过一周的〕。
而项目经理负责项目的一样修改决策〔修改工作量在一天以上,一周以内〕。
变更治理活动包括修改要求、评估、通过、执行和跟踪。
变更治理要点如下:
Ø变更批准权限:
Ø变更操纵组负责讨论和决策项目的重大修改;
Ø项目经理讨论和决策一样性修改;并报项目治理部备案;
Ø修改审批程序:
Ø依照不同地点的客户有不同的审批程序。
1.1.2.3.1.变更状态登记
变更状态登记活动记录和报告各种配置项的状态,记录在项目生命周期中的任何治理信息和历史信息。
包括:
所有变更要求表、所有变更报告单、所有变更记录。
由项目治理人员存取状态登记。
变更状态登记的目的是为了操纵软件需求发生变更时的处理过程,使之按照制定的规程进行,以保证软件需求的一致性。
1.1.2.3.2.变更治理流程
Ø客户方或高伟达提出变更要求,填写变更申请表;
Ø将变更申请表交本项目组的项目经理;
Ø双方项目经理〔或项目经理授权人,必须以书面形式确认〕共同批阅,评估该需求变更的技术有效性和对本项目的阻碍;
Ø假如批阅批准该要求,那么双方项目经理〔或项目经理授权人,必须以书面形式确认〕签字确认,变更申请表将被贵行文档治理员登记后,转发给高伟达。
假如未获批准,其缘故将反馈给该需求变更发起人;
Ø高伟达在收到经批阅批准的需求变更申请后的三个工作日内,发给贵行一份书面确认书,确认其收到,并给出分析与执行变更所需时刻和工作量的估算;
Ø依照要求的变更程度和复杂度,高伟达进一步进行成本评估,假设不需成本,那么直截了当执行变更工作;假设需要增加成本,那么以书面形式通知贵行文档治理员,贵行治理员登记后,按照项目治理方法中的项目变更治理流程处理。
1.1.2.4项目沟通治理
南京银行ESB项目是一个技术与业务互动的项目,项目的成功专门大程度上依靠于业务人员的参与程度及技术人员对业务需求的透彻分析,这就要求技术与业务人员保证充分的交流,制定并遵守项目内部的沟通治理打算。
1.1.2.4.1.项目沟通形式
依照本项目的组织形式及特点,我们建议采取如下多种方式的沟通形式:
序号
沟通形式
负责人
沟通对象
内容
频度
输出文档
1
领导小组与项目组的联系会议
领导小组组长
项目治理组、领导小组
项目实施状态汇报,问题报告、建议措施并要求得到回复,项目组进行问题回复和传达领导组指示
每两周1次
会议纪要
2
总体组会议
项目总监、项目经理
总体组成员
总体组内部工作分工和谐、布置,分析各专业组工作情形和提出的问题决策,为与项目组的联系会议作预备
每周1次
会议纪要
3
专业组组长会议
项目总监、项目经理
各专业组组长、总体组
专业组进行进展汇报、问题汇报及建议措施;总体组部署工作安排,决策,和谐,分析进度、问题等
每周1次
会议纪要*
4
专业组内部会议
专业组组长
专业组组员
专业组内部交流会议,任务布置、信息交流、问题讨论等
每2~3天1次
/
5
动员大会
总体组、领导小组
全体人员
在全体项目成员范畴内宣布项目总体和时期目标,回忆前时期成果,鼓舞士气
项目各时期的开始
/
6
简报
项目助理
全体人员
反映项目动态,包括进展情形、问题及解决方案,本周工作成果、下周工作重点等
每周1次
简报*
7
小组工作周报
专业组组长
总体组
反映各个专业组每周实际工作情形及结果,包括依照打算的执行情形和进度偏差。
每周1次
小组工作周报*
8
个人工作周报
专业组组员
专业组组长
反映个人每周实际工作情形及结果,包括依照打算的执行情形和进度偏差。
每周1次
个人工作周报
9
电子邮件
全体人员
当事人
需讨论问题的非正式书面交流
按实际需求
电子邮件
10
日常交流
全体人员
当事人
需讨论问题的非正式口头交流
按实际需求
/
备注:
1、〝负责人〞为各类沟通形式的组织者;
2、〝沟通对象〞为需参与各类沟通的项目干系人;
3、〝输出文档〞为各类沟通所产生的书面文件,由各类沟通的〝负责人〞或其指定人员制作并派发〝沟通对象〞;
4、〝输出文档〞一栏中有〝*〞记号的文件需由项目办公室作为项目文件进行存档。
1.1.2.4.2.会议治理制度
项目开始进行以后,要有效地操纵项目,需要在各个关键时刻召开关键会议。
关键会议的要紧内容是总结上一时期的工作,分析问题、提出建议,并介绍下一时期的要紧任务和目标,使各有关人员都能做到心中有数,明确努力的方向。
关键会议也是和谐各不同小组之间的人员以及工作任务的重要手段。
除关键会议外,在项目进行的全过程中,应定期召开例会,会上要紧介绍项目进展情形,检查进度、是否存在问题等,会议时须做详细的会议记录并在会后报送所有项目相关人员。
要紧的项目会议流程规定如下:
Ø会前预备:
◆做好预备工作,如明确会议目的和会议议程等;
◆把会议中要求讨论的材料事先下发给开会成员;
◆提早两天通知各位与会成员;
◆预备会议环境、会议用设备等;
Ø会议之中:
◆会议成员准时到会;
◆按会议议程逐项进行;
◆严格操纵会议时刻;
Ø会后跟踪:
◆会议决议落实和检查。
1.1.2.5项目质量治理
为保证项目顺利实施及系统质量,必须在项目治理过程和项目实施过程上加大质量治理力度。
通过高伟达公司实施的成功案例,我们深深体会到〝质量是打算出来的〞这一现代质量学观点所包蕴的深刻道理,因此,我们在项目启动及项目进展的各个时期都会认真制定各项工作打算,严格按照审核通过的打算进行项目操纵。
针对本项目,我们建议从QA及QC两方面保证项目的顺利实施,具体的质量保证措施如下:
1.1.2.5.1.质量保证
本项目将设置质量保证小组,由南京银行和高伟达公司各出一名人员担任QA的角色,其工作任务是依照项目总体组制定的质量核对单,在项目进展过程按照质量核对单逐项审核项目是否按照打算约定执行和操纵,并直截了当向南京银行的相关领导汇报项目实施的质量状况。
1.1.2.5.2.正式评审
依照本项目的特点,本项目中将对项目打算、软件需求规格说明书、系统设计说明书、测试规格说明书、测试报告等文档,组织南京银行相关领导、专家进行正式评审,以便审核系统开发中各时期所产生的过程文档,以保证文档内容与上一时期所产生的软件文档内容一致,同时符合使用者的需求。
1.1.2.5.3.交叉审查
除项目要求的正式评审内容外,本项目还将对各模块软件代码实行交叉评审制度。
各模块负责人应依照总体组制定的代码质量审核清单,对所负责检查的其他模块软件代码进行认真审查,对代码质量不能通过交叉评审的那么必须进行返工。
整体的软件代码交叉评审总量不能少于60%。
1.1.2.5.4.变更操纵
为保证软件产品质量,开发过程将严格采纳配置治理工具进行变更操纵,其目的是保证最终软件产品能够符合业务需求的各项要求,并对开发过程进行监控、报告和提供咨询支持,它包括下面的质量属性要求:
Ø软件产品与需求、说明书和设计一致;
Ø按照说明的标准建立文档;
Ø可测试和可爱护;
Ø被识别、治理、评审和测试;
Ø当变更发生时可治理。
1.1.2.6项目风险治理
任何项目开发实施过程中都会遇到各种风险,在各方面都会遇到不同规模的风险,因此需要了解工程本身的风险、技术风险、新产品的风险、工程资源风险、工程过程风险等全方位的风险因素。
通过对风险的量化提供一个打算来治理预防风险,同时关于潜在的风险也应该建立意外事件的应急打算,使其在必要时能够以可控的及有效的方式作出反应。
✓针对需求风险,南京银行应把握系统建设起点要高、规范运作为系统建设的基础工程、采纳构件化技术进行应哟软件开发、采纳B/S技术降低信息点爱护成本的方式规避需求风险。
✓针对合作风险,选择一个长久的、上规模、具备成熟行业体会、项目治理规范、技术先进、职员有归属感、真正站在用户的立场上考虑问题的公司作为后盾,高伟达集团是能为您最大限度地操纵合作风险。
✓针对资源风险,拥有健全的组织与治理,在幸免人员流淌的基础上,即使因个人缘故必须离职时,高伟达公司也因其规范的、体系化的治理与产品架构而使项目差不多不受阻碍或极少受到阻碍。
✓针对技术风险,高伟达的银行业务系统拥有多个成功实践体会,具备与国外接轨的理念与技术,同时拥有不断调整、更新的技术体系、以及参照标准体系指定规范质量标准并在实施过程中加强时期评审,使因为技术缘故而可能导致的风险降低到最小。
除此之外,为预防操作风险,在南京银行自身加强制度治理的基础上,高伟达还提供培训考试合格上岗及定期培训定期总结分析的模式来规避此类风险。
1.1.2.6.1.风险治理内容
风险治理的内容如下:
Ø项目实施前和实施中对风险的发觉、识别、上报、分析及风险责任人的指定;
Ø风险应对打算的制订和执行〔应对打算包括两部分,一是在如何降低风险发生气率的规避打算;一是当风险不幸变成现实时,如何应对的应急预案〕;
Ø风险状态的监控和更新;
Ø定期对项目风险进行统计、分类和总体结构分析。
1.1.2.6.2.风险治理中的相关角色和责任
参与方
角色
职责
备注
风险识别人
项目相关的任何人
报告发觉的风险,填写风险登记表描述风险,注明风险严峻度、风险发生气率和风险分类
假如是项目相关人员,提交至项目经理,假如是项目治理办公室人员,提交项目治理办公室主任
项目经理
项目内风险治理负责人
在项目进行中,治理项目内的风险并提供项目内的应对打算
关于无法在项目内解决的风险,审核风险登记表,并确认风险描述、风险发生气率、风险责任人以及风险发生后的应急预案
口头确认或书面认可上报的风险登记表,将风险登记表发往相应部门
项目治理办公室
项目整体风险治理的执行监督机构
在项目启动前,组织定义项目级别的风险登记、评估和应对打算
在项目实施时期,对项目报送的相关风险登记表和应对打算进行审核,重点审核跨项目的风险、严峻度为中或中以上的风险和发生气率为中或中以上的风险,建议整个项目的应对打算
依照对项目全社的考虑,更换项目上报风险之严峻度、发生气率和风险责任人
关于无法解决、风险严峻度为中或中以上的风险,负责上报项目总监
跟踪风险进展,对专门进展的风险进行预警
定期统计分析项目风险,在项目周报和月报中提交风险统计情形
项目总监
风险治理最终决策机构
对重大风险,进行决策,给出最终处理意见
风险责任人
风险规避、应急预案执行的负责人
填写风险登记表的风险分析与行动打算
负责风险应对的执行、并汇报风险状态变化
1.1.2.6.3.风险严峻程度
Ø灾难的:
会因为无法满足需求而导致任务失败,会产生错误导致进度延迟和预算严峻超支;
Ø严峻的:
会因为无法满足需求而导致系统性能下降,使得项目能否成功受到置疑,严峻阻碍项目里程碑的范畴、交付日期和交付质量以及会阻碍其它项目进展的风险;
Ø轻微的:
会因为无法满足要求而导致次要任务的退化,阻碍项目里程碑的范畴、交付日期和交付质量以及会阻碍其它项目进展的但不严峻的风险;
Ø可忽略的:
不阻碍或轻微阻碍项目里程碑的范畴、交付日期和交付质量的风险,只是无法满足要求而导致使用不方便或不易操作。
1.1.2.6.4.风险状态
Ø已提交:
风险识别人已填写风险登记表,完成了风险号分配、风险描述并有项目经理提交;
Ø拒绝:
项目治理办公室认为风险导入人所提出的风险不属于项目风险;
Ø已完成打算:
风险责任人得到风险登记表后,对其进行分析并完成应对打算;
Ø规避打算:
风险责任人正在依照顾对打算规避风险;
Ø风险已规避:
风险责任人已成功规避风险并得到项目治理办公室认可;
Ø发生进入应急打算:
风险责任人未成功规避风险,风险发生,执行应急预案。
1.1.2.6.5.风险分类
本项目中,风险要紧分为以下几类:
Ø治理类风险
项目治理没有遵循项目治理的制度、时刻、岗位的要求。
显现项目的风险。
Ø资源类风险
由于人力资源、设备环境等缘故产生。
例如,ATM设备没有驱动程序,无法进行程序调试。
Ø业务类风险
业务风险要紧表现在业务需求不清晰,变动频繁。
Ø技术类风险
技术风险要紧表达在技术架构不合理,各个子系统、服务渠道无法进行整合。
1.1.2.6.6.风险治理流程
风险治理流程包括:
Ø项目启动前风险识别与防范流程
在各项目启动前,应当由项目治理办公室指导各个项目提交其项目风险因素识别、评估和应对措施打算;
项目治理办公室依照各项目的风险识别打算,以及其对项目风险的明白得,完成项目风险因素识别、评估和规避的项目风险规避打算以及制订项目风险应急预案;
项目治理办公室将有关风险应对打算上报项目总监审批;
将项目总监审批过的风险应对打算提交给领导领导组审批;
审批通过的风险应对打算由项目治理办公室公布归档;
在项目实施过程中由项目经理治理风险应对打算的执行,项目治理办公室通过项目周、月报跟踪监督。
如以下图示:
Ø项目运行中风险治理流程
在项目实施过程中,所有项目组成员均有责任报告进程中发觉的风险因素,并报告项目经理;
项目经理在确定其确为风险后,定义风险发生气率和严峻度并指定风险责任人,制订风险一旦发生的应急预案,并将其填写风险登记表上报项目治理办公室;
项目治理办公室审核风险发生气率、严峻度和风险责任人并负责风险状态的监控;
风险责任人负责编制风险应对打算,并定期报告风险状态;
项目治理办公室负责发觉跨项目的风险因素,并主持评估规避打算和应急预案;
项目治理办公室将有关风险评估报告和规避打算、应急预案上报项目总监审批;
所有发觉的风险因素和审批通过的相应风险应对打算由项目治理办公室公布归档;
在项目实施过程中由项目经理治理风险应对打算的执行,项目治理办公室通过项目周、月报跟踪监督。
如以下图示:
1.1.3项目实施打算
1.1.3.1.1.项目组织架构
有效的组织结构,是项目成功的有力保证。
关于一个银行服务总线项目,除了考虑项目的有效治理,也要考虑SOA类项目的实施特点;依照本次项目的范畴和要求,项目的参考组织结构如下
1.1.3.1.1.1项目治理委员会
项目治理委员会负责监督并指导项目的实施进程,定期审核项目经理就项目进展执行情形的书面报告,对项目中存在的重大问题做出决策,和谐解决重大问题和突发事件,决定对项目经理的任免。
项目治理委员会由南京银行高层领导与本公司高层领导共同组成。
1.1.3.1.1.2服务总线治理组
向项目治理委员会负责,在项目实施过程中进行服务标准和原那么的操纵,在以后项目实施完毕后,由那个组织治理和批准新的服务公布和渠道系统的接入。
同时负责制定企业实施SOA项目的总体规划,从企业级的高度而非项目级参与项目治理。
服务总线治理组由南京银行架构师和本公司企业架构师共同组成。
项目实施完成后职责交给客户执行。
1.1.3.1.1.3项目治理组
负责向项目治理
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IT 项目 实施 管理 方案 投标 DOC45
![提示](https://static.bdocx.com/images/bang_tan.gif)