IT企业项目范围管理论文

2024-10-20

IT企业项目范围管理论文(精选7篇)

IT企业项目范围管理论文 篇1

随着信息技术的飞速发展, IT企业作为推动信息技术发展的重要力量, 其地位在经济发达国家提到了空前的高度, 但经调查研究发现, IT企业项目 (以下简称IT项目) 的成功率不高、项目实施效果不容乐观。影响IT项目成功因素有很多, 但项目范围管理的失控是主要原因之一, 在实践中, “需求蔓延”是导致IT项目范围管理失控最常见的因素, IT项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能, 从而使项目在时间、资源和质量上都受到严重影响。由此可见项目范围管理的重要性。

一、项目范围管理相关概念

范围的概念包括产品规范和项目范围两方面内容, 其中产品规范指产品或服务所包含的特征或功能, 项目范围指为了交付具有所指特征和功能的产品必须要做的工作。

项目范围管理是指保证项目范围规定的工作得以顺利完成的所有管理过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。简而言之, 项目范围管理就是:做什么?不做什么?包括什么?不包括什么?

二、项目范围管理的作用分析

在现实的IT项目管理中, 可以看到很多范围管理不到位而导致项目失败的例子。现从以下三个方面对项目范围管理的作用进行分析。

1、确定项目范围可提高项目成本、时间和资源估算的准确性。

如果项目的具体工作内容不明确, 项目的成本、时间和所需资源就不明确, 项目完成的不确定因素将大大增加, 面临巨大的危机。

2、确定项目范围有助于清楚地分派责任。

在明确项目包括那些具体的内容、具体有哪些要求、完成的产品应达到什么要求等内容后, 就为清楚地分派任务提供了必要的保障。

3、项目范围、时间、成本三个约束条件是相互影响、相互制约的。

时间、成本和范围构成一个稳固的三角形, 如图1所示。 (图1)

大多数项目都会有明确的完成日期、成本和范围的限制。时间、成本和范围三个要素被称为项目成功的三大要素。

在三角形中, 任何一边都不可能孤立地改变, 如果项目范围扩大, 必然导致项目成本增加和项目工期的延长。不成比例的变化与孤立的改变某一边是一样的, 都将破坏三角形的结构, 最终招致项目失败。因此, 有效的范围管理更像一门艺术, 可以帮助项目经理在已经确定的时间和成本下完成项目目标。

三、影响项目范围管理的常见因素分析

影响项目范围管理的因素很多, 经分析有以下几种:

1、IT企业没有完善的项目管理体系来指导项目管理工作。

此种情况下, 项目的成败完全依靠项目经理个人的管理、领导能力, 大部分项目都是以失败而告终, 因此建立健全项目管理体系是至关重要的。

2、项目范围的定义不够明确, 不能量化, 可验证程度低。

很多时候都是一些定性的要求, 例如“用户界面友好, 可操作性强, 便于使用及维护”等, 类似这些模糊的界定往往是导致后续项目扯皮的根源。对项目范围的明确定义, 有经验的项目经理及系统分析人员将起到关键性的作用。

3、客户本身原因造成项目范围管理上的困难。

主要包括两方面原因:一是客户本身无法确定清晰的范围定义;二是客户有意拖延明确的范围定义。

针对第一种原因, 要向客户方介绍或带领其参观已经完成的项目, 消除对方的疑虑, 清晰对方的思维。针对第二种原因, 如果处理不好, 不但无法做好范围管理, 还会影响双方的合作关系, 影响到可能存在的后续业务。此时, 项目经理要组织人员做好攻关, 软硬兼施, 让客户方负责人真心投入, 提高对方领导的重视程度, 加深项目干系人对各阶段性工作的印象, 扩大范围定义在客户方单位的认知度和影响面。

4、合同方面的原因造成项目范围难以管理。

在合同签订前销售人员为了能够尽快签单, 往往对客户会有一些不切实际的承诺, 在客户的印象中项目产品已经是无所不包了, 使得客户产生很多不切实际的期望。另外, 国内IT企业签订的合同一般都比较简单, 很少对项目范围有明确规定, 造成项目的范围存在很大的不确定性, 留下了很大的隐藏风险。合同签订后项目小组和客户要有一个渐进的项目范围交互、降低期望的过程, 否则容易出现观点冲突, 对项目的推进造成影响。

四、如何做好项目范围管理

要做好项目范围管理工作必须先了解项目范围管理的一些科学过程, 然后认真按照这些科学过程进行项目的范围管理。依据美国项目管理协会 (PMI) 项目管理知识体系指南 (PMBOK) 中给出的严格定义, 其中包括启动、范围计划、范围定义、范围核实、范围变更控制等内容。

1、项目启动过程。

项目启动是正式承认一个新项目的存在或一个已有项目进入下一个阶段的过程。该过程有一个重要的输出文档是项目章程, 项目章程粗略地规定项目的范围, 这也是项目范围管理后续工作的重要依据。项目章程规定项目经理的权利以及项目组中各成员的职责, 还有项目其他干系人的职责, 这也是在以后的项目范围管理工作中各个角色如何做好本职工作有一个明确规定, 保证后续工作可以更加有序地进行。项目一般是由市场需要、经营需要、客户需要、技术进步、法律要求等一个或多个需要而启动的。

2、项目范围计划过程。

范围计划的核心工作是编写正式的项目范围说明书和范围管理计划。范围计划编制是将产生项目产品的所需进行的项目范围渐进明细和归档的过程。做范围计划编制工作需要参考很多信息, 通常它对项目范围已经有粗线条的约定, 范围计划在此基础上进一步深入和细化。范围说明书在项目干系人之间确认或建立了一个项目范围的共识、作为未来项目决策的文档基准。在进行项目范围规划时, 必须慎重考虑与权衡工具、数据来源、方法、过程与程序, 以及其他因素, 确保为项目而付出的努力与项目的大小、复杂程度和重要性相称。

3、项目范围定义过程。

范围定义指的是把项目产出物进一步分解为更小的、更便于管理的许多组成部分。一个好的范围定义可以提高对项目成本、项目工期和项目资源需求估算的准确性;为项目的绩效度量和控制确定一个基准;便于明确和分配项目任务与责任。在这个过程中, 项目组要建立一个工作分解结构 (WBS) 。WBS的建立对项目的意义非常重大, 它使得原来看起来非常笼统、模糊的项目目标一下子清晰起来, 使得项目管理有依据, 项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时, 变更就不可避免地出现, 很可能造成返工、延长工期、降低团队士气等一系列不利后果。

4、项目范围核实过程。

范围核实是通过参与者的行为正式确定项目范围的过程。它要求回顾生产过程和生产成果, 以保证所有项目都能准确、满意地完成。这个过程是范围确定之后, 执行实施之前各方相关人员的承诺问题。一旦承诺表明你已经接受该事实, 那么你就必须根据你的承诺去实现它。

5、项目范围变更控制过程。

范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行为与教训总结。再好的计划也不可能做到一成不变, 关键是对变更进行有效控制。

客户在项目开始之前不能明确所有的需求, 随着业务的发展、客户认识的提高, 客户的需求也在发生变化, 客户提出变更是不可避免的。变更并不可怕, 可怕的是随意的、没有控制的变更。为了使变更有序, 需要与客户一起, 建立变更控制委员会 (CCB) , 制定严格的变更制度、变更流程, 将一切非必要、非紧急、不合理、非高层领导意图的“无效变更”屏蔽掉, 同时采用变更申请表格和配置管理工具有效地管理变更。

五、总结

影响IT项目最后成功的因素是多方面的, 包括项目管理的九大知识领域。有效的IT项目范围管理对项目的成功运作具有重要的意义, 范围管理的成功与否直接影响到对项目进度、质量、成本的有效掌控以及对项目风险的控制。

参考文献

[1]吴吉义, 殷建民, 信息系统项目管理案例分析教程[M], 北京, 电子工业出版社, 2006.33.

[2]黄德业, 软件项目之范围管理[J], 福建电脑, 2007.9.

IT项目范围管理和风险管理研究 篇2

1项目管理

关于项目管理,对各种不同的观点和看法进行总结,就能够发现,项目管理其实就是各种资源被项目关系人实际应用到项目当中,继而对项目的目标进行实现,促进项目关系人从项目中获得更多的满足感。 在这个过程当中,项目管理和项目本身都得到了相应的发展,也不断地对项目管理的意义进行着充实。 在现代的管理工作中,项目管理是一种新兴的管理方式,被人们所逐渐重视,也成为了科学化管理的代名词。

现阶段, 随着我国社会经济的不断发展,IT行业也得到了大力的发展,但是实施IT项目的效果却始终不尽人意,对项目失败的原因进行系统的总结, 能够发现原因主要为以下几点:其一,项目需求频繁发生变化;其二,随着项目的规模不断增大,但是IT项目管理的范围始终难以界定。 由此可发现,导致项目管理失败的主要原因就是由于难以对管理的范围进行界定。 一般来说,在对IT项目及进行管理范围界定时,需要进行以下几个环节:规划范围、定义范围、分解工作的结构、控制范围,这几个环节之间有着密不可分的关系。 在实行项目管理的过程中,要反复对顶层进行应用分析和验证,将项目的需求渐渐转变为对应的系统型。 在进行验证的过程中,要对相关的物理管理结构和体系进行设计, 保证IT项目能够实现各项性能的要求。 对实际的项目管理情况进行分析,能够对管理范围进行流程的归纳,主要是以下几个方面:其一,项目章程;其二,规划范围;其三,定义范围;其四,分解WBS,然后对其范围进行确定。 在实际的工程操作当中,实施的流程具有较大的变动性,项目处于的环境始终都是变化的, 各种因素都会对其产生影响,项目本事同时也处于不断变化的状态。 对于这样的情况,实施项目管理的开展项目中各项工作的初始阶段,只有如此才能够对其进行有效的管理,对项目的发展工作进行推动。

