第二十三章 案例分析

第二十三章 案例分析

 一、可行性研究问题

1、主要内容

技术可行性分析、经济可行性分析、运行环境可行性分析、 其他方面可行性分析，如法律、社会道德。

2、可能产生的原因

没有进行系统的可行性分析、调研不充分，不了解技术是否成熟、没有调研国家政策或法律法规是否允许、

3、可能遇到的风险

技术风向、政策风险、市场风险。

二、项目整体管理

整体管理负责管理项目的需求、范围、进度、成本、质量、人力资源、沟、风险和采购。

大家可以根据每个项目的实际情况看看案例中具体说的是哪方面，然后结合具体的去写；有如下几个过程：

1、项目启动

制定项目章程，正式授权项目或立项阶段的开始。

2、制定初步的项目范围说明书

编制一个初步的项目范围说明书，概要地描述项目的范围。

3、制定项目管理计划

将确定、编写、集成以及集成所有分计划，以形成整体项目管理计划。

4、指导和管理项目的执行

执行在项目管理计划中所定义的工作以达到项目的目标。

5、监督和控制项目：

监督和控制项目的启动、计划、执行和收尾过程，以达到项目管理计划所定义的目标。

6、整体变更控制：评审所有的变更请求，批准变更，控制可交付成果和组织的过程资产。

7、项目收尾：完成项目过程中的所有活动，以正式结束一个项目或项目阶段。

 

大家可以从以下几个方面去考虑：

1、建立企业级的项目管理体系和工作规范，管理上不乱。

2、明确可交付物。

3、培训学习项目管理知识，提高管理能力

4、做好经验的总结，做好各项计划。

5、做好整体管理，项目过程。

6、加强变更管理与控制，建立变更流程与体系。

7、要有项目启动-可行性分析

8、要制定项目章程。

其中项目整体实施过程控制中经常出现以下问题：

1、在项目实施过程中没有及时传递绩效报告给客户，因此客户对项目进展和质量状况不了解。

2、没有让客户即使对阶段交付成果签字确认。

3、由于没有售后服务的承诺，客户担心没有后续的保证。

4、合作气氛不良，客户担心没有后续的保证

针对以上问题我们可以采取下面的一些措施：

1、就项目验收标准和客户达成共识，确定哪些主要工作完成就可以验收通过。

2、就验收的步骤方法和客户达成共识。

3、就项目已经完成的程度让客户确认，例如出具系统使用报告，让客户签字确认。

4、向客户提出明确的服务承诺。 使客户没有后顾之忧。

我们可以从项目中吸取以下的经验和教训：

1、项目合同中要规定项目成果的证实验收标准，验收步骤，验收流程和运营维护承诺等内容。

2、加强项目执行过程的控制：加强变更控制、加强项目沟通管理、加强计划执行的控制。

3、项目经理还应注重和客户交往的技巧，努力促成双方的良好合作氛围。

当然整体管理还可能会和配置管理、变更管理一起出题。

配置管理

1、可能出现的问题

1）缺乏项目整体管理和权衡 

2）缺乏变更控制规程

3）缺乏项目干系人沟通

4）缺乏配置管理

5）缺乏整体版本管理

6）缺乏各种单元测试和集成测试。

2、配置管理的主要内容

1）制定配置管理计划

2）配置项目识别

3）建立配置管理系统

4）基线化

5）建立配置库

6）变更控制

7）配置状态统计

8）配置审计。

3、我们采用的应对措施

1）针对目前系统建立基线

2）梳理变更脉络，确定统一的最终需求和设计

3）梳理配置项及其历史版本

4）对照最终需求和设计逐项分析现有配置项及历史版本的符合情况

5）根据分析结果由干系人确定整体变更计划并实施

6）加强单元接口测试与系统的集成测试。

三、范围管理

一、范围管理的过程

1）编制范围管理计划：制定一个项目范围管理计划，以规定如何定义、检验、控制范围，以及如何创建与定义工作分解结构。

2、范围定义：制定项目和产品详细的过程。

3、创建工作分解结构：将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。 工作分解结构WBS是一种以结果为导向的分析方法，用于分析项目所涉及的工作，所有这些工作构成项目的整个工作范围。WBS为项目进度管理、成本管理和范围变更提供了基础。

4）范围确认：正式验收项目已完成的可交付成果的过程。

5）范围控制：监督项目和产品的范围状态、管理范围基准变更的过程。

二、范围中可能问题

1、没有挖掘出全部隐性需求，缺乏精确的范围定义。

2、没有有效的范围管理，造成二次变更。

3、没有对风险进行有效管理。

4、没有对质量进行有效控制。

5、对范围控制不足

6、没有和客户进行需求确认。

三、范围管理应对措施。

1、对项目范围进行清晰定义，并根据定义对工作分解，制定WBS.

2、对项目进行合理估算，对工作量有量化的把握。

3、对项目范围进行有效控制。

4、重新定义项目范围必须得到高层和客户的确认。

5、进行沟通管理，协调多个项目干系人之间的矛盾。

其中范围范围中最主要和最可能的问题就是需求管理没有做好！关于需求答题要点

1、需求定义：形成一上清楚的、完整的、一致的可验收测试的用于产品的技术性能需求说明书；

2、需求追溯：包括正向追溯和反向追溯。 通过实施追溯将会使项目在审核、变更影响分析、维护、跟踪、再设计、重用、减小风险、测试等方面受益。即时更新需求状态，以保证系统或产品的完整性和准确性。

3、需求状态跟踪：

周期性报告需求项的各状态类别以及各状态类别在整个需求中的所占的百分比来改进项目的监控工作。状态包括：已建立、已批准、已实现、已验证、已删除、已取消。

4、需求变更：走正式的需求变更流程。

以上是必须掌握的内容，当然我们还需要掌握以下内容

1、质量控制和核实范围的区别和联系

范围核实与质量控制的不同之处在于，范围核实主要关注对可交付成果的验收，而质量控制则则主要关注可交付成果是否正确以及是否满足质量要求。质量控制通常先于范围核实进行，但二者也可同时进行。  与质量控制不同，核实范围所关心的是接受而不是纠正工作成果。 也就是说：质量控制（确认可交付成果是否正确并满足质量要求）  核实范围（正式验收项目已完成的可交付成果） 项目收尾（最终的产品、服务）

2、范围进行控制

对项目范围进行控制，就必须确保所有请求的变更、推荐的纠正措施和预防措施都经过实施整体变更控制过程的处理。 在变更实际发生时，也要采用范围控制过程来些变更。 要防止范围蔓延和镀金的发生。  对范围进行变更时，要以工作分解结构、项目进展报告、变更请求和范围管理计划为依据。

进行范围变更控制必须经过范围变更控制系统。

3、WBS表示形式

1）分级的树形结构，类似于组织结构图。 树形结构图的WBS层次清晰，非常直观，结构性强，但不容易修改；大型项目不容易表示项目全景，需分解为多个子项目。

2）列表形式，类似于书籍的分级目录。 能反映项目的所有工作要素，直观性差，用在大型项目中。

4、分解WBS结构的方法至少有如下三种（掌握）

1）使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层。

2）把项目重要的可交付物作为分解的第一层；

