Else 的博客

请围绕“项目的风险管理”论题，分别从以下三个方面进行论述：1．概要叙述你参与管理过的信息系统项目（项目的背景、发起单位、目的、项目周期、交付的产品等），以及该项目在风险管理方面的情况。2．请简要叙述你对于项目风险的认识以及项目风险管理的基本过程。3．结合你的项目经历，概要论述信息系统项目经常面临的主要风险、产生根源和可以采取的应对措施。

我们对已识别的风险列出风险的名称、风险影响、风险策略、责任人等内容形成风险登记册。在识别风险时，我鼓励所有项目相关方参与风险识别，我们依据风险管理计划、进度管理计划、成本管理计划、质量管理计划、范围基准及人力资源管理计划等文件，召开会议，通过头脑风暴等方式，让大家畅所欲言，总结出项目在质量、进度、成本、范围、人力等方面可能存在的风险，并将风险记录下来，识别出的主要风险包括成本超支、需求随时变动、进度延误、核心人员离职、硬件设备到货干系人沟通不畅、及政策方生改变等风险，最终形成本项目的风险登记册。

1、事前预防，风险不可避免，但是可以预估，提前对可能出现的风险进行规避，可有效减轻或避免风险带来的损失;2、事中控制，当预判到风险时，就要立即采取措施减轻风险后果，比如用成本换进度，用进度换质量等等;3、事后总结，风险管理经验的积累和总结，是风险管理水平提高的重要动力源泉。应加强这方面的积累，才能之后的风险管理活动中游刃有余。1、重视项目的调研，充分了解项目需求与范围;2、要把计划工作做实，要根据实际情况不断地修正计划，才能使得风险真正受控;

监督风险过程采用项目执行期间生成的绩效信息，以确定:①实施的风险应对是否有;②整体项目风险级别是否已改变;③已识别单个项目风险的状态是否已改变;④是否出现新的单个项目风险;⑤风险管理方法是否依然适用;⑥项目假设条件是否仍然成立;⑦风险管理政策和程序是否已得到遵守;⑧成本或进度应急储备是否需要修改;⑨项目策略是否仍然有效等。

（1）早期明确客户的需求和系统产品的方向，减少后期的变动，早期准备技术调研，让资深的技术专家介入到需求调研和分析阶段做好合理的技术选型，可以应对（需求不断新增、代码测试质量差、计划排期不准、变更记录不全未周知，发布流程不规范等可以用对应的更完善的流程来缓和和预防问题的发生。：上报、规避（延迟进度、缩小范围、改变策略）、转移（非消除风险，向风险承担者支付风险费用，如买保险、外包集成资源）、减轻（采用不太复杂流程、更多测试、更可靠供应商、开发原型等）、接受（主动接受：建立应急储备）4、团队合作胜过闭门造车。

每次改变一个因素，其他的因素不变，看这个因素对目标产生多大程度的影响。敏感性分析的典型表现形式是龙卷风图。4.工具和技术：数据收集和展示技术：访谈（乐观、悲观、最可能）、数据分析（模拟、敏感性分析、决策树分析、影响图）3.定义：就已识别的单个项目风险和不确定性的其他来源对项目整体目标的影响进行定量分析的过程。2）基于单个风险定量分析的结果，对项目整体目标的影响进行定量分析，量化风险信息，用损失多少钱表示出来。1.我们通过了什么方法进行了风险的定量分析，通过分析起到了什么效果，结合项目的具体情况进行说明。

影响系数计算出分值大小，然后进行排序。如:人员离职的风险值=0.62=1，需求不明确的风险值=0.4。

1.我们通过了什么方法进行了风险识别，识别出了有哪些风险？每种风险类型进行描述、原因分析等2.风险识别活动的参与者可包括：项目经理、项目团队成员、风险管理团队（如有）、客户、项目团队之外的主题专家、最终用户、其他项目经理、干系人和风险管理专家。