2风险管理

(1)IT项目中的风险管理。 风险管理就是对管理方法或者方案进行假设,假设其中存在漏洞,随后管理其可能引发的负面影响,在实施项目的风险管理时,主要内容有五个方面。 其一,识别风险,就是系统和连续对客观的风险进行识别和归类,在识别的过程中,一般都形成一定的风险列表,识别风险的方法主要是事故数分析法、 财务报表分析法以及事件分析法等。其二,分析风险,就是在识别风险的基础上,定量和定性地分析风险,在这个过程中,主要的分析内容就是系统的分析和单项的分析。 单项的分析系统对过去的风险资料进行分析,从而对可能出现的分析进行预测, 系统的分析就是以单项分析为基础,对风险出现的概率进行预测。 其三,应付风险,在这个过程中,要对风险进行控制,对风险导致的负面影响进行消除、避免和降低,评估风险的发展,并根据评估的结果对应对风险的方案进行及时地调整。 其四,补偿风险,就是当风险出现在管理的过程中时,采取经济的手段对已经发生的损失进行处理,对风险导致的经济损失进行补偿,也就是在发生风险后,对其导致的后果进行相应的处理,降低风险所造成的不利影响。

(2) 规避风险的措施。 随着对经济市场的不断完善, 市场中的竞争也愈发激烈。 在开发IT项目的过程中不但要对技术进行有效地提高,还要对其中隐含的风险进行规避,可以从这几个方面来进行规避。 其一,制定项目章程,开发IT项目的工作是一个较为复杂的过程,具有较强的系统性与技术性。 其二,组建相应的项目团队,若要将整个IT项目进行完善,其中必须包含开发设计、测试安装和配置等多项活动和内容。 其三,增强技术培训, 有效地利用人才是完成IT项目最重要的环节。 其四, 对项目的实施过程进行存档保存, 在开发IT项目的过程中,要注重相关工程的规范性,为用户提供各个实施环节的相关资料,使得项目在开发过程中有实际依据,以免对正常的操作产生影响。 针对开发项目的过程,可以采取相应的规避风险的措施,保证项目的顺利实施和完成。

3结语

随着IT项目的不断发展, 参与项目的人员应当具有一定的风险意识,在制定管理制度的同时进行风险识别,并做出正确的评估,将风险造成的影响在最大程度上进行降低。

摘要:在IT项目的开发和研究过程中,存在着较多的风险,风险的发生会带来较为严重的影响,因此要进行相应的管理。文章对范围管理和风险管理进行了研究,并提出相应的规避风险的措施。

项目范围管理题目 篇3

1.工作分解结构的基础是()。

A.产品需求 B.项目需求C.干系人的全部需要和期望D.产品需求和项目需求 2.项目范围说明书中通常包括以下哪些内容?()A.产品范围、项目可交付成果、项目进度里程碑、项目除外责任

B.产品范围、产品验收标准、项目可交付成果、项目组织结构图、项目除外责任

C.产品范围、产品验收标准、项目可交付成果、项目除外责任、项目制约因素 D.产品范围、产品验收标准、项目可交付成果、项目假设条件、项目审批要求 3.核实范围的主要内容是什么?()A.确保项目可交付成果按时完成

B.通过确保客户对可交付成果的接受,保证项目不偏离轨道 C.确保可交付成果符合技术规范 D.给人们提供一个发表不同意见的机会 4.以下哪个是收集需求的输入?()A.项目工作说明书 B.项目章程 C.干系人管理策略 D.采购工作说明书 5.以下关于产品范围和项目范围的说法,哪个是正确的?()A.项目范围服务于产品范围

B.项目范围的变化必然引起产品范围的变化 C.产品范围的变化必然引起项目范围的变化 D.产品范围服务于项目范围

6.控制账户是工作分解结构某个层次上的要素,以便()。A.指定工作的责任人或小组 B.进行挣值管理 C.与工作包一一对应 D.汇总项目的成本数据 7.以下哪个不是项目范围管理的过程?()A.收集需求 B.创建工作分解结构 C.实施工作分解结构 D.核实范围 8.用来衡量产品范围完成情况的文件是()。

A.项目管理计划 B.项目范围说明 C.项目工作分解结构D.产品需求文件 9.以下哪项是收集需求过程的工具与技术?()A.控制图 B.鱼骨图 C.流程图 D.亲和图 10.下列四个选项中,不属于备选方案识别技术的例子是()。A.价值工程 B.横向思维 C.配对比较 D.名义小组技术 11.范围蔓延是指()。

A.项目范围的合理延伸 B.产品范围的合理延伸

C.经过批准的项目范围或产品范围变更D.未得到控制的项目范围或产品范围变璧

12.项目范围变更()。

A.也叫做范围潜变 B.是不可避免的

C.会影响进度、成本等,必须被拒绝 D.应该由项目发起人来审批 13.定义范围过程旨在()。

A.制订范围管理计划 B.制定项目范围说明书 C.制定项目工作说明书 D.制定工作分解结构 14.核实范围过程与实施质量控制过程的关系是()。A.经质量检查合格的可交付成果才能进行范围核实 B.经范围核实符合要求的可交付成果才能进行质量检查 C.应根据具体需要,先做质量检查或先做范围核实 D.质量检查和范围核实通常可以同时进行 15.应该在什么阶段核实范围,以保证在可交付成果完成时及时进行验收?()A.项目执行 B.项目监控 C.项目收尾 D.项目变更 16.系统工程、价值工程、价值分析和系统分析经常用于()。A.备选方案识别 B.可交付成果识别 C.项目制约因素分析 D.产品分析 17.核实范围过程旨在()。

A.审核项目范围基准的正确性 B.审核工作分解结构和工作分解结构词典的正确性 C.审核项目范围说明书的正确性 D.验收已经完成的可交付成果

18.以下哪个是控制范围过程的输出?()A.工作绩效信息 B.工作绩效测量结果 C.技术绩效测量结果 D.绩效报告 19.在整个项目生命周期中,用于监督、核实和控制项目范围的文件不包括()。

A.项目工作说明书 B.项目范围说明书 C.工作分解结构D.工作分解结构词典 20.在项目的环境中,“范围”可以指()。A.产品范围和工作范围 B.产品范围和项目范围 C.项目范围和管理范围 D.项目范围和需求范围 21.以下各项都是收集需求过程的输出,除了()。

A.需求管理计划 B.需求识别文件 C.需求文件 D.需求跟踪矩阵 22.工作分解结构的第一层通常可以是()。

A.项目阶段 B.高层次的可交付成果 C.准备外包出去的子项目 D.以上都是 23.下列哪一项最恰当地描述了项目范围说明书?()A.项目范围说明书是规划范围过程的输出 B.项目范围说明书识别项目的目标和可交付成果 C.项目范围说明书一经制定,就不允许更改 D.每个项目只能有一份项目范围说明书 24.项目范围管理旨在确保()。

A.做尽可能多的工作,使项目尽可能完美 B.做而且只做为成功完成项目所需要的工作 C.为客户提供额外的产品功能 D.确定不包括在项目范围内的工作

25.以下哪个不是创建工作分解结构过程的输出?()A.项目范围说明书B.工作分解结构 C.工作分解结构词典 D.范围基准 26你正在管理一个新产品研发项目,要研制出一种永不卡住的拉练。“永不卡住”是属于()。

A.项目需求 B.商业需求 C.交付需求 D.产品需求 27.项目范围说明书()。

A.用来记录项目的主要可交付成果及所需开展的项目工作 B.有助于创建WBS C.用来明确怎样对已完可交付成果进行正式核实与接受 D.用来指导对项目范围变更请求的审批

28.收集需求的工具与技术中,通常采取“一对一”的形式的是()。A.访谈 B.问卷调查 C.德尔菲技术 D.引导式研讨会 29.以下哪个文件会明确说明那些被排除在项目之外的内容?()A.工作分解结构B.项目范围说明书C.项目范围管理计 D.工作分解结构词典 30.工作分解结构底层的要素是()。

A.控制账户 B.规划包 C.规划要素 D.工作包 31.在以下哪种情况下,应该采用观察的方法来收集项目干系人的需求?()A.干系人的数量很少时 B.需要用渐进明细的理念来开发需求时 C.干系人不愿或不能说明他们的需求时 D.需要组建焦点小组时 32.项目需求包括下列所有,除了()。

A.产品性能需求 B.商业需求 C.项目管理需求 D.交付需求 33.以下哪个是收集需求过程的输入?()A.项目工作说明书 B.项目范围管理计划C.干系人登记册D.干系人管理策略 34.以下哪个是控制范围过程的输出?()A.工作绩效信息B.工作绩效测量结果 C.绩效报告 D.质量控制测量结果 35.关于WBS的说法,哪项是正确的?()A.WBS的第一层可以是可交付成果、项目阶段或子项目 B.WBS的第一层可以是可交付成果、项目部门或子项目 C.WBS的第一层可以是可交付成果、项目阶段或项目活动 D.WBS的第一层可以是项目部门、项目阶段或项目活动 36.定义范围的一个输入是()。