3）把子项目安排在第一层，再分解子项目的WBS.

5、分解工作结构应把握如下原则（必须掌握）

1）在各层次上保持项目的完整性，避免遗漏必要的组成部分。

2）一个工作单元只能从属于某个上层单元，避免交叉从属。

3）相同层次的工作单元应有相同性质。

4）工作单元应能分开不同的责任者和不同工作内容。

5）便于项目管理进行计划和控制的管理需要。

6）最低层工作应该具有可比性，是可管理的，可定量检查的。

7）应包括项目管理工作（因为管理是项目具体工作的一部分），包括分包出去的工作。

8）WBS的最低层次的工作单元是工作包。 一个项目的WBS是否分解到工作包。

四、进度管理

1、进度管理的6个过程

1）活动定义：

把工作包进一步分解为活动，方便进度管理，方法有分解、模板、专家判断等，主要输出是“项目活动清单”

2）活动排序：即工作排序，确定各活动之间的依赖关系，形成文档。工具和技术主要有前导图法、箭线图法、进度计划网络模板、确定依赖关系等，主要输出是项目计划网强图；

3）活动资源估计：需要什么资源（人力、设备、原料），分别要多少，何时用。主要方法有：专家判断、替换方案、公开的估算数据、估算软件、自下而上的估算等等；

4）活动历时估算：关系到各事项、各工作网络时间的计算和完成整个项目任务所需要的总时间，主要方法有：专家判断、类比估算、三点估算、预算时间、最大活动历时等；

5）制定进度计划：决定活动的开始和完成日期。 方法有关键路径法、进度压缩、资源平衡、所采用的日历、超前和滞后、计划评审技术等等。

6）进度控制：包括进度报告、进度变更控制、绩效测量、项目管理软件、偏差分析、计划比较甘特图等。

2、常见考点：关键路径法  完工概率。

工作量及工期计算；制定网络图；甘特图、里程碑图、网络图的区别；PERT；

如何优化工期；跟踪项目进度的方法。

关键路径法：上下午都可能考核，涉及到：ES、EF、LS、LF计算；关键路径计算、总时差、自由时差。

完工概率：考核基础是三点估算法，标准差，在此基础上进行延伸，考核活动完成的概率，要求掌握标准差的公式以及对应的概率。 应对的关键方法是“面积法”，通过“面积法”解百题。

3、进度管理可能出现的问题以及解决办法：

1）团队成员没有及早参与，需求分析耗时长，要早期参与拉项目。

2）经验不足，进度计划制定不准，采取有效的历时估算方法和网络计划技术，制定进度计划。

3）考虑项目期间特定时期会对进度产生影响。

4）增加人手，聘请更有经验的人员，找兼职人员

5）加班   6）并行   7）重新估算后面的工期

8）加强沟通，减少变更   9）加强控制，避免返工。

10）外包   11）加强沟通，先完成关键需求

12）增加资源有时可能压缩工期有限

13）关注关键路径，在关键路径上加资源，有效果。

14）关注里程碑

15）加强进度与成本、风险、质量等知识点的协调。

4、遇到如何缩短项目工作以保证项目整体进度的方法：

1）向公司申请资源，或使用经验丰富的员工；

2）优化网络图，重排活动之间的顺序，压缩关键路径长度；

3）临时加班（赶工），尽可能补救耽误的时间或提升资源的利用效率；

4）将部分阶段的工作改为并行、内部流程优化；

5）变更原来的进度计划。 根据前阶段的绩效，对后续工作重新估计，修订计划，并得到项目干系人同意；

6）加强同项目干系人的沟通；

7）加强交付物、项目阶段及时检查和控制，避免后期出现返工。

8）尽可能调配非关键路径上的资源用于关键路径上的任务；

9）优化外包、采购等环节并全程监控。

进度压缩的主要工具：赶工和快速跟进，当然这2个工具和抚摩也有一些需要注意的事项；

赶工：只适用于那些通过增加资源就能缩短持续时间的活动。赶工并非总是切实可行的，它可能导致风险和成本的增加。 为了评价一个项目赶工的意义，项目经理首先要计算生个能够赶工的关键活动的成本和时间的斜率。 如果斜率一直不变的话，那么赶工就没有意义。 所以赶工并不一定会增加项目进度，不能进行盲目的赶工。

快速跟进把正常情况下按顺序执行的活动或阶段并行执行。快速跟进可能造成返工和风险增加。 它只适用于能够通过并行活动来缩短工期的情况。

其中资源对项目进度影响如下：

1）一般情况下，项目活动历时与投入的资源数量成反比，即投入的资源数量越多，活动历时越短。 但是，当针对某一活动的资源投入数量达到一定规模时，再增加资源的投入不会进一步缩短项目活动历时，也就是资源投入递减规律。

2）非关键路径上的活动历时只对项目产生较小的影响或不产生影响，而关键路径上活动历时的延误，则会直接影响到项目工期。 因此第当缩短项目工期时应对首先考虑在关键路径活动上增加资源。

5、活动历时估算的技术和工具有：

专家判断、类比估算、参数估算、三点估算。这几个需要重点理解掌握。

6、活动时间的期望=（乐观+4个正常+悲观）/6

活动时间的标准差=（悲观-乐观）/6

 

五、成本管理

1、成本管理过程：

1）制定成本管理计划：制定了项目成本结构、估算、预算和控制的标准。

2）成本估算：编制完成项目活动所需资源的大致成本。

3）成本预算：合计各个活动或工作包的估算成本，以建立成本基准。

4）成本控制：影响造成成本偏差的因素，控制项目预算的变更。

2、常见考点：挣值分析、完工预测

记住在个参数，4个指标以及公式即可。  PV   EV   AC   CV   SV   CPI   SPI.

需要深入考核PV、EV、AC的理解，从一段文字描述中计算出PV、EV、AC，对概念没有掌握者，很难拿全分。

完工预测：难点。 关键在于掌握典型偏差和非典型偏差，早期记公式，能够判断典型或非典型偏差老大哥解题，现在考核对公式的理解，因此，要求能够推到出典型偏差公式，并能够充分理解。

完成尚需估算ETC、完成时估算EAC、项目总预算BAC=完工时的PV总和

ETC有2个计算公式，必须掌握

非典型的偏差计算  ETC(当前的偏差被视为一种特例，并且项目团队认为将来不会发生类似的偏差，需要纠偏)

ETC=BAC-截止一目前的累加EV

 

典型的偏差计算ETC(当前出现的偏差被视为具有典型性，可以代表未来的偏差)

ETC=(BAC-截止到目前累加EV)/累加CPI

EAC=AC+ETC

要熟悉挣值分析法来分析时间/进度/成本偏差，会画图和看图分析：

PV、EV、AC、SC、EC、SPI、CPI

PV：预算值

EV：已完成任务的预算值 。

AC:已完成任务的实际值；

SV=EV-PV     SPI=EV/PV   进度偏差；

CV=EV-AC    CPI=EV/AC    成本偏差；

 

3、常见问题

1）各种成本估算方法、工具

2）资源平衡

3）成本与范围、进度等约束之间的关系

4）综合考虑影响成本的因素

管理水平、技术水平、组织形式。

5）对共用资源的可用性进行分析，引入资源日历。