三、尽量降低风险造成的损害:这是风险发生阶段的管理，既然风险已经发生，完全避免损失已经不太可能，我们只能强调尽量，即最大限度地减少风险的危害性;四、尽责总结风险带来的教训:这是风险后果阶段的管理，人们最容易犯的错误是好了疮疤忘了疼，因此我们强调尽责，把风险的教训，风险应对方法及效果，风险管理的有效性总结等形成文档。定期对风险登记册进行审查，删除过时风险、释放储备，识别新的风险，重新评估风险的有效性。成本风险，不得超出总预算的5%。:主要划分为进度风险、成本风险、质量风险、技术风险、组织风险、财务风险。

5、你参与管理过的信息系统项目有哪些风险﹖并具体阐述其应对计划，包括:风险描述、出现的原因、采用的具体应对措施、方法和工具等。8、请结合项目实际情况画出一个风险登记册说明风险基本情况，风险登记册是如何完善更新的【12、请结合蒙特卡洛分析、气泡图分析下项目中的风险情况P410。13、针对项目中的重要风险，您是如何应对解决的?10、定性风险分析和定量风险分析有何区别和联系?2、项目风险管理的过程、工具和技术、输入输出。【规划风险管理、识别风险、试试定性风险分析】【识别风险、规划风险应对、各个过程】

在项目管理三角形中，质量位于进度，成本，范围的中间的位置。规划质量管理的输入中有需求文件，也就是说先有范围有需求的基础上，才可以进行制定质量管理计划。设定的质量测量指标的高于低，将直接影响到项目的成本情况。也就是说质量和成本的关系是高质量是要以高成本为代价。还有制定质量管理计划的输入中有成本效益分析，有质量成本这两个工具，这些工具与技术的使用，都会产生成本变化，而统计抽样，测试检查等的实施密度不同，也会直接体现在成本之中。进度和质量的关系是唯美求全，往往要付出沉重的代价，甚至偏离目标更远。

请围绕“项目的质量管理”论题，分别从以下三个方面进行论述：1．概述你参与管理过的信息系统项目以及在项目中所遇到的质量管理问题。2．请简要论述你对于质量、质量管理和质量成本的认识。3．简要论述你认为提升项目质量应做哪些工作。写作思路：背景1-2段，500字左右过渡段1段，150字左右【写质量、质量管理的认识】一、规划质量管理【写质量成本】二、管理质量【写提升项目质量的措施方法】三、控制质量【写提升项目质量的措施方法】收尾300字左右。

经验：1、制订科学合理的质量管理，管理质量，质量控制计划很重要。2、严格执行质量管理，管理质量和质量控制计划很重要。3、质量管理的工具和技术不宜采用过多，适用和够用就好，关键是如何把这些工具和技术用好，用透。4、质量控制过程中发现的问题或缺陷一定要严格跟踪直至解决 5、条件成熟的情况下，可以把产出物质量和软件系统的质量作为绩效考核的指标之一。6、领导越重视质量，往往质量会越好，如何让领导重视质量便是我们项目经理要做的事情。7、质量与成本有着密不可分的联系。

由于项目的模块多，功能复杂，数据量又比较大，我们每完成一个功能模块的需求、设计、开发、测试等都要求项目相关人员参与评审，在会上记录大家的意见、讨论出现的偏差，分析原因，提出解决措施，直至问题解决。我赶紧组织相关技术人员，采用因果图分析该问题的根本原因，分析可能是接口问题、数据库问题或代码调用问题，又用直方图将这几种问题导致的影响从大到小进行排列，发现接口问题累计达到85%，最终分析得出问题的根源在于接口的开发方案存在缺陷。团队成员通过鱼骨图进行了分析，将导致响应速度慢的所有原因进行了分析，图形如下。