A.项目工作说明B.需求文件 C.工作分解结构(WBS)D.需求跟踪矩阵 37.收集需求过程是()。

A.定义并记录干系人的需求 B.主要关注产品需求 C.主要关注项目需求 D.主要关注性能需求 38.以下哪个最好地描述了工作分解结构(WBS)?()A.WBS是对工作成果的层级分解 B.WBS是对工作本身的层级分解 C.WBS是对项目产品的层级分解 D.WBS是对项目活动的层级分解 39.核实范围过程旨在()。A.正式验收可交付成果 B.审查项目范围文件的正确性 C.检查可交付成果的技术正确性

D.发现项目范围偏差,管理项目范围基准变更

40.你的一个合同商给你发了一封电子邮件要求使用更高质量的原材料,这将会导致费用增加和质量得到提高。项目经理应该首先做什么工作?()A、更改项目基线

B、要求合同商发一份正式的变更请求 C、询问你的发起人的意见 D、更改WBS

41、客户通知你对原始范围做一项小的变更。与整个项目相比,这是一项很小的投入,并且你需要这个大项目的亲善关系。你将:()A、拒绝做这个工作。B、同意免费做这个工作。

C、做这个工作,然后给客户开账单。

D、评估这个工作对成本和进度产生的影响,然后告诉他们你将在晚些时候决定这件事。

42、一个项目的启动阶段输出不包括下列哪项?()A、项目章程

B、约束条件

C、产品描述

D、项目经理选择

43、范围确认的主要内容是什么?()A、确保项目可交付成果按时完成

B、通过确保客户对可交付成果的接受保证项目不偏离轨道 C、显示可交付成果符合技术规范 D、提供一个发现不同意见的机会

44、关于项目可交付成果,下列哪句是正确的?()A、项目可交付成果是在完全定义了工作之后确定的。

B、在项目计划编制期间对项目可交付成果进行描述,然后随着时间的推 移对它们进行细化。

C、在项目开始时用项目干系人的输人对可交付成果进行定义。D、项目可交付成果由项目发起人来确定。

45、你正在管理一个为期6个月的项目并且每两周与你的项目发起人开一次会。在工作了五个半月后,这个项目既符合进度又在预算内,但是项目发起人对可交付成果不满意。这一情况会把项目完工延误一个月。可以防止这种情况的最重要的过程是:()

A、风险监控

B、进度控制

C、范围计划编制

D、范围变更控制

46、除了()下面所有陈述是错误的? A、WBS传达每个定义项目活动的日历日期 B、WBS对每个定义活动的商业需求加以说明 C、WBS向项目干系人传达定义的项目活动

D、WBS对负责每项定义项目活动的职能经理加以说明

47、产品文件是()的输人。A、范围确认

B、绩效报告 C 风险分析

D、范围计划编制

48、一个项目经理正在对一项可交付成果实施审计时听到做这项工作的团队成员对所有人抱怨说,审计他做的工作是挑他的刺儿。你知道这是不对的。对于今后的项目你应该吸取什么教训?()

A、在项目开始时就告诉团队成员,他们的可交付成果将受到审计。B、在范围管理计划中制定一项政策。C、降低审计频率。

D、用简单检查代替审计。

49、在已经建立的绩效测量基准计划之后,客户要求扩大项目范围。客户将需要提交哪类文件?()

A、变更申请

B、工作说明 C、修改的项目进度计划

D、发票

50、在一个设计项目开始两个月后,客户要求对产品作修改。在没有通知项目经理的前提下就做了这项变更。在最终测试阶段,测试结果与当初计划的不同。这种情况是下列哪项的例子?()

A、测试计划定义不完善

B、质量管理计划的开发不完善 C、使用范围变更控制的技能差

D、不坚持沟通计划

51、下列哪项不是范围计划编制的部分?()

A、检查

B、确定备选方案 C、质量功能展开

D、成本/收益分析

52、一个职能经理与项目经理的上司开会讨论对一个主要可交付成果的验收标准做一项变更。会后,这个上司与项目经理联系,让他实施这项变更。对这种情况最佳的做法是什么()A、尽快做这项变更 B、理解该项变更

C、给管理层一份变更申请表,让他们填写后尽快交回 D、把这项变更告诉团队

53、项目大部分已经完成,客户要求对工作范围做重大变更。项目经理应该:()A、与项目团队开会,决定是否可以做此变更 B、向客户要该项变更的描述

C、向客户解释,进展到这个程度不能再做此项变更 D、通知管理层

54、项目经理想要使用Delphi技术获得专家对他所遇到的一些技术难题的意见。他应该谨慎地做什么?()

A、确信所咨询的专家对他们的输人是公认的。B、对任一种意见都进行信息与工作比较。C、咨询项目干系人。

D、与专家们一起开会,得出一致意见。

55、一个项目发起人给了项目经理一份章程并告诉该项目经理,他不能肯定该章程是否完整。项目章程应包括:()

A、可交付成果和目标

B、详细的工作范围 C、详细的进度计划

D、网络图

56、一个项目经理从一个团队成员那里收到一项应提交给客户的可交付成果。在查看这项可交付成果时,项目经理注意到该文件比预期的要少一些并且没有他认为应该包括的内容。这个项目经理应该首先:()A、与该团队成员讨论

B、与该团队成员的经理联系,让那个人接受额外的培训 C、审计开发过程 D、完成产品确认

57、在实施期间,你发现尽管以前已经批准了工作范围,但客户却对工作范围进行了变更,对该项变更的成本没有异议。你应该首先做什么?()A、遵循变更过程。

B、与客户讨论该项变更并协商新的范围。C、与团队开会,计划选择方案。

D、对该项变更可能导致的风险进行评估并形成文件。

58、产品确认不同于范围确认,产品确认;()A、在实施阶段发生

B、确认使用了正确的产品 C、获得客户的签字认可

D、确保所有工作都已完成

59、一个项目经理刚刚被分配到一个新项目中并得到一份完整的项目范围。这个项目经理必要做的第一件事是什么?()A、使用WBS建立项目计划

B、确认所有项目干系人的输人都包括在工作范围中 C、组织一个团队制定采购计划 D、建立网络图 60、在对一项任务的检查中,你发现一个团队成员正在用与WBS词典中的规定不同的方法完成这项工作。你应该如何处理这种情况?()A、告诉这名团队成员采取纠正措施。

B、确定这种不同的方法对职能经理是否是可接受的。C、问这名团队成员,这种变化是否必要。D、确定这种变化是否改变了工作包的范围。61、一个新项目经理正要编制项目的工作范围。一个项目干系人要在工作范围中加入很多事项。另一个项目干系人只是要求描述功能要求就可以了。这个项目对项目经理所在公司很重要,但是工作是由卖方来实施。你建议这个项目经理做下列哪项?()

A、工作范围应是概括性的,以便允许卖方做自己的决策 B、工作范围应是概括性的,以便可以在以后澄清 C、工作范围应是详细的,以便可以在以后澄清 D、工作范围应详细到该类型项目所需的详细程度.62、下面哪种文档是项目经理首先要向项目团队成员定义的,为了在项目启动会议上就展示该项目是被官方批准正式成立的项目?()A、项目章程

B、项目计划

C、可行性研究

D、费用——收益分析 63、项目经理并不能确定某个特定的工作包中包含了什么。为了能更好地理解一个工作包中包含了什么,项目经理应该首先查看:()A、进度控制文档

B、账户编码 C、WBS字典 D、风险管理计划 64、你的一个合同商给你发了一封电子邮件要求他们只答应进行8次测试,而不是你方要求的10次测试。项目经理应该首先做什么工作?()A、更改项目基线

B、要求合同商发一份正式的变更请求 C、在合同中找到处罚条款 D、询问你的发起人的意见

65、你是变更控制委员会中的一员,批准巨大的范围变更。项目经理首先第一步需要更新的文档是:()

A、范围基线

B、进度 C、WBS

D、预算

66、在你以前的项目实施期间,即使你交付了客户指定的内容,你也很难得到范围定义的签字认可。为了未来项目更好实施,你会更注意哪个过程?()A、绩效报告

B、范围确认 C、范围定义

D、管理收尾

67、下列规则除()以外对于工作分解结构最低层次的工作包都是正确的。A、可以在一个位置不发生中断地完成 B、可以做出可信的估算 C、必须且只能分配给一个人 D、必须在80小时内完成

68、下列哪项最不真实?()A、WBS的最低层次也可以叫工作包

B、WBS词典可以用于保存各种工作要素的说明

C、承包商的WBS和合同工作分解结构(CWBS)基本上是相同的 D、WBS中的工作包还可以进一步细化

69、效益测量和约束条件下的最佳化是()的例子。A、成本效益比

B、可变成本 C、折旧类型

D、项目选择方法 70、用于开发的分解过程是什么?()

A、管理计划

B、沟通计划 C、工作分解结构

D、挣值 71、项目的工作分解结构是项目经理和她的团队一起开发的。但现在项目团队成员好像正在做工作分解结构以外的工作。工作分解结构的目的是:()A、指导项目的成本估算,而不是工作怎么做 B、给高级管理层提供高层次项目范围概观 C、把制造项目产品所需的工作包括进去

D、把整体项目范围或完成项目所必须做的全部工作包括进去 72、参与准备范围基准计划的是:()

A、职能经理

B、项目团队 C、所有干系人

D、项目发起人

73、一个新软件产品的构建阶段即将完工。下一个阶段是测试和执行。这个项目比进度计划提前了两周。在进人最后阶段之前,项目经理最应该关注什么?()A、范围确认