6）成本控制方法==不可预见费的控制、变更的控制、设计标准的控制、采购合同的控制、支付进度的控制。

7）综合起来，信息系统的项目成本估算的困难主要包括以下方面

》需求信息的复杂性

》开发技术与工具的不断变化

》缺乏类似的项目估算数据可供参考。

》缺乏专业和丰富有经验的人才。

》信息系统研发人员技术能力的差异 。

》管理层压力与误解在对项目成本估算时，应该避免以下的常见错误

1）草率的成本估算  2）在项目范围尚未确定时就进行成本估算。

3）过于乐观或保守的估算。

 

4、项目成本失控的原因

项目成本控制工作是在项目实施过程中，通过项目成本管理尽量使项目实际发生的成本控制在预算范围之内。 如果项目建设的实际成本远远超出批准的投资预算，就表明出现成本失控。 发生成本失控的原因主要有以下几点：

1）对工程项目认识不足

》对信息系统工程成本控制的特点认识不足，对难度估计不足。

》工程项目的规模不合理，一个大而全的项目往往导致工期很长，而且导致工程实施的技术难度太高，导致技术人员的投入方面跟不上工程建设的需要，并且单位各部门对信息系统工程的接受能力和观念的转变跟不上信息系统建设的需要。

》工程项目的设计人员和实施人员缺乏成本意识，导致项目的设计不满足成本控制的要求。

》对项目成本的使用缺乏责任感，随意开支，铺张浪费。

2）组织制度不健全

》制度不完善

》责任不落实：缺乏成本控制的责任感，在项目各个阶段和工作包没有落实具体的成本控制人员

》承建单位项目经理中没有明确的投资分工，导致对投资控制的领导督查不力。

3）方法问题

》缺乏用于项目投资控制所需要的有关报表及数据处理的方法

》缺乏系统的成本控制程序和明确的具体要求，在项目进展不同阶段对成本控制任务的要求不明确，在项目进展的整个过程中缺乏连贯性的控制

》缺乏科学、严格、明确且完整的成本控制方法和工作制度。

》缺乏对计算辅助投资控制程序的利用。

》缺乏对计划值与实际值进行动态的比较分析，并及时提供各种需要的状态报告及经验总结。

4、技术的制约

》由于进行项目成本估算发生在工程项目建设的早期阶段，对项目相关信息了解不深，项目规划设计不够完善，不能满足成本估算的需求。

》采用的项目成本估算方法不恰当，当项目的实际情况不符，工与所得到的项目资料不符。

》项目成本计算的数据不准确或有漏项，从而导致计算成本偏低。

》设计者未对设计方案进行优化，导致项目设计方突破项目成本目标。

》物资或设备价格的上涨，大大超过预期的浮动范围

》项目规划和设计方面的变更引起相关成本的增加

》对工程实施中可能遇见的风险估计不足，导致实施成本大量增加。

5、估算成本的工具和技术包括：专家判断、类比估算（其实是专家判断的一种）、参数估算、自下而上估算（也就是说从底层的工作包成本估算开始，不断汇总为项目的总成本）、三点估算等。

 

六、质量管理

 1、质量管理的过程

1）编制质量计划

识别与项目相关的质量标准以及确定如何满足这些标准，确定需要对哪些过程和工作产品进行质量管理。

2）做好质量保证

所有的有计划地、系统地为保证项目能够满足相关的质量标准而建立的活动，主要是确保过程质量。

3）做好质量控制：

采取措施，监督项目的具体实施结果是否符合相关的项目质量标准，并确定消除产品不良结果的原因。

2、项目质量管理经常遇到的问题

1)项目交付成果本身有缺陷，例如不稳定或功能不完美。

2）项目交付成果没有实现预定的功能需求。

3）项目在需求分析阶段对用户的需求分析提炼精度不够，没有挖掘出部分重要的需求。

4）随着时间和环境的变化，客户产生了新的需求。

5）由于文档的不完备，一方面导致用户不能解决一些使用问题，另一方面还使得维护工作的效率提不高。

6）没有为项目制定一个可行的项目质量管理计划并积极地实施。

7）仅向用户提交测试报告而没有提交全面质量管理进展情况报告（或实施报告）

，沟通方式单一（或不全面），容易误导客户，容易导致客户不必要的担心。

8）没有制定可行的质量管理计划并积极实施。

9）没有全面的质量管理进展情况报告；

10）沟通方式单一或不全面，容易误导用户，致用户不必要的担心。

3、针对以上情况我们可以采取以下相应的措施保证项目的质量

1）首先执行项目的质量管理计划

2）采用质量保证的工具和技术（如编制质量计划时所采用的工作和技术、质量审计、质量控制、过程分析与基准分析）等等。

3）提出相应的质量整改措施，如建议的纠正措施，对项目计划的可能的更新，对组织资产可能的更新，变更请求。

4、质量控制应该关注以下内容

1）对维护工作进行质量控制，做好相关文档工作。

2在有条件情况下，开始对已交付系统进行文档建设，尤其是用户手册的建设工作。

3）建立组织级的质量管理体系和相关的标准及规范，取得高层领导的支持和信任，开展整体质量控制观念的培养，在以后工作中实施严格的质量控制工作。

5、项目质量管理过程可以从以下4个方面进行把握

1）确立质量标准体系  2）对项目实施进行质量监控

3）将实际与标准对照    4）纠偏纠错

6、全面质量管理有 4个核心的特征：

即全员参加的质量管理、全过程的质量管理、全方法的质量管理和全面结果的质量管理。

7、质量保证和质量控制的目的和区别

质量保证的目的是保证项目实施是按照组织的质量政策来实施的，是按照质量管理计划来进行的。质量保证主要针对的是过程，也就是保证我们过程是正确的，这个过程是通过质量审计、过程分析来达到目的。

而质量控制针对的是结果，也就是通过质量控制来确认我们的可交付物是否符合质量要求。

8、质量控制工具：

测试、检查、控制图、因果图（石川图）、帕累托图（排列图或主次因素分析图）、统计抽样、流程图、趋势分析。

9、软件质量从六个方面来衡量：性能、可靠性、可用性、安全性、可修改性、功能性。

10、质量控制与质量保证的区别与联系：

1）质量计划是质量控制和质量保证的共同依据。

2）达到质量要求是质量控制和质量保证的共同目的。

3）质量保证的输出是下一阶段质量控制的输入。

4）一定时间内质量控制的结果也是质量保证的质量审计对象，质量保证的成果又可以指导下一阶段的质量工作，包括质量控制和质量改进。

5）质量保证一般是每隔一定时间如阶段末进行的，主要通过系统的质量审计来保证项目的质量（或质量保证是按质量管理计划正确的去做）

6）质量控制是实时监控项目的具体结果，以判断他们是否符合项目的相关标准，制定有效方案，以消除产生质量问题的原因（或质量控制检查是否做的正确并进行纠正）

11、如何实施质量保证

执行质量管理计划；采用质量保证的工具和技术；提出相应的质量整改措施。

12、我们如何控制产品的质量

1）强有力的领导

2）建立组织级项目管理体系

3）建立组织级质量管理体系

4）建立项目级激励制度

5）理解质量成本