比如，在项目进行过程中，QA发现大家在进行项目相关文档的评审时不太积极，觉得评审工作与自己的关系不大，因而有点流于形式，QA在审计报告中说明了这种现象。我了解后及时分析了原因，主要是评审工作没有明确纳入项目成员的工作量，各人只关心明确列入工作量的事务，针对这种情况，我采取了如下措施，将评审工作进行记录，定期通报各人参加评审的次数、时长、提出合理化建议的数量，以及后道工序的责任人必须评审前一工序的产出物，如果评审未发现问题，评审通过后再发现问题将由后道程序的负责人负责。质量管理培训，时间待定。

为了更好的保证项目质量，在项目启动阶段，我同公司QA组长、质量保证人员等召开会议，根据项目章程、项目干系人参与计划、干系人登记册等资产结合当前行业政策、各类标准等事业环境因素，通过成本效益分析、流程图、头脑风暴等工具，编制了质量管理计划的初稿，进行内部评审，并进行了修改完善。质量管理计划的内容一般包括：①项目采用的质量标准②项目的质量目标③质量角色和职责④为项目规划的质量控制和质量管理活动⑤项目使用的质量工具⑥与项目有关的主程序，如处理不符合要求的情况，纠正措施程序以及持续改进程序。⑥项目使用的质量工具;

（3）合格的QA，跟踪和报告项目运行中的发现问题，只是其工作职责的基础部分，更富有价值的工作包括为项目组提供过程支持，例如为项目经理提供以往类似项目的案例和参考数据，为项目组成员介绍和解释适用的过程定义文件等；评审的效果好不好，我认为与评审活动的组织，参加评审的人员构成，以及如何开展评审工作有非常密切的关系。阶段管理评审就是指在项目的某个时期，依据是先定义好的每个阶段的开始和结束边界，检查该阶段的过程和工作产物的合格性，对项目阶段绩效进行整体评价并提出改进建议的过程。（2）QA活动贯穿项目运行的全过程；

试题：论信息系统项目的干系人管理-项目干系人管理是对项目干系人需求、希望和期望的识别，并通过沟通上的管理来满足其需要、解决问题的过程。请以"论信息系统项目的干系人管理"为题进行论述∶1.概要叙述你参与管理过的信息系统项目（项目的背景、项目规模、发起单位、目的、项目内容、组织结构、项目周期、交付的成果等），并说明你在其中承担的工作（项目背景要求本人真实经历，不得抄袭及杜撰）。2.请结合你所叙述的信息系统项目，围绕以下要点论述你对信息系统项目干系人管理的认识：（1）项目干系人管理的过程；

我们按照沟通管理计划定期跟干系人进行沟通，在沟通过程中，我会倾听干系人的诉求，也会通过观察读出干系人的话外之音，沟通结束后我会对干系人进行分析，判断干系人当前的状态，更新干系人参与度评估矩阵，如果干系人的当前参与度达不到所需参与度的要求，我就会调整干系人参与计划和和沟通管理计划，努力让干系人达到项目所需的参与度要求。监督干系人参与是监督干系人的关系，并通过参与策略和计划来引导干系人合理参与项目的过程，本过程的主要作用，随着项目的进展和环境的变化，维持和提升干系人参与活动效果和效率。

我们定期依据干系人登记册、沟通管理计划、干系人参与计划等文件，对所有干系人进行分析，发现李院长（分管医疗副院长）总是以各种由拒绝参加项目沟通会议，经过我和李院长单独的会谈，原因是李院长认为目前运行的PACS系统，系统稳定，满足影像科的要求，没有必要更换，担心更换后系统不稳定，对于李院长的顾虑，我们演示了我司的产品，以及成功的案例分享，以及新PACS上线后对于消除信息孤岛，共享信息资源的益处，也是医院互联互通5级的要求，通过此次沟通得到了李院长的信任和支持。②通过谈判和沟通的方式管理干系人期望;