B、质量控制 C、绩效报告

D、成本控制 74、一个客户要求你给项目增加工作范围。现在项目低于预算并比进度计划提前一些。你应该怎么做?()A、批准该项变更

B、让客户了解该项变更对项目的影响 C、请发起人批准该项变更

D、从配置变更委员会获得批准 75、下列哪项是范围确认的一项重要输入?()A、工作结果

B、历史信息 C、正式接受

D、变更申请 76、下列哪项不是范围确认的输入?()

A、工作分解结构

B、项目计划 C、工作结果

D、变更申请 77、工作分解结构可以用于下列哪项?()

A、与客户沟通

B、显示每项任务的日历日期 C、对每个团队成员显示职能经理

D、显示对项目的商业需求 78、下列哪项不是范围确认的工具?()

A、产品审核

B、审计

C、检查

D、灵敏度分析 79、在编制WBS时不需要下列哪项?()

A、历史信息

B、项目章程 C、假设条件

D、范围说明 80、在一个新产品的开发中,我们发现竞争对手正在开发一种与我们的项目产品有相似功能的新产品。我们决定建议对产品特性和项目产品做变更。这种变更申请是()的结果。A、外部事件

B、在定义产品范围中的错误或遗漏 C、在定义项目范围中的错误或遗漏 D、一项增值变更

81、什么时候向一个项目指派项目经理?()

A、合同签订后

B、就在合同时执行之前 C、合同启动期间

D、合同计划编制期间 82、在过去的几周项目团队已经对活动和任务做了3项范围变更。项目经理必须非常仔细地:()A、记录所有变更

B、向发起人提交所有变更的文件 C、确保变更都反映在项目范围内 D、防止更多的变更发生 83、一个项目经理发现两个团队成员讨论要完成一项活动需要什么并且做了很多范围变更。现在这项可交付成果完成了,那两个团队成员准备进行下一项任务。在看了他们所做的之后,项目经理确定他们所做的工作不符合项目要求。该项目经理的最佳行动路径是什么?()

A、增加另一项任务,与正确的项目范围相符合 B、拒绝交付的任务

C、让团队重新做这项任务并把这个事故加人到他们的绩效审核中 D、请该团队成员的经理派别的人执行这项任务 84、范围确认应在何时做?()

A、项目结束时

B、项目开始时 C、项目的每个阶段期间

D、计划编制期间 85、项目进行到一半时,客户想取消剩余的工作和合同。最佳的方法是查看下列哪项来确定项目的目的?()

A、章程中的目的、目标和商业案例 B、WBS词典,以便验证范围是否正确 C、风险管理计划,以便评估可选方案 D、会计科目表,以便确定完工估算

86、你是一个IT项目的项目经理。你项目团队的一个信息专家在同与他一起工作的一个低级别客户代表共进午餐后得知,在显示中一项简单的改造会给项目增加巨大的附加功能。你和项目发起人都已经对范围签字认可。那位信息专家进行了这项改造,没有给项目进度带来负面影响,也没有增加额外的费用。你应该采取什么管理措施?()

A、这位信息专家所做的超过了客户预期,并且既没有影响项目成本也没有影响项目进度,因此,这位信息专家应该受到表扬。

B、项目经理应该在项目计划中增加一项没有相应时间的任务。

C、应该告诉这位信息专家,他的行为是不可接受的,因为它完全可能给整个项目带来负面影响。

D、由于这项变更已经做了,因此项目经理应该做一份变更控制表并请客户在上面签字。案例分析题

小杨第一次管理一个大型的软件研发项目,该项目是在以前项目的基础上研发新的功能。以前项目的版本已经批量安装到客户,并达到预先设定的目标稳定程度。该项目在前期各个阶段的数据都符合原先设定的目标。但是,在系统测试阶段,测试人员却递交了大量的缺陷。经过分析,发现这些问题大多数是回归测试时发现的。而其中大部分是以前项目遗留的问题。这些问题介于优化和问题之间。不会影响基本功能,但是对新用户来说,也有修改的必要。新的用户的验收测试不久就要开始了。小杨该如何处理这些问题呢? 答案提要:

1、原项目遗留问题是否在项目范围内,需要查看项目范围说明书;一般情况下不会包含原系统的问题修改;如果在范围内,则需进行修改。

2、如果不在范围内则需要与公司和客户沟通,估算修改的成本以及风险等因素,如果要修改,则需要做哪些工作,例如追加费用,会可能引发哪些进度方面的变化,存在哪些风险。

3、如果要修改发现的以前项目遗留问题,应该属于原项目的优化,与本项目无关。但是也需要与客户和公司沟通,一般而言,对于历史遗留问题,公司是有责任修改的,但是对于当前项目而言,可能会有很多影响,需要就该修改进行分析,是否要修改与公司和客户共同协商,寻求解决办法。

4、作为项目经理,不仅仅是该项目的项目经理,也是公司面向客户的一个形象,很多时候还需要考虑公司整体的利益,而不仅仅是原定的项目范围。

所以项目经理任务项目范围是一定要区分清楚,但是是否进行能修改是需要与公司上层和客户沟通清楚,明确其中的责任和风险

单项选择题参考答案

IT企业项目范围管理论文 篇4

1项目质量管理系统

1.1系统定义

质量管理系统方法鼓励企业分析顾客要求, 规定相关的过程, 以实现顾客能接受的产品。 质量管理系统能提供持续改进的框架, 使顾客和其他相关方满意。 质量管理系统还就企业能够提供持续满足要求的产品, 向企业及顾客提供信任。

1.2相关术语

(1) 质量 : 一组固有特性满足要求的程度 。

(2) 要求 : 明示的 、 通常隐含的或必须履行的需求或期望。

(3) 顾客满意度 : 顾客对其要求已被满足的程度的感觉 。

(4) 能力 : 组织 、 体系或过程实现产品并使其满足要求的本领。

(5) 系统 : 相互关联或相互作用的一组要素 。

(6) 管理 : 建立方针和目标并实现这些目标的体系 , 是相互协调的活动。

(7) 质量管理 : 指导和控制组织的关于质量的管理体系 。

(8) 质量保证 : 质量管理的一部分 , 致力于提供能满足质量要求的信任。

(9) 质量目标 : 关于质量的所追求的目的 。

1.3方法和步骤

(1) 确定顾客和其他相关方的需求和期望 。

(2) 建立企业的质量方针和质量目标 。

(3) 确定实现质量目标必需的过程和职责 。

(4) 确定和提供实现质量目标必需的资源 。

(5) 规定测量每个过程的有效性和效率的方法 。

(6) 应用这些测量方法确定每个过程的有效性和效率 。

(7) 确定防止不合格并消除产生原因的措施 。

(8) 建立和应用过程以持续改进质量管理系统 。

1.4开发环境及完成期限

系统开发周期约为3个月。

人力资源: 6人 (项目经理一名, 需求分析负责人一名, 概要设计负责人一名, 详细设计负责人一名, 编码设计负责人一名, 软件测试负责人一名);

开发环境: 操作系统, Windows XP及以上版本; 开发工具: Visual Studio 2008; 开发语言, C#。

2项目质量管理系统设计

2.1系统各模块关系图

如图1所示 。

2.2系统功能

系统功能设计包括: 质量标准管理、 质量报表管理、 质量评估管理、 综合查询等。

质量标准管理: 本模块负责收集国际国家项目相关标准, 并可由项目经理制定本项目在实行过程中的相关项目、 任务、 事件及可交付成果等标准, 以及进行对项目标准的修订管理等工作。 具体功能包括:

(1) 新建项目计划 : 在立项之初建立项目计划 , 初步制定项目中的各个活动及其完成时限及资源分配, 系统以此绘制出项目甘特图。

(2) 修改项目计划 : 对项目计划进行修改 , 增加 、 修改或删除项目中的活动, 并制定其新的完成时限及资源 分配 , 系统以此更新项目甘特图。

(3) 新建质量标准 : 在项目开始之初对项目设定所需质量标准, 以便在项目开展过程中对其进行监管。

(4) 修改质量标准 : 在项目实施过程中根据被允许的范围调整计划进行质量标准的重新修改, 对于制定有误的质量标准或无意义的标准进行删除。

质量报表管理: 本模块负责根据项 目组成员 提交的日 、 周、 月报表, 来统计编制本项目的日、 周、 月报表信息。 具体功能包括:

(1) 填写提交报表 : 项目组成员填写日 、 周 、 月等相应报表并提交至质量管理子系统。

(2) 修改报表 : 若提交后某时段内发现报告有误可进行修改, 超过时段限制则不可修改。

(3) 删除报表 : 本功能仅供系统管理员进行系统维护之时使用。

质量评估管理: 本模块负责对项目、 任务、 事件及各种可交付成果进行评估, 以便对其过程及结果进行有 效控制 。 具体功能包括:

(1) 项目评估 : 对项目总体进行评估 , 一般在项目收尾阶段进行, 对项目完成情况进行总结。

(2) 任务评估 : 对项目中的某项任务进行评估 , 对任务完成情况进行总结, 并决定任务的评价及补充工作。

(3) 事件评估 : 对项目中的某个事件进行评估 , 并做出事件总结。

(4) 可交付成果评估 : 对项目中应当进行交付工作的可交付物进行评估, 评价成果的完成情况并对决定是否进行修缮。

综合查询: 本模块可查询质量管理子系统中的各种信息, 在搜索前可先指定搜索的范围, 再根据不同关键字进行搜索。