6）提高项目文档质量（项目文档应有针对性、精确性、清晰性、完整性、灵活性、可追溯性）

7）发展和遵从成熟模型

13、文档的种类和作用

1）用户文档

2)开发文档

3）管理文档

质量管理强调的是全面质量管理，我们要记住质量是规划出来的，而不是检查和测试出来的。 任何通过时候增加测试和检查，而后修改问题的方式来增加质量的方法是错误的。

 

七、人力资源管理

1、人力资源管理的主要过程

1）组织计划编制：识别项目中的角色（管理类、技术类、支持类）、职责、能力和汇报关系，识别项目组成员所需要的技能培训，制定人力资源配备管理计划；

2）组建项目团队：招募项目所需的人力资源

3）项目团队建设：提高个人和团队的技能以改善项目绩效。

4）管理项目团队：跟踪个人和团队的绩效、提供反馈、解决问题、管理冲突，并协助变更以提高项目绩效。

2、经常出现的问题

1）招募不到合适的项目成员

2）团队的组成人员尽管能力强，但很难合作。

3）团队的气氛不积极，士气低落。

4）团队的任务和职责分配不清楚；

5）人员流动过于频繁。

3、问题产生原因：

1）未建立人力资源获取和培养的稳定机制

2）未完整识别项目所需要的人力资源的种类、数量和任职条件。

3）未建立一个能充分有效发挥能力的团队；

4）未清楚的将工作职责分配到个人或人力单元；

4、解决问题要采取的措施

1）事先制定岗位的要求、职责和选人的标准，并选择合适的人选。

2）对工作进行全面估算，如果有人负荷过重，需要找人代替，解决负载平衡问题。

3）事前沟通并对相应人员明确要求，明确角色的轻重缓急，促使尽快转换角色。

4）上级应该注意平时对人员的培养和监控。

5）采用激励理论与实际制度相一致。

6）加强团队建设的活动

7）形成共同的行为准则

8）争取公司认可的奖励机制，认可成员的工作。

9）绩效考核

10）聘掌握技能的人员加入项目团队。

11）做好人员风险分析，制定相应的计划与措施。

12）采用项目管理系统，提高工作效率。

5、组织计划编制采用的工具和技术：OBS和RAM

组织分析结构OBS则按照组织现有的部门、单元或团队排列，并在每个部门下列出项目活动或工作包。 

运营部门（如信息技术部或采购部）只需找到其所在的OBS位置，就能看到自己的全部项目职责。

资源分解结构是另一种层级图，按照资源类别对项目进行分解。

在人力资源计划编制过程中可以采用责任分配矩阵（RAM）显示工作包或活动与项目团队成员之间的联系。 RAM的一例子是RACI(R=执行   A=负责   C=咨询 I=知情)

6、项目团队的四个阶段：形成期-震荡期-正规期-表现期，当团队中有新的成员加入时，将会重新从形成阶段开始。

7、项目团队建设的几个理论：

1）马洛斯需求理论

生理需要：食物和生活必需品。

安全需要：失业、医疗、养老保障、人身、财产保障。

社交需要：与他人的关系，友情、爱情等，归属的需要。

尊重的需要：被认可的需要。

自我实现的需要：实现能力提高，实现理想和抱负。

2）双因素理论：激励因素、卫生因素。

3）麦克格勒尔的X理论和Y理论

X理论：假定人们是一个消极的工作形态，更喜欢经常的指导，只能用马洛斯低层次需求（生理安全）进行激励。

Y理论:  假设人们是一个积极的工作形态，受马洛斯高层次需求（自尊与自我实现）的激励。

8、成功团队的标志及特点：

1）团队的目标明确，成员清楚自己工作对目标的贡献。

2）团队的组织结构清晰，岗位明确。

3）有成文或习惯的工作流程和方法，而且流程简明有效。

4）项目经理对团队成员有明确的考核和评价标准

5）组织纪律性强

6）互相信任，善于总结和学习。

9、管理项目团队的工具和技术：包括观察和交谈、项目绩效评估、冲突管理、问题日志。

10、冲突产生 原因：项目的高压环境、责任模糊、多个上级的存在、新科技的流行。

冲突解决的方法：问题解决、妥协（求同存异、撤退、强迫）

常见的冲突解决方法包括：

撤退、回避：从实际或潜在冲突中退出。

缓解、包容：求同存异，强调一致而非差异。

妥协：都做出让步，是LOSE-LOSE的解决方法。

强制：强制解决冲突，是WLIN-LOSE的解决方法。

合作：冲突双方合作解决问题。

面对/解决问题：PMI推崇的WIN-WIN的解决问题方法。

新技术风险解决方法：培训、自制一外购分析、招聘掌握该新技术的人员、风险分析与防范。

11、如何组织建团队成员：

1）事先分派   2）谈判   3)采购   4）虚拟团队。

12、概述典型的项目集团团队的角色构成，叙述在组建项目团队，建设项目团队和管理项目团队所需的活动？

一）针对选定的项目，根据项目的特点，需要的角色如下：

1、管理类岗位：项目经理

2、工程类岗位：架构师、分析师、网络工程师、软件工程师、测试工程师、和实施人员。

3、行业专家

4、支援类：文档管理员、秘书

二）1、组建项目团队，明确责任，制定责任分配矩阵，制定组织结构图和职位描述。2、建立项目团队  提高项目团队的个人绩效   提高项目团队个人之间的信任感和凝聚力，已通过更好的合作提高工作效率。

3、管理项目团队

跟踪个人的团队的执行情况、提供反馈。

协调变更，以提高项目的绩效，保证项目的进度。

项目管理团队还必须注意团队的行为，管理冲突，解决问题评估团队成员的绩效。

八、沟通管理

1、沟通管理过程

1）沟通计划编制：确定项目干系人的信息和沟通需求；哪些人是项目干系人，他们对于该项目的收益水平和影响 程度如何，谁需要什么样的信息，何时需要，以及应怎样分发给他们。

2）信息分发：以合适的方式及时向项目干系人提供所需信息。

3）绩效报告：收集并分发有关项目绩效的信息，包括状态报告、进展报告和预测。

4）项目干系人管理：对项目沟通进行管理，以满足信息需求者的需求并解决项目干系人之间的问题。

2、沟通管理可能存在的问题

1）内部管理有问题，监管不力。

2）没有或极少与客户进行直接沟通。

3）现场管理制度执行不力。

4）总包与分包责任不清。

5）客户获取的信息失真，总包推卸责任。

6）客户自己本身的问题，包括资金、管理水平等等。

7）可监理工作没到位。

8）缺乏对项目组织成员的沟通需求和沟通风格的分析。

9）缺乏会议规程，会议目的，议程、职责不清，缺乏控制，导致会议效率低下，缺乏效果

10）会以没有产生记录

11）会以没有引发相应的活动。

12）沟通方式单一

13）没有进行冲突管理

3、面对沟通管理的问题我们采取的措施

1）做好干系人分析

2）发挥总包的牵头和监理的协调作用。

3）对共用资源可用性进行分析，引入资源日历。

4）解决冲突

5）建立健全项目管理制度并监管其执行。

6）采用项目管理信息系统。

可能还会出现以下问题和方式

1、缺乏沟通，合作氛围不够。