3.周院长，分管信息财务副院长，属于高权力高利益，对项目重视和支持，管理策略：重点管理，需参加周例会、阶段总结会，1周一次沟通，直接预约沟通，汇报项目进展，沟通项目重大流程。6.信息科刘科长，甲方项目总协调人，属于高权低利益，对项目支持，管理策略：令其满意，需参加周例会，随时沟通，电话、当面沟通，沟通项目整合流程，协商项目各模块上线计划等。1.张院长，医院一把手，属于高权力高利益，对项目非常重视和支持，管理策略：重点管理，需参加阶段总结会，2周一次沟通，和办公室预约沟通，主要汇报项目进展。

在项目启动以后，我依照项目章程开始识别本项目的干系人，我首先按照团队内部和外部进行干系人识别，团队外部的主要是考虑建设方分局领导、建设方各科室沟通负责人，市局科通部门负责人、指挥中心负责人、派出所等一线民警，因为项目还涉及到传感器和服务器的采购，所以我还把供应商的一些干系人也识别出来，团队内部主要包含需求分析人员、架构师、开发人员、测试人员、QA 等等。（1）识别全部潜在的项目干系人及其相关信息，通常先识别关键干系人，然后对已识别的干系人进行访谈，来识别其他干系人，扩充干系人名单，直至列出全部潜在干系人；

背景500字1-2段 过渡段150字左右1段一、规划进度管理…【随便写，正常写即可】二、定义活动…【随便写，正常写即可】三、排列活动顺序…【随便写，正常写即可】四、估算活动持续时间…【随便写，正常写即可】五、制定进度计划…【重点写，需要写出甘特图编制的进度计划，可以画一个甘特图说明进度计划，也可以不画图，用文字方式表达出来，比如用project来制定甘特图，得到什么活动什么时候开始到什么时候结束】

经验：1、慢慢计划，快速执行。在计划时对工作内容、技术要求、人力资源、风险因素等进行充分的了解，在执行时根据实际情况实时调整和纠偏。2、计划工作别想着一成不变，要根据实际情况不断地修正计划，才能使得进度真正受控。3、计划的首要原则就是让具体做事的人参与到计划的制订中来，这样既能做出精准的预判，又能明确工作的具体事项，还能调动人员的参与，可谓一举多得4、要洞悉项目进行的趋势，随时发现影响进度计划的因素，及时解决 5、人尽其才，要将熟悉的人放在熟悉的工作岗位上，这样既能加快效率又能提高质量。

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。我定期依据进度管理计划、进度基准、进度数据等文件，通过挣值分析、偏差分析等技术来对项目进度进行监控，11月20日在分析进度情况时发现，培训进度SPI为0.9，我立刻召集项目组分析，原因是10月下旬新冠疫情突发，此时正是系统集成完毕，准备软件培训的阶段，医护人员大部，分投入全民核酸检测的采集工作中，工作人员来参加培训的时间非常少，如不进行进度干预，势必要影响系统上线时间，经和院方会议讨论决定如下：1.利用中午、晚上、周末休息时间进行软件培训。

在制定进度计划中，我组织项目团队，将活动清单和活动持续时间估算带入到本项目的进度网络图并进行分析，确定了项目的关键路径，还形成了进度基准。制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程，是为完成项目活动而制定具有计划日期的进度模型。在制定项目进度计划时，我们把项目分成需求分析、详细设计、开发实施、测试、部署等阶段，利用关键链法，让所有活动及早开始，将剩余的自由浮动时间放到缓冲里去，并考虑到项目可能出现的一些不可控因素,预留了7天的储备时间。

因此大部分的活动我们采用了类比估算法，从而节约了时间。经过各专家和开发团队成员的讨论，认为最乐观的时间为2个工作日、最悲观的时间为6个工作日、最有可能的时间为4个工作日。由于我们前期进行过多个类似项目的开发，同时，项目间也有某些不同的要求，相似模块我们采用类比估算和三点估算相结合的方法，例如种植业一张图模块，我们做过类似模块，该地区没有水稻生产，而增加了谷物和花生的内容，先期开发的时候，我们用了16天，我们与开发过此项目的工程师一起，进行估算最快18天，最慢22天，最可能20天，计算该工作的工期为20天。