2.3软件生命周期模型

本项目选择瀑布模型进行开发。 虽然瀑布模型仍然存在很多的问题有待解决, 但瀑布模型仍然是最基本的和最有效的软件开发生命周期模型。 瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行, 每一个阶段都可以定义明确的产出物和验证准则。 瀑布模型在每一个阶段完成后都可以组织相关的评审和验证, 只有在评审通过后才能够进入到下一个阶段。

由于需要对每一个阶段进行验证, 瀑布模型要求每一个阶段都有明确的文档产出, 对于严格的瀑布模型每一个阶段都不应该重叠, 而应该是在评审通过, 相关的产出物都已经基线后才能够进入到下一个阶段, 如图2所示。

2.4项目阶段与工作产品

如表1所示 。

3结语

本质量管理系统以产品质量管理为中心, 采集完善的质量信息数据, 实现对原材料的质量监控等, 为日常原 材料 、 生产过程、 用户服务、 供应商管理、 设备及质量的质量信息的查询 、 统计和分 析提供平 台 。 本系统采 用Microsoft SQL Server 2008作为后台数据库 。 其内置的数据库引擎可以控制访问权限并快速处理数据, 搜索引擎可以对SQL Server表中的数据进行索引, 提高了检索速度。

摘要:为了成功地领导和运作一个IT企业,需要采用一种系统、透明的方式进行管理。根据所有相关方需求,实施持续改进的质量管理系统,可使IT企业获得成功。质量管理是IT企业实施项目管理的重要内容之一。过去那种基于人主观因素的影响很大,致使很多时候软件质量不能保证。建设项目质量管理系统是IT企业实施项目开发一项很重要的工作,通过项目质量管理系统可以使IT企业科学进行项目管理,企业能够良性持久地发展。

关键词:IT企业,项目质量,管理系统,分析,设计

参考文献

[1]张跃廷,王小科,张宏宇.C#程序开发范例宝典[M].北京:人民邮电出版社,2007.

[2]邵维忠,麻志毅,等,译.UML用户指南[M].北京:人民邮电出版社,2009.

IT企业项目范围管理论文 篇5

在当今信息技术日新月异, 飞速发展的现代社会, 计算机、软件、网络, 以及跨学科的甚至是遍及全球的项目团队已经彻底改变了我们的工作环境。工作被当作一个项目来完成, 不再是以哪个部门为主来牵头完成, 而是以项目的需要来选择成员, 项目小组共同承担课题研究, 进行有关工作的问题讨论, 以期形成集体解决问题的方法。由此取得的成果则是:时间的节约、成本的降低、利润的增加、质量和企业信誉的提高。这种新型的项目团队关系, 要求必须通过先进的项目管理方式进行管理。然而, 最新的研究表明, 目前国内的IT项目中, 大约只有26%的IT项目成功地实现了范围、时间和成本目标的项目管理, 而剩余的74%的IT项目都有不同程度的失败。究其原因, 主要缘由是中国国内正规的项目管理研究起步比较晚, 项目管理知识的普及程度也比较低, 不可避免地导致现在大多数组织中的项目管理存在着这样或那样的问题。主要表现在:

项目管理控制体系不健全:大部分组织缺乏完整的项目管理体系, 相关的管理责权不够明晰, 项目管理漏洞较多, 组织缺乏协调性。

项目管理缺乏系统性:项目的运作主要体现为过程行为, 项目任务细分与计划性不够, 缺乏事前管理和进度管理, 造成项目进度延迟、资源浪费、质量低下或项目失败。

不重视项目整合管理:很多IT项目经理和技术经理都是技术人员出身, 主观上造成重技术轻管理, 不够注重项目的整合, 项目管理常常呈现单一性, 致使项目不能成功实施。

不重视项目领导技巧:从IT项目组成员个体而言, 其技术能力水平大都比较优秀, 但由于个性较强, 自我表现欲望突出, 一旦遇到项目经理、技术经理的领导技能较弱的情况, 项目团队建设时常出现如:项目中途合作各方散伙、项目经理不能得到组织高层领导及客户的有效支持等问题。

项目风险防范意识缺乏:很多组织的项目管理没有风险防范计划管理。项目的可行性分析常常流于形式;项目计划时不注重项目中的自然、经济、技术、管理与运作中的风险分析;项目实施中不重视风险的监控。

不注重项目经验总结:大多数组织往往比较注重项目实施过程中的控制管理, 缺乏项目收尾的项目总结过程, 不重视对项目结果的评价和分析, 缺乏对项目经验的知识共享。

二、项目管理是组织行为

(一) 项目管理及项目管理体系内涵

从项目管理理论上讲, 项目管理包含九大知识领域、五个过程。九大知识领域分别是:项目范围管理、时间管理、费用管理、质量管理、风险管理、人员管理、采购管理、沟通管理和项目整体管理。五大项目过程包括:项目启动过程、项目计划过程、项目执行过程、项目监控过程和项目收尾过程。项目管理的本质是“项目 (过程) ”和“管理 (过程) ”相结合的产物。由于不同类型项目过程的差异性很大, 通用的适合于所有项目的过程与相关的项目管理技术也只能是抽象的。在一个组织实际的项目管理体系建设中必须将这些项目管理技术与项目过程紧密结合, 这样的项目管理才具有实际指导意义。

在实际的项目运作组织过程中, 学会项目管理技术本身不是一件困难的事情, 困难的是如何将这些项目管理技术运用于组织的项目过程中。

从项目角度看项目管理和从组织高度看项目管理的结果是不同的。从项目角度看是如何管理好项目, 即要做好项目管理。从组织角度看是如何管理好一批项目, 则是应该如何建立一个项目管理体系。一个组织, 不仅仅要重视项目管理技术, 更应该注重组织项目管理体系的建设。

因此, 项目管理体系的建立涉及项目管理流程与规范、也涉及组织机构设置、角色与职责。项目管理体系就是项目过程、管理过程与组织结构相结合的产物。

(二) 项目管理是组织行为

有相当一部分人认为:项目的成功与失败是项目经理的事。而实际上则不然, 因为, 项目管理首先是一种组织行为而非个人行为, 项目过程活动充其量也只是一种团队行为。表1所示为不同组织中项目经理的权利情况。从中我们可以看出, 不同组织中项目经理的地位千差万别, 其所拥有的权利也有很大差别。对于一些企业和组织, 项目经理更多只是计划与执行, 项目范围、进度、质量与变更的决策权更多的掌握在上层。

因此, 对于一个企业和组织来说, 建立良好的项目管理体系才是至关重要的。

三、建立项目管理机制

应合理设置组织结构、明确项目管理相关人员的角色与职责。一个完整、健康的项目管理体系, 应建立在相对稳定的扁平化的组织结构基础之上, 在组织机构频繁更迭变化的情况下, 项目管理体系难以建立。

迄今为止, 在有关建立项目管理体系的组织结构的文献中, 其组织结构大都被阐述为扁平的、不分等级的项目管理型组织结构。许多专家研究的结论和验证的结果都表明:一个具有较高项目管理水平的组织, 其组织结构一般对其成员较少控制, 并尽量使工作最基层的单元向最终决策者靠近。只有这个组织是一个扁平的、不分等级的, 并在成员工作过程中只有最少的程式化控制时, 上述项目管理型组织的必要条件才能得以实现。基于这一理论根据, 笔者认为:在今后的组织重组中, 应首选考虑组织的最高决策层→项目管理层→项目组 (经理) 的组织结构, 最大限度地减少臃肿的中间管理环节。表2所示为项目管理型组织机构设置的一个例子。

(一) 最高决策层

IT企业要建立项目管理型组织结构, 必须由最高决策层中的成员担任项目管理体系的负责人。由于项目管理体系涉及组织的人力资源、成本、质量、流程优化等各方面问题, 因此, 需要在组织的高层领导下, 才能有足够权力保证各方面的工作得以顺利实施。

(二) 项目管理层

作为项目管理型组织, IT企业应建立在高层领导下的项目管理层, 项目管理层应履行以下职责:

1. 明确项目经理责权

项目管理的四大核心领域是:范围管理、时间管理、费用管理、质量管理。项目整体管理的目的是在不同过程的目的和方法之间做出折衷。如成本与进度、范围与进度、成本与质量。因此, 应明确和赋予项目经理适当的权利, 以保证项目经理在这几方面有控制能力, 宏观把握项目全局。

2. 建立奖惩分明的考核机制

在明确并赋予项目经理责权的前提下, IT企业应建立奖惩分明的考核评估机制。项目经理的最终利益是行使权力和承担责任的结果, 应体现责、权、利的相互统一。

3. 组织项目管理培训

IT企业要想按照项目管理的方法来进行项目管理, 摆脱固有的行为方式, 组织项目管理培训很关键。培训涉及的人员包括:高层经理、项目经理、项目组成员及相关职能管理人员, 内容涉及到项目管理知识, 企业项目管理规范的培训。培训在IT企业的项目管理中是一项长期和十分重要的工作, 可以举办项目经理和高级项目经理的资质认证培训, 建立起项目经理资质认可上岗制度。

(三) 项目过程改进组

作为项目管理型组织, IT企业应成立一个在高层领导下的项目过程改进组, 项目过程改进组的主要工作是:负责建立和完善企业的项目流程和相关规章制度, 完善和优化企业级的各种作业指导书、规范、标准。项目过程改进组应由组织内各部门、专业技术业务骨干组成, 负责持续改进企业的项目过程管理。由于项目过程改进组一般都是兼职岗位, 因此, 企业应在现行绩效考核和奖励分配制度上采取激励方法, 使项目过程改进组具有一定的动力, 并有效运作。