2、及时信息分发，加强沟通，让客户了解项目具体情况。

3、注重沟通技巧，建立融洽的合作气氛。

4、没有团队成员的沟通需求和沟通风格进行分析。

5、没有开一个高效的会。

6、沟通方式单一

7、没有冲突管理

8、开高效会议的做法。

9、分析成员的沟通风格，从而采用相应的沟通方式。

10、多种沟通方式   11、采用一些沟通模板   12、加强冲突管理

13、加强冲突管理  14、多供应商的沟通

15、解决冲突，包括干系人对项目期望之间的冲突、资源冲突 。

16、做好干系人分析，调研各集成商的沟通需求。

17、周期性的沟通。

18、突发事件的协调。

4、在信息系统项目中，为了提高沟通的效率和效果，需要把握如下一些基本原则：

沟通内外有别、非正式的沟通有助于关系的融洽、采用对方能接受的沟通风格、沟通的升级原则、扫除沟通的障碍。

5、有效沟通的方式以下：

1）使用项目信息系统辅助沟通，用于收集、综合、分析项目管理过程输出的工具和技术；

2）建立沟通基础结构，是一套工具、技术和原则，为项目信息传送提供基础；

3）使用项目沟通模板；

4）把握项目沟通基本原则：沟通内外有别、非正式沟通有利于关系融洽、采用对方能够接受的沟通风格、沟通升级原则、扫除沟通的障碍。

5）发展更好的沟通技能；

6）认识和把握人际沟通风格；

7）良好的冲突管理

8）召开高效的会议

6、为了加强沟通，怎么样提高项目例会的效果？

1、事先制定一个例会制度，在项目沟通计划里，确定例会的时间，参加人员范围，一般议事议程等等。

2、放弃可开课不开的会议，在决定召开一个会议之前，首先应该明确会议是否必须

举行，还是通过其他方式进行沟通。

3、明确会议的目的和期望的结果，明确要开的会议的目的，是集体讨论一些想法，彼此互通信息还是解决面临的一个问题，并确定会议的效果是以信息同步为结束还是要讨论出一个确定的解决方案。

4、发布会议通知，在会议通知中明确：会议目的、时间、地点、参加人员、会议议程和议题。 有一种被广泛采用的决策方法是：广泛征求意见，少数人讨论，核心人员决策。 许多会议不需要全体人员参加，因此需要根据会议的目的，来确定参会人员的范围。 实现应明确会议的议程和要讨论的问题。 可以让参会人员提前做准备。

5、在会议之前把会议资料发发到参会人员手中。对于需要有背景资料支持的会议，应该先将资料发给参会人员，以提前阅读，直接在会上讨论。可以有效地节约会议时间。

6、可以借助视频设备。 对于有异地成员参加的会议，或者需要演示的场合，可以借助于一定的视频设备，以提高会议效果。

7、明确会议规则。 指定主持人，明确主持人的职责，主持人要对会议进行有效控制，并营造一个活动的会议气氛。 主持人要实现陈述会议的基本规则，例如明确每个人发言时间，每次发言只有一个声音，主持人根据会议的议程规定控制会议的节奏，保证每个问题都得到讨论。

8、会议后要总结，提炼结论。 主持人在会后总结问题的讨论结果，重申有关决议，明确责任人和完成时间。

9、会议要有纪要，如果将工作的结果、完成时间、责任人都记录在案，则有利于检查工作的完成情况。

10、做好会议的后勤保障，很多会议兼有联络感情的作用，因此需要选择一个合适的地点，提供餐饮、娱乐和礼品，制定一个有张有弛的会议议程。对于客户和合作伙伴参加的会忆尤其如此。

 

7、项目例会外，还可以采用的有效沟通措施：

1、首先应该对项目成员进行沟通和沟通风格的分析。

2、对于不同沟通需求和沟通风格的成员设置不同的沟通方式。

3、除了项目例会之外，可以通过电话、电子邮件、项目管理软件、OA软件进行沟通。

4、正是沟通的结果应该形成记录，对于其中的决定应该有人负责落实。

5、可以引入一些标准的沟通模板。

6、在项目组内培养团结的氛围。

8、潜在沟通渠道的问题为N(N-1)/2,其中，N代表干系人的数量。 比如有10个干系人项目，就有10（10-1）/2=45条潜在沟通渠道。

9、沟通基本原则：

1）沟通内外有别   2）非正式的沟通有助于关系的融洽 

3）采用对方能接受的沟通风格  4）沟通的升级原则

5）扫除沟通的障碍

10、沟通障碍

1）缺乏清晰沟通渠道

2）发送者和接收者存在物理距离

3）沟通双方彼此技术语言不通。

4）分散注意力的环境（噪声）

5）有害的态度（敌对、不信任）

6）权力游戏、滞留信息、隐藏议程和敌对情绪等。

九、风险管理

1、风险管理的过程

1）编制风险管理计划：描述如何为项目处理和执行风险管理活动；

2）风险识别：识别和确定出项目哪些风险，可能会影响到项目的哪些方面；

3）风险定性分析：对已识别出的风险评估其可能性、影响度、风险等级，进行

优先级排序，便于采取预防措施。

4）定量风险分析：定量地分析风险对项目目标的影响，方法有概率分布、灵敏度分析、期望货币值分析、决策树分析、建模和仿真等等。

5）编制风险应对计划：制定减缓风险影响的措施，如避免、转移、减轻等等；

6）风险监控：跟踪识别出的风险是否发生，是否采取相应的措施，检测残余风险和识别新的风险，保证风险计划的执行，并评价这些计划对减轻风险的有效性。

 

2、常见风险及应对措施。

风险项        产品原因    应对措施。

1、风险项：没有正确理解业务问题

     产生原因：项目干系人对业务问题的认识不足、计算起来过于复杂、不合理的业务压力、不现实的期限。

    应对措施：用户培训、系统所有者和用户的承诺与参与、使用高水平的系统分析师。

 

2、风险项：   用户不能恰当的使用系统

     产生原因： 信息系统没有与组合战略相结合、对用户没有做足够的解释、帮助手册编写的不好、用户培训工作做的不够。

      应对措施：  用户的定期参与、项目的阶段交付、加强用户培训、完善信息系统文档。

3、风险项：拒绝需求变更

      产生原因：固定的预算、固定的期限、决策者对市场和技术缺乏正确的理解。

      应对措施：变更管理、应急措施。

4、风险项：对工作的分析和评估不足

      产生原因：缺乏项目管理经验、工作压力过大、对项目工作不太满意 。

      应对措施：采用标准技术、使用具有丰富经验的项目管理师。

5、风险项：人员流动

      产生原因：不现实的工作条件、较差的工作关系、缺乏对职员的长远期望、行业发展不规范、企业规模较小。

      应对措施：  保持好的职员笨拙、确保人与工作匹配、保持候补、外聘、行业规范。

6、风险项：缺乏合适的开发工具

     产生原因：技术经验不足、缺乏技术管理准则、技术人员的市场调研或对市场理解有误、研究预算不足、组织实力不够。

   应对措施：预先测试、教育培训、选择替代工具、增强组织实力 。