例如，在本项目中，开发WEB 系统的小组和开发手机客户端的小组所进行的活动既相互独立有相互依赖，因而可以并行进行，但在某些时间点上又存在约束关系，一些在手机上实现的功能要等WEB系统完成后才能进行，我们经过几次反复调整之后才得到较为合理的网络图。排列活动顺序是识别和记录项目活动之间的关系的过程。我组织项目组成员本着工作包谁负责谁分解的原则，在进度管理计划、范围基准的指导下，对WBS中项目近期要完成的工作包进行分解，得到具体要完成的活动，并对活动进行描述，汇总形成活动清单和活动属性。种植业一张图工作包。

计划中，采用预测和适应型混合的周期模型，项目的总体开发以预测型，按流程进行需求、规划、实施、测试、结束等流程，但是其中几个模块，特别是需要紧急上线让客户看到效果的模块，如农业农村一张图，采用适应型开发，以能够最短的时间上线运行，满足甲方尽快看到效果的期望。接着我组织业主方领导和其他干系人，对进度管理计划进行评审，评审会上我详细介绍了进度管理计划的内容，得到了业主方的认可，并通过了评审，正式成为本项目的进度管理计划，为进度管理过程提供了基本依据。5、如何用甘特图制定进度计划，进度管理计划和进度计划的区别?

一、规划范围管理…【随便写，正常写即可】二、收集需求…【采分点：重点写，输出是需求跟踪矩阵，然后需要举例需求跟踪矩阵的作用，结合项目进行列举说明】例如需求跟踪矩阵的实例：【考试不需要画图，列举2-3个功能的情况，比如需求状态等等】三、定义范围…【采分点：范围说明书的内容，对于子题目3结合项目描述项目的范围】

经验：1、在规划范围管理的时候，对项目的复杂程度过于乐观，考虑的不够周详，制订的计划粒度过于粗糙2、在收集需求前，没有对需求收集人员进行项目业务上的培训，导致需求收集人员与客户沟通时存在障碍3、在定义范围时，忽略了行业标准，导致几处交付物验收标准定义过低不符合项目实际情况4、在创建WBS时，对WBS字典的定义过于粗糙，编号规则不是很统一5、在确认范围时，准备的资料不够详细，没有足够的说服力，还有部分交付物质量检测的不够严格，导致验收过程不是很顺利。

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。在项目执行过程中，客户提出了一些新的需求，对于一些不必要的变更，我们通过沟通，使客户予以放弃，而对于一些必要的变更，严格按照变更控制流程进行，避免范围的蔓延。例如，在一次状态审查会上，我发现项目的功能模块中，综合管理平台里面多了桌面风格管理的功能，我查了下系统变更日志，未找到有类似的变更记录，于是我参照责任分配矩阵，找到这个模块开发的负责人询问原因，陆工告诉我，他增加这个功能，是因为业主方有人在一次电话中，向他提过希望增加这样一个功能。

在该项目中，我使用检查和群体决策技术，在每个阶段结束时与相关干系人召开阶段评审会，各方共同对本阶段的工作内容和交付物进行评审，并对关键文档进行确认定版，项目进行过程中，我总共组织了3次阶段成果物检查和评审，第一次主要是针对票型管理、票库管理、订单管理、售票管理等模块组织了项目团队并邀请景区项目经理、信息科主任、售票经理进行评审;也可以和确认范围同时进行，质量控制是内部进行，强调的是可交付成果的正确性及是否满足质量要求，而范围确认通常在阶段末进行，观调的可交付成果是否被客户接受和认可。

【范例3】创建WBS是把项目可交付成果和项目工作分解为较小、更易于管理的组件的工作。本项目中我们依据范围管理计划、项目范围说明书、需求文件的内容，通过专家判断和分解的技术来创建WBS，我们采用的是按照子系统做为第二层的方式来建立WBS，我们严格遵守三个标准来分解WBS：可估算、可分工、可控制。对WBS进行了编码工作，WBS创建完成后我们组织内部审查，然后交给院方各干系人，通过会议的方式讨论各阶段的工作内容，经过三次的修正，最终完成了确认的WBS，形成了范围基准，为后续的项目管理提供依据。