(四) 项目组

IT企业的项目组既可以隶属一个部门, 也可以跨部门。项目组的主要职责是负责执行企业的项目流程和相关规章制度, 根据项目管理手册, 按照项目的实际情况, 进行裁剪性选用, 形成项目组的项目规程, 并在实际运行过程中, 对项目管理手册提出改进和修改建议。

(五) 质量保证组 (SQA)

企业的质量保证组织, 作为企业的质量保障系统, 其主要职责是:按照项目管理质量管理要求, 结合ISO9000系列认证标准或CMMI认证标准, 负责监督、评价、分析企业的项目流程、相关规章制度和项目执行情况, 汇总、整理项目数据, 及时向企业高层管理者提供项目实施过程和项目结果的可视性数据, 确保项目质量结果。

四、组织过程优化及知识管理

企业组织机构确定后, 要尽快建立适合于IT行业类型的组织流程和制度。开发和维护一组便于使用的、基于IT信息技术的软件过程财富, 这些财富改进横跨各项目的过程性能, 并为企业项目管理的知识积累打下基础。它包括两部分 (如表3所示) :一是制定和维护企业项目管理组织流程的标准软件过程, 各项目组可以根据组织标准过程进行裁剪, 按照实际情况建立项目标准和规范;二是组织建立标准软件过程中的文档库和数据库, 它来源各个项目的数据和文档, 同时, 各项目也可以根据历史积累的数据作为项目的参考和估计。

(一) 项目管理中过程管理优化

1. 按照项目管理的方法建立组织级的标准WBS分解

WBS (工作任务分解) 是项目管理的一种重要方法, 它是以结果为导向的分析方法, 用于分析项目所涉及工作, 它是计划和管理项目的进度、成本和变更的基础。WBS常常表示为一个任务导向的活动家庭图, 通常是围绕项目产品或项目阶段来展开的, 有点像组织结构图, 人们可能通过它看到整个项目图景以及每一个主要的组成部分。它按照阶段、活动、任务的层次进行层层分解。

企业在实际项目管理过程的实践方法是:在高层领导下的项目过程改进组负责按企业的主要过程建立标准的WBS, 分为八大过程阶段和一个公共部分。八大过程包括立项、启动、需求、开发、测试、实施、验收、维护;公共部分主要包括贯穿项目始终的重要管理活动:需求管理、项目计划与跟踪、质量保证、配置管理、评审、风险管理等。如表4所示:

按照上述项目管理过程形成8张WBS责任矩阵表和1张公共活动责任矩阵表。每个WBS责任矩阵包括、阶段活动、任务、责任人、协助人。在责任矩阵表中, 特别明确项目的里程碑和客户需要参与的工作。如表5, 以需求分析的WBS为例, 协助人一栏中指出客户需要参与的工作。

各个项目可依据企业标准的WBS进行裁剪和细化, 对各项目制订计划, 形成有力的指导。各个项目制订WBS时, 把客户也作为责任角色矩阵中的相关人, 明确了客户的职责, 并邀请客户共同评审WBS, 审定项目的工作范围、进度、成本变更。

2. 在WBS分解的基础上建立全过程的作业指导书

与八大过程阶段及公共活动相对应, 企业需要编制不同的作业指导书。作业指导书指出了WBS最底层的每一项任务应该由谁做、如何做、达到什么样的标准, 有利于每一个员工按照统一的规范和要求进行工作, 并在作业指导书中给出相应工作的表单、模板和案例。即便是新进入企业的员工, 在进入企业后, 通过岗前培训, 学习企业的标准项目流程后, 都能很快了解和掌握项目实施过程中的各项工作。

那么, 如何编制好作业指导书?笔者认为可以从以下方面着手:

(1) 必须从项目管理结构上予以保障。前面也提到, 一定要建立在高层领导下的跨部门的项目过程改进组, 对项目管理体系的改进持续负责;

(2) 可采用和CMMI结合的方式, 建立各阶段的作业指导书。按企业战略目标、重点项目和重点产品的影响重要程度进行排序, 将所有需建立标准的过程划分为级别, 分批编制。同时, 对于一些关键过程域可采用CMMI的思想, 如CMMI提出的过程域目标和关键实践;

(3) 在建立了相关的项目管理流程和项目管理制度之后, 项目监控管理、技术管理就有了“法律”上的依据。这些“法律”在应用于实际的开发、实施、服务的管理工作中, 指导项目进行, 并接受有效性检验。检验的标准就是能否真正提高开发、实施、服务的质量、效率 (进度与成本) , 使项目不仅对客户, 而且对项目成员、企业领导都达到一个较好的满意度。对于经过检验无法达到上述效果的部分, 我们要进行持续的发现、完善、再实践、再检验、再发现、再完善。

(二) 量化管理, 数据积累优化

在企业项目管理的实践中, 涉及到需要量化管理的领域非常多, 从事前管理和事后管理的角度来分, 可以分为估算和度量两大类。估算是以实际统计调查资料为基础, 根据事物的联系及其发展规律, 间接地估算和预计有关事物的数量关系和变化前景;而度量则是依据特定的标准, 衡量当前的事物与标准之间的差异。

1. 项目估算

项目管理范围中, 有如下阶段需要应用估算技术:

(1) 项目范围估算

对项目预期的范围进行评估是项目的基础, 范围估算失误将给项目带来不可挽回的损失。

(2) 项目成本估算

估计完成项目各活动所需每种资源成本的近似值, 成本预算的过程是把估算的总成本分配到各个工作细目, 建立基准成本以衡量项目执行情况。可见成本估算的准确性直接决定成本的预算情况。

(3) 项目进度估算

项目管理的关键要素之一就是时间管理, 也即进度控制。准确地估算对制定项目计划、监督项目执行都有重要的意义。

(4) 项目风险估算

对风险识别不到, 或对风险可能造成的影响估计不足都可能导致项目失败, 因此对项目风险的量化估算更是至关重要。

2. 项目度量

定义项目、制定项目计划的时候需要进行项目估算, 而项目执行过程中的跟踪监督过程则离不开度量。良好的项目管理主要针对项目要素进行跟踪度量, 通过分析度量数字就可以及时发现项目进展中存在的问题, 从而有针对性地制定解决方案。通常需要度量的项目要素包括:

(1) 项目进度度量

对项目进度进行定期的跟踪度量, 及时发现当前进度与计划的偏差, 可以及时采取措施, 及时赶工或调整进度计划。

(2) 项目缺陷度量

项目的成败直接取决于客户满意度, 客户满意度是个难以量化的指标, 而项目成果———产品的缺陷密度直接影响着客户的满意程度。度量产品的缺陷密度, 可以有效地了解项目完成的质量。

(3) 项目工作量度量

工作量是衡量项目成本、人员工作情况的基础, 准确地度量出项目真实的工作量, 既可以掌握当前项目的情况, 对于今后估算其它项目数据也有重要意义。

(4) 人员生产率度量

人力资源是生产力中最为活跃和具有决定性影响的因素, 是项目中最为重要的资源之一, 掌握人员的生产能力对于项目管理中人员管理、资源管理都有重要的参考价值。

(5) 需求变更率

在项目中, 需求量直接决定项目的范围和工作量。

3. 建立企业级项目质量目标控制域

通过项目度量, 可以持续有效的进行数据积累, 制订各种数据的质量控制域, 并以此作为项目估算的基础, 如表6所示:建立企业级别的各种项目重要指标的控制上、下限。

如果再进一步, 可以按过程阶段对重要指标进行细分, 制订上、下限, 以表7进度变化率要求为例:

这样可以实现项目的量化管理, 并可逐步实现项目及工作人员的量化考核。

五、结论

为了加强项目执行过程中对所有项目的成本、进度、风险、收益等要素进行严格的动态监控, 有效分配组织的有限资源, 提高项目数据的准确性、及时性, 以保证项目获得最大的收益。IT企业在合适的时候, 有必要考虑选用项目管理系统来管理IT企业的各级各类项目, 以提高IT企业项目管理的效率和质量。

参考文献

[1]PMI.项目管理知识体系指南.2000

IT企业项目范围管理论文 篇6

作为以软件开发和实施为主的IT企业, 其项目管理的主要工作就是能够合理的利用企业研发、服务、销售和客户等各方资源, 在总体成本和工期的控制范围内, 能够按期或者提前完成项目建设, 满足甚至超越客户需求, 完成项目验收和回款。项目需求来源和最终结果好坏的裁判就是客户。所以客户作为项目最重要的干系人, 对软件项目的影响至关重要。项目管理中的客户管理包括客户甄别、客户需求管理、客户沟通、客户投诉管理等各个方面的内容。

二、软件项目客户

为了提高客户满意度, 现代的软件项目管理方法都向以客户为中心、客户驱动、客户参与的项目管理方式转移。所以我们必须认识到客户是软件项目成败的核心因素。正确的识别和定义软件项目的客户, 这是IT企业客户管理成功的基础。