7、风险项：缺乏合适的开发与实施人员

      产生原因：对组织架构缺乏认识、缺乏中长期的人力资源计划、组织不重视技术人才的技术工作、行业人才紧缺。

      应对措施：全面评估、推迟决策

 

8、风险项：使用了过时的技术

      产生原因：缺乏技术前瞻人才、轻视技术、缺乏预算。

      应对措施：延迟项目、标准检测、前期研究、培训。

 

简单的来说

风险管理可能出现的问题可能从以下几个方面去考虑

1）项目范围的风险

2）项目进度的风险

3）项目人力资源的风险

4）项目质量的风险

5）客户方面的风险

针对以上风险我们可以采取应对的措施：

1)项目范围尽可能清晰的界定。

2）项目进度制定需要充分考虑各种潜在因素，适当留有余地和柔性。

3）合理利用赶工及快速跟进等方法，充分利用资源，争取保质保量完成任务。

4）实施双方因对人员进行认真的评估，制定适当的奖惩措施。

5）对用户进行培训，让用户的需求更加合理。

3、识别风险是一个反复进行的过程，应该保证必须的干系人能够参加识别风险活动。识别风险的技术包括：文档审查、信息收集技术（包括头脑风暴、德尔菲技术、访谈、根本原因分析）、核对表分析、假设分析、图解技术（包括鱼骨图，又叫石川图或因果图、系统或过程流程图、影响图）、SWOT分析（每个字母代表的单词意思为优势、劣势、机会和威胁）、专家判断。 而风险调查法是针对特定信息系统工程的风险进行调整，最具有针对性，是必须采用的方法。 识别风险的过程输出是风险登记册，包括已识别风险清单和潜在的应对措施清单。

4、风险的特性：客观性、不确定性、随机性、相对性、可变性、阶段性。

5、风险识别主要内容包括：

1）识别并确定项目哪些潜在风险

2） 识别引起这些风险的主要因素。

3）识别项目风险可能的后果。

6、定性风险分析的方法：

1）风险概率与影响评估

2）概率和影响矩阵

3）风险数据质量评估

4）风险分类

5）风险紧迫性评估。

7、消极风险或威胁的应对策略包括回避、转移、减轻和接受。

      积极风险或机会的应对策略包括开拓、分享、提高、接受。

十、合同管理

1、合同管理可能会出现的问题：

1）合同没订好，没有就具体完成的工作形成明确清晰的条款。

2）甲方没有对需求及其变更进行统一的组织和管理

3）缺乏变更的接收-拒绝准则。

4）项目干系人及其关系分析不到位，范围定义不全面、不准确。

5）甲乙双方对项目范围没有达成一致认可或承诺 。

6）缺乏项目生命周期的范围控制

7）缺乏客户/用户参与

8）甲方无法进行跨部门协调

2、面对以下问题我们可以采取以下措施

》合同谈判阶段

1、缺的明确的工作说明书或更细化的合同条款。

2、在合同中明确双方的权利和义务，尤其是关于变更问题。

3、采取措施，确保合同签约双方对合同的条款理解是一致的。

》计划阶段

1、编制项目范围说明书

2、创建工作的分解结构

3、制定项目的范围管理计划执行阶段。

1、在项目执行过程中加强对易分解的各项任务的跟踪和记录。

2、建立与项目干系人进行沟通的统一渠道 。

3、建立整体变更控制的规程并执行。

4、加强对项目阶段性成果的评审核实确认。

》项目全生命周期变更管理

1、在项目管理体系中应该统一有一套严格、适用、高效的变更程序。

2、规定对用户的范围申请变更请求、应正式提出变更申请，并经过项目经理审核后，作出相应的处理。

3、合同的分类

按信息系统范围划分的合同分类：总承包合同、单项项目承包合同、分包合同。

按项目付款方式划分的合同分类：总价合同、单价合同、成本加酬合同

4、合同收尾是包括产品确定和管理收尾的过程，或者是说项目收尾包括产品收尾和管理收尾的过程。

5、合同提前终止是结束采购的一个特例。 合同可由双方协商一致而提前终止，或因一方违约而提前终止，或者为买方的便利而提前终止（如果合同中有这种规定）

6、项目合同签订的注意事项

1）当事人的法律资格

当事人订立合同，应该具有相应的民事权利能力和民事行为能力。

2）质量验收标准

质量验收标准是一个关键指标。 如果双方的验收标准不一致，就会在系统验收时产生纠纷。

3、验收时间

当事人没有约定设备的交付时间或约定不明确的，可以协议补充，不能达成协议的，依照合同有关条款或交易习惯确定。 若仍不能确定，则供货方可以随时履行，采购方也可以随时要求履行，但应当给予对方必要的准备时间。

4、技术支持服务

5、损害赔偿

原则上，委托方与被委托方都具有损害赔偿这项权利，但比较多的情况是因为承建方对企业实施信息系统的困难估计不足，结果陷入到期后难以完成项目的尴尬局面。

6、保密约定

当事人在订立合同过程中知悉的商业秘密，无论合同是否成立，不得泄露或者不正当地使用。泄露或者不正当地使用商业秘密给对方造成损失的，应当承担损害赔偿责任。

7、合同附件

合同生效后，当事人就质量、价款或者报酬、履行地点等内容没有约定或者约定不明确的，可以协议补充：不能达成补充协议的，按照合同有关条款或者交易习惯确定。

8、法律公证

为避免合同纠纷，保证合同订立的合法性，当事人可以将签订的合同拿到公证机关进行公证。 经过公证的合同，具有法律强制执行效力。

7、关于合同不明确情况的处理

1）当事人对标的的物的质量要求不明确的，按国家标准和行业标准。 没有这些标准的，按产品通常标准或符合合同目的的标准。

2）履行地点不明确，按标的性质不同而定：接受货币在接受方，交付不动产的在不动产所在地，其他标的在履行义务方所在地。  履行地在法律上具有非常重要的意义，它可以确定由谁负担，货物的所有权何时何处转移，货物丢失风险由谁承担等，在诉讼中，也是确定管辖权的重要依据，所以签订合同对履行地条款要特别注意。

3）履行期限不明的，债务人可随时履行，债权可随时要求履行，但应给对方必要的准备时间。 在这里特别提醒债权人要注意诉讼时效，关于随时履行受不受诉讼时效的制约目前仍有争议，不过最好在时效以内主张权利。

4）履行费用负担不明确的，由履行义务一方负担。 履行费用是履行义务过程中各种附随发生的费用。 在合同中应该考虑各种费用的分担，如果没有约定，视为履行义务方承担。   以上关于处理各种条款不明情况的法定标准，是根据长期交易形成的规律确定下来，不管对谁有利和不利，都得按这个规定去履行。 当然，最好还是把合同条款定得明确而严密些。

十一、采购管理（几率小）

采购管理包括：编制采购计划、编制询价计划，询价、招投标；供方选择合同管理和收尾。

1、编制采购计划：决定采购什么，何时采购，如何采购。

2、编制询价计划：记录项目对于产品、服务或成果的需求，并且寻找潜在的供应商。

3、询价、招投标：获取适当的信息、报价、投标书或建议书

4、供方选择：审核所有建议书或报价，在潜在的供应商中选择，并与选中者谈判最终合同。