在项目范围说明书中，我们明确了产品范围描述、可交付成果以及验收标准等。在收集完需求后，我组织项目主要干系人，以范围管理计划和需求文件为基础，通过专家判断和产品分析，对系统功能进行评价，通过用户的角度改进和完善系统功能，对各模块功能进行详细的记录，最终制定出项目范围说明书。项目范围说明书包括：1、产品范围描述（包括各子系统模块等）2、项目的可交付物（用户文档、应用系统等）3、系统验收标准（功能满足需求、系统运行稳定、相关文档齐全等）4、项目的除外责任（该项目涉及的机房的主电不包含在该项目范围中）。

需求是龙头，收集需求是为实现项目目标而确本记录并管理干系人的期望和需求的过程，为定义项目和产品范围奠定了基础。随后组织法院执行法官及法官助理、书记员等相关干系人就项目需求召开需求讨论会，会议中因部分干系人对部分需求概念模糊描述不清楚，双方产生了分歧，针对这些需求我采用原型法来收集，利用故事板将干系人对需求的想法转化为图形描述，消除彼此的歧义，充分挖掘客户的需求，最终形成需求文件和需求跟踪矩阵，并得到了所有干系人的签字确认。收集需求是为了实现项目目标而确定，记录并管理干系人的需要和需求的过程。

规划范围管理就是书面描述将如何定义、确认和控制项目范围和产品范围的过程。规划范围管理就是书面描述将如何定义、确认和控制项目范围和产品范围的过程。规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过心为项目范围管理提供指南和方向，我带领项目组通过项目管理计划、项目章程，并邀请公司相关领域的专家帮助，依靠他们丰富的理论知识和站在全局的高度进行项目的分析，另外还借鉴公司做过的同等规模的医院项目，结合此项目实际情况编制项目范围管理计划和需求管理计划。4、范围管理计划和需求管理计划的内容。

1）尽可能在项目的早期就确定项目需要采购的内容，以便有足够的时间确定采购方式和选择合适的供应商。2）选择供应商时一定要根据被采购产品或服务的特点设定供应商入选门槛，这样不但可以提高供应商选择工作的效率和质量，而且可以避免鱼目混珠。3）必须把外包模块供应商的管理当作整个项目管理整体的一部分。4）不仅要供应商提供满足要求的工作结果，还要监控供应商的工作过程。5）采购也是一种风险转移和风险分享的手段，所以在制定采购管理计划的时候，需要参照风险登记册；

果然，没过几天，我们就收到了卖方邮寄的全部显示屏。在2022年3月，我们用挣值分析方法对项目绩效进行评价时发现SPI=0.96，进度滞后，经过分析发现是设备采购由于受疫情影响推迟到货，发现问题后，我们及时和甲方沟通，取得甲方谅解，同时与供货方沟通，供货方同意加派人手进行设备的安装调试，及时进行了纠偏。按照合同履行完成后，我们按合同要求支付了费用，并组织相关审计人员对采取工作进行审计，发现采购工作中的问题，并且总结经验和教训，对采购过程中的文档进行了加汇总，对供应商的绩效进行评价，更新了组织过程资产。

首先我们按照采购管理计划中的规定，在公司指定的网站上发布了招标公告，规定开标日期为25天后。其次，在开标前我们邀请了所有合格卖方召开了投标人会议，会上我们对显示屏的参数、性能要求等做了详细的描述，也澄清了招标文件中存在的疑问，并组织踏勘了项目现场。评标结束3天后，我们还与卖方进行了采购谈判，进一步明确了合同的条款，比如考虑到项目资金限制平衡和显示屏的质量问题，我们商定货品验收后支付合同款的50%，使用2个月之后无质量问题，再支付剩余的50%，显示器要求合同签订后30天内到货，卖方提供安装大屏服务等内容。