比如, 某IT企业的软件开发类项目, 其项目目标是针对电信运营商的网络管理中心和运行维护部门的实际生产和管理需求, 需要解决他们的实际工作问题:自动化网络维护工作, 规范化工作流程管理等。因此, 该企业开发出来的产品, 能否解决客户的实际工作问题和困难, 最终用户是否满意, 项目直属领导是否满意, 能否解决实际的网络维护和保障问题, 给运营商创造了多少直接和间接的价值, 是否能落实客户领导的管理思路, 是判断该产品或项目是否成功的标尺。由于企业的产品需求来源是客户, 最终评判也是客户, 所以要做好软件项目的管理, 就要在需求调研、需求评审、验收软件项目流程的几个关键环节上明确具体客户和客户责任, 包括哪些是最终客户, 哪些客户负责提需求, 哪些是决策客户, 哪些是验收客户 (验收客户最好与提需求的客户是同一个团队或个人) 。同时客户也要明确相应的职责, 明确他们在项目中的地位和角色, 才能提高企业产品的针对性、准确性, 促进项目顺利进展, 促进项目验收和回款, 甚至衍生出新的或者下一期的项目。

所以, 在软件项目中, 需要明确以下四种客户角色:

1. 要明确最终使用部门和用户, 要去了解他们现有的工作方式, 要让他们知道项目的目标框架, 知道项目要解决他们的哪些困难, 但绝对不是全部困难, 这样可以较好的控制项目范围。

2. 要明确需求的提出者, 他或者他们要能够代表最终客户群体。提出产品需求的这类客户要具有一定的技术、业务能力和权威, 能够真正代表最终客户团队的意愿和想法, 最好有IT基础, 能够用IT语言描述问题和需求, 以利于双方的沟通、协作, 避免产生歧义。

3. 要明确做需求确认的中层领导, 他要把握方向。软件开发项目是解决实际生产或者管理问题, 同时也是领导系统建设的具体实现, 做需求确认的客户领导, 既要了解高层领导的系统建设要点和方向, 又要谙熟具体业务和生产管理实际。如果是这样的客户领导来把握和决策, 对企业软件开发项目的顺利进展作用非凡。

4. 要明确谁来对成品提意见, 谁来验收。项目验收环节, 是项目的收尾环节, 如果验收的人对项目初期的需求目标不了解, 会从态度和产品实际使用效果上对验收产生负面的影响, 对提供产品的企业关闭项目非常不利。根据实践总结, 由需求提出人和确认人来做项目的验收工作, 能够促进项目的顺利完成, 避免延期。

三、软件项目各阶段的客户管理

IT企业软件项目的实施较之于其他项目, 有其特点。也决定了该类企业的客户管理工作的独有特性。在通常情况下, 软件项目分为四个阶段, 分别是:需求识别阶段、制定方案阶段、实施阶段和结束阶段。

由于软件项目的各阶段具有不同的特点, 所以始终贯穿于项目各阶段的项目客户管理在不同的阶段实施的内容也有差异。

1. 需求识别阶段。

需求对于软件项目来说是一把双刃剑, 它既可能让一个项目成功, 也可能让该项目失败。对于项目组织而言, 该阶段非常重要, 需精确识别客户的真实需求。因此, 在该阶段, 项目经理应充分与客户沟通, 组织内其他与项目相关的成员也必须频繁活动, 通过一切渠道充分获取关于客户的所有信息。随后, 项目团队应对收集到的信息加以汇总并进行深层次、多角度的分析, 随时将不明确之处反馈于客户, 以期客户解答, 并要求客户审核需求分析书, 达到与客户的真实期望高度一致。同时, 项目方还要做好需求和需求的变更管理, 切实捕捉客户的真正需求, 避免开发资源的重复劳动, 缩短开发周期。因此, 我们需要在以下几方面做好管理工作:

(1) 需求沟通和描述的规范化。要用标准化的工作方式和工具与客户沟通并描述需求。一些规范的需求调研与沟通手段, 诸如随工、问卷、原型展示等, 都可以针对实际情况来使用, 其主要目的是更准确的把握客户需求。需求描述文档要针对不同的需求部分, 比如界面应用、处理逻辑等, 通过标准化的文档模板来描述和表现, 并和用户确认落实, 填平需求和功能之间的鸿沟, 同时给后端研发提供可管理的开发点介入。

在理解和认同客户需求方面, 我们需要把握以下几点:

(1) 能够站在客户的角度, 知道什么需求是对的, 什么需求的应用是更适合的; (2) 客户了解业务语言, 开发人员了解IT语言, 应用需求和开发之间的鸿沟, 有时需要产品经理去填平; (3) 提倡以草图或者可视信息化的方式和用户沟通, 确认界面、业务需求; (4) 要学会换位思考, 针对不同层面的客户提供最适合的操作界面, 用户觉得好用的才是真正好的软件产品; (5) 要抓住重点需求, 尤其是客户方领导关注的创新类和实用类需求。

(2) 需求变更的规范化管理。需求变更在软件开发类项目中是正常的也是可以理解的, 对需求变更需要做规范化的管理。一方面避免出现需求反复无止境的风险, 另一方面可以一步一个脚印的落实资源调配和项目实施。需求变更需要经过统一的接口人提出, 并且要用户需求的审核领导认可, 需求变更要定期而不是随时的提出, 我们要做好详细的记录, 让客户能够了解需求变更的实际情况, 了解客户自身和我们为之付出的成本代价。

2. 制定方案阶段。

该阶段项目团队的主要任务就是与客户一起制定一个以前期明确的需求、双方的资源、项目开始实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划, 从本阶段开始争取客户全面参与项目的管理, 需要双方共同考虑项目实施的具体计划落实和风险规避。

3. 实施项目阶段。

在该阶段, 软件项目团队应该与客户共同领导项目的实施。同时, 项目团队应实时评估客户满意度, 并通过持续改进提高客户满意度, 还应要求客户参加必要的培训, 以及在必要时检查项目产品。在出现客户的需求变更前, 应主动与客户沟通交流, 使客户充分了解项目的每个环节, 以及变更带来的影响, 减少需求变更。如果出现客户需求变更, 应与客户一起共同解决由变更引起的成本、进度、质量变化;如果与客户发生冲突, 应与客户坦诚相待, 以项目的最终目标和实现双方的利益最大化来权衡, 化解矛盾。在项目执行过程中, 促进双方人员的认识和了解, 记录客户的个性要求和特点, 建立合作伙伴关系。

想在项目实施和管理过程中, 获得客户的持续满意, 并最终达到双方的共同目标, 软件项目组织的相关岗位人员应从以下几方面加以关注和改进:

(1) 在获取项目过程中, 相关销售人员不要过分承诺。如果过分承诺, 会给后续的项目实施带来困难;一旦承诺没有兑现, 也会降低客户满意度, 影响今后合作。如果有附加承诺, 一定要让实施项目经理知晓并传达给项目组成员。

(2) 项目组要充分理解售前投标书或建议书的内容, 并在项目正式开始后就项目需求范围以文档化的形式与客户确认。

(3) 项目经理要切实履行自己的职责, 做好项目规划和人员管理, 并时刻铭记项目目标。

(4) 项目经理要定期与客户方相关负责人召开项目会议, 介绍项目进展情况以及项目过程中遇到的问题。

(5) 项目实施过程一定要规范, 质量控制要到位, 项目资料编写规范和齐全。

(6) 项目组成员要努力工作, 利用过硬的技术本领和规范化的实施, 赢得客户的信赖。

(7) 项目阶段成果要让客户参与评审并听取客户的意见和建议, 并在里程碑点交付客户。

(8) 销售人员要保持与客户的联系, 了解项目进展和问题, 在项目组和客户有意见分歧时起到缓冲的作用, 不要等到项目收款时才露面。

4. 结束项目阶段。

在项目结束阶段, 软件项目团队应组织项目经验或教训总结会, 邀请客户参加。评估客户满意度, 并加以全面分析, 请客户评估项目组织各个环节的工作, 提出建议和批评。在项目结束后, 仍需和客户保持联系, 建立长期合作关系。

四、客户沟通

客户沟通是软件项目客户管理中的“润滑剂”。在明确了项目中的各种角色和目标客户之后, 接下来需要在项目的各阶段, 做好贯穿项目始终的客户沟通工作。结合软件项目需求调研、方案评审、项目开发和结束验收等不同的阶段, 客户沟通会涉及到以下内容:

1. 和需求提出者 (或者最终用户) 的沟通。

要尽量深入他们的实际工作, 了解项目需要解决的实际问题的关键点。要使用不同的沟通手段和沟通工具来和用户沟通, 比如手绘界面或者图片界面、原型法来和客户沟通应用需求;比如用例图、流程图等方式来和客户沟通业务逻辑和流程需求等, 争取把IT语言和客户语言能够很好的在表述上达到一致, 切忌自以为是, 答非所问。

2. 和决策者或者客户领导的沟通。

项目产品基本定型和相对完整的产品需求, 需要经过客户领导的认可, 以确认项目建设思路和方向没有偏离, 利于投入更多的资源来细化和付诸开发实现。和客户领导要定期汇报沟通项目进展, 及时修正项目目标偏离, 争取客户更大力度的协调配合, 裁定项目范围需求边界。和客户领导的沟通要主动和及时, 要坚持到项目结束, 贯穿始终。每周的项目进展周报也是很好的沟通方式, 主动及时的汇报项目状态, 促进项目进展。

3. 和负责验收的客户的沟通。

验收客户最好就是需求提出者和最终客户。由于软件开发项目的产出是面向生产和管理实际的系统, 验收要考虑到功能、界面、性能、数据和用户容量等多个方面。为了实现分阶段建设, 成熟一步运用一步, 对于暂时有问题的部分, 需要和客户做详细的书面或面对面的沟通, 达成后期阶段实现的共识, 避免建设“大而全”且工期漫长的系统。