5、合同管理和收尾：管理合同以及买卖双方之间的关系，审核并记录供应商的绩效以确定必要的纠正措施并作为将来选择供应商的参考，管理与合同相关的变更。

合同收尾的工作是：完成并结算合同，包括解决任何未决问题，并就与项目或项目阶段相关的每项合同进行收尾工作。

工作说明书与范围说明书的区别

》工作说明书是对项目所要提供的产品、服务的叙述性描述。

》项目范围说明书通过明确项目应该完成的工作而确定了项目的范围。

采购工作说明书描述了由卖方提供的产品、服务、成果。 每个采购工作说明书来自于项目范围基准，定义了一采购合同相关的部分项目范围。

 

招投标流程及管理（重点学习）

招投标：招标、投标、开标、评标、中标。

注意事项：

1）任何单位和个人不得将依法必须进行招标的项目化整为零或采用其它方式规避招标。

2）应该遵循公开、公平、公正和诚实信用原则。

3）招投标活动不受地区或部门的限制，任何单位和个人不得违法限制或排斥本地区、本系统以外的法人或其他组织参加招投标，也不得非法干涉招标活动。

》招标类型：公开招标、邀请招标（有公开招标、竞争性谈判、询价采购、单一来源、其他5种类型）

公开招标是以公告形式出现的，邀请招标是邀请特定的人。

》招标人有权自行选择招标代理机构、委托其办理招标事宜。

任何个人或单位不得以任何方式为招标人制定招标代理机构。

招标文件开始发出之日起至投标人提交标文件截止日期之日止，最短不得少于20日。 招标人对已发出的招标文件需要进行澄清或修改的。

》投标人提交投标文件截止时间至少15天前，以书面形式通知所有招标文件收受人。并且该澄清或修改的部分为招标文件的组成部分。

》投标人少于3个的，招标人应该重新招标。 在投标文件截止日期后送达的投标文件，应该不予以接收

》投标人在招标文件要求提交投标文件的截止日期前，可以修改、补充或撤回已提交 的投标文件，并书面通知招标人。 补充、修改完善的部分为投标文件的组成部分。 联合投标===2个或2个以上的法人或组织以一个投标的身份投标。 其中，联合体各方均应当具备承担招标项目的相应能力和相应的资质要求。 并且按资质较低的算。

》开标：

应当在招标文件上确定的提交投标文件截止时间的同一时间开标，开标地点应为招标文件中预先确定的地点。 开标时要检查投标文件的密封情况，要当场宣读投标人名称、价格、投标文件主要内容。

》评标委员会：由招标人的代表和有关技术、经济等方面的专家组成，成员人数

应该为五人以上单数，其中技术、经济等方面的专家不得少于总数的三分之二。

完成评标后，应当向招标人提出书面评标报告，并推荐合格的中标候选人。

招标人根据评标委员会提出的书面评标报告和推荐的中标候选人确定中标人。

招标人也可以授予授权评标委员会直接确定中标人。

》中标人的投标应当符合下列条件之一：

1）能够最大限度地满足招标文件中规定的各项综合评价标准

2）能够满足招标文件的实质性要求，并且经评审的投标价格最低，但是投标价格低于成本的除外。

》中标人确定后，招标人应当向中标人发出中标通知书，并同时将中标结果通知所有未中标的投标人。 招标人和中标人应当自中标通知书发出之日起30日内，按照招标文件和中标人的投标文件签订书面合同，不得再订立背离合同实质性内容的其他协议。依法必须进行招标的项目，招标人应当确定中标人之日起15日内，向有关行政监督部门提交招投标情况的书面报告。

》中标人按照合同约定或经招标人同意，可以将中标项目的非主体、非关键性工作分包给其他人，接受分包的人应当具备相应的资质，并且不得再次分包。

中标应当就分包项目向招标人复制，接受分包的人就分包项目承担连带责任。

12、配置管理(喜欢和整体、变更一起出题，重点)

1、要求在软件开发过程中做发配置管理，步骤如下：

1）制定配置管理计划：确定方针、分配资源、明确职责、计划培训、确定干系人、制定配置识别准则、制定基线计划、制定配置变更流程，制定审批计划等；

2）识别配置项：识别配置项、分配唯一标识、确定配置特征、记录配置项进入时间、确定配置项拥有者职责，进行配置项登记。

3）建立配置管理系统：建立分级配置管理机制，存储和检索配置项，共享和转换配置项，进行归档、记录、保护和权限设置

 

十二、配置管理（喜欢和整体、变更一起出题，重点）

1、要求软件开发过程中做发配置管理，步骤如下：

1）制定配置管理计划：确定方针、分配资源、明确职责、计划培训、确定干系人、制定配置项识别准则、制定基线计划、制定配置变更流程，制定审批计划等等。

2）识别配置项：识别配置项、分配唯一标识、确定配置特征、记录配置项进入时间、确定配置项拥有者职责，进行配置项登记；

3）建立配置管理系统：

建立分级配置管理机制，存储和检索配置项，共享和转换配置项，进行归档、记录、保护和权限设置；

4）基线化：获得授权，建立和发布基线。

5）建立配置库：建立动态库、受控库和静态库。

6）变更控制：变更的记录、分析、批准、实施、验证、沟通和存档。

7）配置状态统计：统计配置项的各种状态；

8）配置审计：功能审计和物理审计。

2、配置库可以分为动态库（开发库、程序员库、工作库）、受控库（主库）、静态库（软件仓库）和备份库4种类型。

开发库：存放开发过程中需要保留的各种信息，供开始人员个人专用。

受控库：在软件开发的某个阶段结束时，将工作产品存入或将有关的信息存入。

产品库：在开发的软件产品完成系统测试后，作为最终产品存入库里，等待交付用户或现场安装。

备份库：包括制作软件和相关构架、数据和文档的不同版本的复制品。 在各点的及时备价，可以每天、每周或每月执行备份。

3、配置项状态变迁规则：草稿、正式、修改。

4、配置审核的意义：

1）防止出现向用户提交不适合的产品

2）发现不完善的实现

3）找出各项配置项间不匹配或不相容的现象。

4）确认配置项已在所要求的质量控制审查之后作为基线入库保存。

5）确认记录和文档操持着可追溯性。

十三、变更管理（重点学习，经常考）

变更指对项目计划的改变；整体变更控制贯穿于整个项目过程的始终。 对项目范围说明书、项目管理计划、项目可交付物必须进行变更管理。

被批准的项目管理计划就是项目的基准（基线）。

1、变更的分类

1）内部变更：项目在实施过程中，对实施的状态和计划对比，发现产生了偏差，从而导致项目计划的变更。

2）外部变更：由于客户方面的原因，项目目标本身发生了变化。从而引起了项目计划的变更。

2、有可能的问题

1）对用户的要求未进行记录

2）以变更请求未进行跟踪的分析，也没有获得批准；

3）在修改的过程中没有注意进行版本管理；

4）修改完成后未进行验证。

5）修改的内容未和项目干系人进行沟通。

3、变更的常见原因

1）产品范围（成果）定义的过失或者疏忽。

2）项目范围（工作）定义的过失或者疏忽。

3）增值变更。

4）应对风险的紧急计划或回避计划。

5）项目执行过程与项目基准要求不一致带来的被动调整。