五、客户抱怨处理

客户对企业的抱怨, 主要来自于对我们软件产品方面和服务方面的期望落差, 要预防和处理好客户的抱怨, 需要从以下两个方面重点做工作:

1. 产品方面。

在产品功能方面, 我们要尽量使得我们的产品能够符合客户的业务实际、工作实际和管理实际, 能够符合用户的部门职责分工和工作流程, 能够给他们的实际工作带来创新性的改善和提升。用户在产品功能方面的抱怨, 很可能是我们提升产品价值的宝贵信息和财富。在产品可用性方面, 由于软件所运行的主机、存储, 既有数据量和用户使用量的不同, 又有软件产品的设计阶段和实际运行阶段的不同, 所以我们如果想做好的产品, 从设计、开发到现场部署只是完成了一半, 我们还需要密切跟踪现场的运行环境, 不断改进和优化我们的软件产品, 在容错性、运行效率等各个方面付出努力和代价, 才能使得我们的产品在用户的工作中扎根, 真正和客户形成长期的战略合作。

2. 服务方面。

服务方面的抱怨主要由专业技术和工作态度引起。客户针对这两个方面的抱怨或投诉, 需要我们能够具体甄别, 对症下药。我们可以通过建立“学习型组织”、通过实行“导师负责制”等具体方式提升团队的整体技术水平和实力。同时, 还要统一服务形象、标准化服务流程、加强员工工作礼仪培训等, 全面提升员工的自身修养和素质, 从而提升企业在客户现场的服务形象和公司形象。

在IT企业中, 无论是集团群组项目还是本省本地开发项目, 在项目管理的诸多环节中都需要以客户为指向, 切实做好客户管理, 为项目的成功运作打下坚实的基础。作为企业的各相关人员, 尤其是项目经理, 能够做好客户管理, 意味着项目已经成功了一半。

摘要:现代企业能否获得持续发展与竞争力, 很大程度上取决于其是否进行成功有效的客户管理。IT企业作为科技创新性企业, 主要业务是做软件项目;由于其软件项目的固有特点, 决定了该类企业的客户管理工作的独有特性。认清客户、积极有效的管理客户在IT企业项目管理中具有重要意义, 是IT企业竞争力的DNA。

关键词:项目管理,客户管理,客户角色

参考文献

IT企业项目范围管理论文 篇7

关键词:互联网,金融企业,IT项目,管理

在互联网高速发展的大数据信息时代背景下, 无论是银行、保险、证券、基金还是信托等行业, 都意识到金融业务对计算机网络和信息系统的依赖程度愈发强烈。云计算和大数据等新技术手段为金融企业发展带来了超出想象的空间和机会, 面临的信息化风险也愈来愈大, 使得金融企业IT项目管理在推动金融行业发展和创新方面的作用日益重要, 加强自身IT项目管理非常必要。

一、金融企业IT项目管理内涵与特征

金融业是计算能力应用大户, 互联网时代每个参与者都会面对海量庞大的数据处理。传统金融企业加强IT项目管理保障海量信息处理已是发展趋势, 不仅能为企业信息化建设提供保障, 也能为企业带来更多效益。

1. 金融企业IT项目管理的内涵。

项目管理指对利用项目管理理论方法和技术对项目资金、时间、人力等资源控制已达到预期目标的管理过程。IT项目管理指在互联网时代结合IT项目特点运用项目管理知识与技术方法实施全过程管理, 即对项目集成、范围、时间安排、成本、质量、人力资源、沟通、风险和采购管理等方面实施管控。金融企业IT项目管理指金融企业在互联网大数据信息时代, 借助计算机网络和信息系统新技术手段实施IT项目管理的行为与过程, 成为向金融企业整个业务提供业务管理与解决方案的平台, 这是高科技时代IT领域应用于金融企业项目管理实现资源调配业务变革的一种普遍形式。

2. 金融企业IT项目管理的特征。

金融企业实施IT项目管理已经成为信息时代帮助企业实现IT与金融业务整合及创新和提高效益的必要手段, 其特征主要包括五点:一是功能独特。金融企业IT项目管理运用现代信息技术确保企业各项业务的正常有序开展, 不仅是简单技术化管理, 更要满足客户多元化需求, 量身定制设计各类功能满足客户个性化需要。二是目的明确。信息社会, IT系统建设和管理的主要目的是为了提高效率满足客户与企业业务需要, 金融企业面对海量庞大数据处理更是如此。三是团队管理。随着金融企业业务日趋丰富, 依赖科技手段日益复杂, 项目管理难度不断提高, 而人成为整个IT项目管理流程的关键。项目团队能否有效解决各种问题, 人力成本能否控制得当, 都成为项目管理成败的关键。四是高风险性。面对大量客户与多样需求, 以及金融企业IT项目规模的日益增大, 项目设计工作调整和频繁改动引起的项目进度和费用变化使项目面临的风险与日俱增。五是及时性。信息时代要求金融企业信息要准确、及时和全面, IT项目管理要保障各环节信息畅通和智能化, 实现信息资源共享。

3. 金融企业IT项目管理的作用。

随着市场竞争加剧和技术进步的推动, IT项目管理已经逐渐融入到金融企业日常运行的各个方面, 这不仅是企业现代化建设的需要, 更是提升企业管理效率增加效益的重要途径。一是有利于企业扩大市场范围。金融业的快速发展, 使得金融企业不断拓展市场范围, 但往往受制于传统项目管理的时空限制。IT项目管理却能突破这些约束, 成为帮助金融企业在互联网时代将金融业务和服务覆盖范围扩展至全国甚至全世界的有力保障。二是有利于加强用户与企业间的交流。在互联网时代, 金融企业业务与服务更多的是24小时提供, 良好的IT项目管理能够有效控制交易成本, 进而保障用户与企业间的沟通与交流, 为双方提供极大便利。三是提高了企业运营的效率和服务客户的质量。对于金融企业来说, 良好的IT项目管理能够缩短信息交流时间并加速信息共享, 满足客户实时个性化需求, 同时可以提升资金流通速度和管理效率。

二、我国金融企业IT项目管理中存在的问题及原因

信息时代对金融互联网高速发展的大数据信息时代背景下, 在金融行业实施IT项目开发管理的过程中, 项目总是会遇到各种各样的困难和问题。

1. 认识不够, 重技术轻管理。

随着大数据、云计算在互联网中的不断应用推广, 金融企业更加关心新技术、新产品和新项目的开发, 忽视IT项目的日常管理与运营。

2. 机制不够, 重形式轻内涵。

一是金融企业IT项目管理对客户描述过于简单, 无法了解客户详尽需求, 缺乏灵活应对机制, 可能导致项目无法开展。二是仅注重内部应急机制建设, 缺乏大范围沟通应急机制。金融企业IT项目大多是全国性大型集中应用系统, 事故发生时只依靠单个金融机构自身力量往往无法应对。如果金融企业IT项目应急机制只考虑单位内部管理, 这种缺乏专业性的管理就无法保证金融业务的连续性, 进而无法为金融企业提供有效预测、预警。

3. 人才不够, 重个体轻团队。

在云计算和大数据为基础的互联网高信息时代, 金融业务对新技术的依赖程度愈发强烈, 金融企业对金融IT人才的引进给予了高度重视, 但金融IT人员流失已经成为很多金融企业面对的严重问题。这种从业人员快速更迭流动, 给IT项目管理带来了较大风险, 也给金融企业运营带来了不确定性。

4. 原因分析。

金融企业IT项目管理中存在的问题多种多样, 其原因也是各异。IT技术日新月异, 金融市场蓬勃发展, 客户需求变化多端, 人员流动四面八方, 众多因素使得金融企业IT项目管理变得愈发复杂。一是我国项目管理发展晚于欧美发达国家, 其理论知识系统成熟不够, 相关管理制度完善不足, 使得实际企业项目管理差异较大, 无法适应快速变化的发展形势, 特别是无法适应金融企业发展新需要, 需要重新认识现代IT项目和传统项目管理的差异性。二是在风险控制和团队管理方面存在问题。因为人是企业最重要的资产, 需求因人而异, 因而对每个项目IT人才的管理方法也不尽不同。如果无法适应新形势和新要求, 忽略团队文化、团队理念建设导致人才流失, 会成为IT项目管理面临风险的重要原因。因为金融企业IT项目的系统性极强, 任何管理细节不清晰, 都可能给整个企业带来严重的不利后果。

三、我国金融企业IT项目管理的改进策略

1. 加强团队建设。

IT项目团队管理对金融企业依托信息技术加速发展愈发重要, 其成功与否和项目团队建设息息相关。因而首先要采取IT项目团队管理优化措施, 依托企业文化建设不断优化团队管理理念, 选好IT项目经理并依托培训不断提升团队整体水平和能力。进一步加强IT项目团队沟通和权责明晰化, 增强团队凝聚力和向心力, 才能处理好IT人员流动问题。

2. 重视风险管控。

风险管控不仅是金融企业IT项目管理的一项重要内容, 更是金融企业金融信息化建设的一项重要工作。针对风险管理意识与制度缺乏、项目计划性不足和风险意识缺乏等问题, 应首先明确项目管理的风险管理人, 建立IT项目风险管理计划和应急协作机制, 引入信息系统工程监理, 以问题管理为导向加强技术人员相关培训。

3. 推进全面绩效管理。

上一篇:服药方法下一篇:加权朴素贝叶斯分类论文