6）外部事件。

4、导致的后果

1）缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。

2）缺乏对变更请求分析可能会导致后期的变更工作失误；

3）在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原；另一方面，对于组织财富和经验的积累也是不利的；

4）修改完成后不进行验证则难以确认变更是否正确实现。

5）未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处。

5、变更流程

1）变更请求   2）变更评估   3）变更决策   4）变更实施   5）变更验证  6）沟通存档

遇到需要变更时要严格走以下变更流程：

1、变更申请：记录变更的提出人、日期、申请变更的内容；

2、变更评估：对变更的影响范围、严重程度、经济和技术可行性进行系统分析。

3、变更决策 ：有具有相应权限的人员或机构（CCB）决定是否实施变更；

4、变更实施：由指定的人员在受控状态下实施变更。

5、变更验收：由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果是否符合预期，相关内容是否进行了更新，对输出的工作产品实施版本管理。

6、沟通存档：将变更后的内容通知可能受到影响的人员，将变更记录存档，便于追溯。

 

对于变更评审：

1）CCB在收到变更请求后，会有专门的人员做一个初步的分析，主要是评估变更的来源、理由、产生的影响、以及变更的代价；

2）某些申请会在这一阶段先做一个初步的处理（描述不清的申请会被要求重新提交 、明显错误的变更申请会被删除、简单且影响较小的变更申请会被直接分配并处理），其余的申请会被提交到CCB进行评审。

变更控制委员会的组织机构：

一）变更控制委员会CCB,也称为配置控制委员会：

1）是一个项目主要的管理机构组织。

2）人员组成：可以包括高层经理、项目经理（技术负责人）、配置管理负责人、质量保证负责人、测试负责人等；该组织不必是常设机构，包括的人员也不必面面俱到，可以根据项目的实际情况决定其人员组成；小的项目中CCB可以只有一个人或者多个人，甚至只是兼职人员；

3）CCB是决策机构，不是作业机构。通常，CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。

二）项目经理（PM）:

项目经理对项目负责，其正式权利由项目章程取得，而资源调度的权力通常在项目基准中明确规定。 项目基准中不包括的储备资源需经授权人批准后方可使用。

项目经理在变更中的作用是：响应变更提出者的要求，评估变更对项目的影响及应对方案，将要求由技术要求转化为资源需求，供授权人决策；并据评审结果实施即调整项目基准，确保项目基准反映项目实施情况。

6、变更管理的基本原则

变更管理的原则是首先建立项目基准、变更流程和变更控制委员会（也叫变更管理委员会）。包括以下内容：

1）基准管理

2）建立变更控制流程

3）完整体现变更的影响

4）明确组织分工

5）妥善保存变更产生的相关文档

14、收尾管理（稍微学习一下）

项目收尾阶段是收获项目成果的阶段，同时也是IT信息类项目容易理解但较难操作的阶段之一。这个阶段一旦结束，就标志着整个项目管理过程的最终结束。

如同项目启动阶段需要正式的文档和工作一样，项目收尾阶段也需要以某种正式的活动作为结束标志：主要是完成项目交付成果的检验，由承建方将完成的成果交与用户方，业务（用户）确认成果符合合同规定。 项目收尾的另一重要内容是从项目中获得相关经验，以便指导和改善未来项目的运作和实施。

项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。

项目的正式验收包括验收项目产品、文档及已经完成的交付成果。

验收需要正式的验收报告。 对于系统集成项目，一般来讲需要正式的验收测试工作。

验收测试工作可以由业主和承建单位共同进行，也可以由第三方公司进行，但无论哪种方式都需要双方认可的正式文档为依据进行验收测试。

如果验收测试未获通过，同应立即查找原因，一般会转向变更环节进行修改和补救；

通常，系统集成项目的验收工作包括如下步骤：

1、系统测试

2、系统的试运行

3、系统的文档验收

4、项目的最终验收报告。

项目总结

项目总结属于项目收尾的管理收尾。 而管理收尾有时又被称为行政收尾，就是检查项目团队成员及相关干系人是否按规定履行了所有责任。 实施行政收尾过程还包括收集项目记录、分析项目成败、收集应吸取的教训，以及将项目信息存档本组织将来使用等活动统一为一个整体。

项目总结的主要意义如下：

1）了解项目全过程的工作情况及相关的团队或成员的绩效状况。

2）了解出现的问题并进行改进措施总结。

3）了解项目全过程中出现的值得吸取的经验并进行总结。

4）对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业过程资产。

项目评估和审计：

项目评估的意义是将项目所有工作加以客观的评价，从而对项目全体成员的成果形成绩效结论。 好的项目评估会引导后续项目的开展，并对项目过程的改进起到重要的作用。 一般的由第三方进行的。

项目的审计应由项目管理部门与财务部门共同进行，相关的审计项目应在项目成本管理中列出。 在项目收尾的时候，对已经列出的支出和收入进行账务审计，对不合理的支出和收入加以分析，为改进项目的管理服务。分为内审和外审。

十五、服务管理

信息系统服务是一个范围相当广泛的概念，所有以满足企业和机构的业务发展所带来的信息化需求为目的，基于信息技术和信息化理念而提供的专业信息技术咨询服务、系统集成服务、技术支持服务等工作，都属于信息系统服务的范畴

我国信息系统服务管理的主要内容：

1）计算机信息系统集成单位资质管理

2）信息系统项目经理资格管理

3）信息系统工程监理单位资质管理

4）信息系统工程监理人员资格管理。

计算机信息系统集成资质等级从高到低依次为一、二、三、四级。 其中一级为最高级，系统集成资质有效期3年，届满3年应及时更新新证，换证时必须由评审机构对申请单位进行评审，评审结果达到原有等级条件时，其资质等级不变。

信息系统工程监理单位分为甲乙丙三级，信息系统工程监理资格证书分为高级监理工程师、监理工程师、监理员。 信息系统工程单位分为甲（没有投资规模限制）、乙（投资规模在1500万元以下）、丙（投资规模在500万元以下）三级。

监理活动的主要内容概括为：四控、三管、一协调。

四控：信息系统工程质量控制、信息系统工程进度控制、信息系统工程投资控制。

           信息系统工程变更控制。

三管：信息系统工程合同管理；信息系统工程信息管理；信息系统工程安全管理。

一协调：在信息系统工程实施过程中协调有关单位及人员的工作关系。

工程管理三方：建议方、承建方、监理方。

ITTL与IT服务管理、信息系统审计（了解）

1、ITSM核心思想是：IT组织，不管它是企业内部的还是外部的，都是IT服务提供者，其主要工作就是提供低成本、高质量的IT服务。

2、实施IT服务管理的根本目标：

1）以客户为中心的提供IT服务

2）提供高质量、低成本的服务；

3）提供的服务是可以准确计价的。

3、IT服务管理的价值：作为IT管理的ERP解决方案，IT服务管理给实施它的企业、企业员工及其他利益相关者提供多方面的价值。

《IT服务管理实施规划》将这些价值归纳为商业价值、财务价值、创新价值和内部价值、员工利益。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

本文出自 “IT产品技术&管理=伟豪” 博客，请务必保留此出处http://itcn001.blog.51cto.com/1469755/1013381