信息系统项目管理师历年论述题Word格式文档下载.docx
《信息系统项目管理师历年论述题Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理师历年论述题Word格式文档下载.docx（27页珍藏版）》请在冰点文库上搜索。
（4）修改完成后不进行验证则难以确认变更是否正确实现，为变更付出的工作量也无法得到承认。
（5）未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量。
变更管理的基本流程是：
（1）变更申请。
应记录变更的提出人、日期、申请变更的内容等信患。
（2）变更评估。
对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
（3）变更决策。
由具有相应权限的人员或机构决定是否实施变更。
（4）变更实施。
由管理者指定的工作人员在受控状态下实施变更。
（5）变更验证。
由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
（6）沟通存档。
将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。
如提出的变更在决策时被否决，其初始记录也应予以保存。
试题三
（l）合同中缺乏以下内容：
·
项目目标中关于产品功能和交付物组成的清晰描述。
项目验收标准、验收步骤和方法（或流程）。
对客户的售后服务承诺。
（2）项目实施过程控制中出现的问题：
在项目实施过程中没有及时将项目绩效报告递交给客户，因此客户对项目进展和质量状况不了解。
没有让客户及时对阶段成果签字确认。
（3）由于没有售货服务的承诺，客户担心没有后续服务保证。
（4）合作氛围不良，客户存在某种程度的抵触情绪，双方缺乏信任感，客户对项目质量信心不足，怕承担责任，因此不愿签字。
问题二：
根据项目现状，需要采取补救措施，加强沟通以解决问题。
（l）就项目验收标准和客户达成共识，确定哪些主要工作完成即可通过验收。
（2）就项目验收步骤和方法与客户达成共识。
（3）就项目已经完成的程度让用户确认。
例如出具系统试用报告，请客户签字确认。
（4）向客户提出明确的服务承诺，使客户没有后顾之忧。
问题三：
（l）项目合同中要规定项目成果的正式验收标准、验收步骤、验收流程和运营维护恶务承诺等内容。
（2）加强项目执行过程中的控制。
（3）加强变更控制。
包括制定变更控制流程，按流程进行变更的评估、审核、实施、记录、确认等工作。
（4）加强项目沟通管理。
包括及时向客户提供项目绩效报告，让客户了解项目进展。
设置对阶段性成果的验收，并让客户对阶段性成果进行签字确认。
项目文档要齐全，使项目进展有据可查。
（5）加强计划执行的控制。
制订详尽的项目管理计划（包括进度管理计划、成本管理计划等各分项计划），按计划实施和检查。
（6）项目经理还应注重跟客户相处的技巧，努力促成双方的良好合作氛围。
2005年下项目管理师
（l）销售部没有及时让软件开发部参与项目早期工作，需求分析耗时过长。
（2）项目经理经验不足，进度估算不准确。
（3）项目资源配置不足，缺乏专门的系统分析和设计人员。
（4）工作安排没有充分利用分配的项目资源，资源有闲置。
（5）在安排进度时可能未考虑法定节假日的因素。
（l）向职能经理申请增加特定资源，特别是要增加系统分析设计人员。
（2）临时加班／赶工，尽可能补救耽误的时间或提升资源的利用效率。
（3）将部分阶段的工作改为并行进行。
（4）对后续工作的工期重新进行估算，并考虑节假日问题，修订计划，尽量留有余地。
（5）加强沟通，争取客户能够对项目范围以及需求、设计、验收标准进行确认，避免后期频繁出现变更。
（6）加强对阶段工作的检查和控制，避免后期出现返工。
此外，如有可能还可采取外包和缩减范围等办法，不过不建议在本案例中采用。
进度／时间管理的过程：
（l）活动定义：
活动定义把工作包进一步分解为活动，以方便进度管理。
活动定义的方法有分解、模扳、专家判断等，主要输出是项目活动清单。
（2）活动排字：
即确定各活动之间的依赖关系，并形成文档。
项目活动排字的工具和技术有前导图法、箭线图法、进度计划网络模板、确定依赖关系等，主要输出是项目计划网络图。
（3）活动资源估算：
活动资源估算包括决定需要什么资源（人力、设备、原料）和每一样资源应该手多少，以及何时使用资源来有效地执行项目活动。
它必须和成本估算相结合。
项目活动资源估算的工具和技术有专家判断法、替换方案确定、公开的估算数据、估算软件、自下而上的估算等，主要输出是活动资源需求。
（4）活动历时估算。
活动历时估算直接关系到各事项、各工作网络时间的计算和完成整个项目任务所需要的总时间。
项目活动历时估算的工具和技术有专家判断、类比估算法、基于定额的历时、历时的三点估算、预留时间、最大活动历时等，主要输出是定量的活动历时估算结果。
（5）制定进度计划。
制定进度计划就是决定项目活动的开始和完成的日期。
制定进度计划的工具和技术有关键路径法、进度压缩、仿真、资源平衡、关键链、项目管理软件、编码结构、所采用的日历、超前和滞后、计划评审技术等，主要输出是项目进度计划。
（6）进度控制。
项目进度控制是依据项目进度计划对项目的实际进展情况进行控制，使项目能够按时完成。
进度控制的工具和技术有进展报告、进度变更控制系统、绩效测量、项目管理软件、偏差分析、计划比较甘特图等，主要输出是进度计划（更新）、变更需求、建议的纠正措施、取得的教训。
资源对进度的影响：
问题一：
CV＝EV－AC＝54－68＝－14万元 SV＝EV－PV＝54－64＝－10万元 CPI＝EV/AC＝54/68＝0.794
SPI＝EV/PV＝54/64＝0.843
（1）缺乏对项目组成员的沟通需求和沟通风格的分析。
（2）缺乏完整的会议规程，会议目的、议程、职责不清，缺乏控制，导致会议效率低下，缺乏效果。
（3）会议没有产生记录。
（4）会议没有引发相应的行动。
（5）沟通方式单一。
（6）没有进行冲突管理。
（1）事先制定一个例会制度。
在项目沟通计划里，确定例会的时间，参加人员范围及一般议程等。
（2）放弃可开可不开的会议。
在决定召开一个会议之前，首先要明确会议是否必须举行，还是可以通过其他方式进行沟通。
（3）明确会议的目的和期望结果。
明确要开的会议的目的，是集体讨论一些想法、彼此互通信息，还是解决一个面临的问题。
必须要讨论出一个确定的解决方案。
（4）发布会议通知。
在会议通知中要明确：
会议目的、时间、地点、参加人员、会议议程和议题。
事先应明确会议议程和讨论的问题，可以让参会人员提前做准备。
（5）在会议之前将会议资料发到参会人员。
对于需要有背景资料支持的会议，应事先将资料发给参会人员，以提前阅读，直接在会上讨论，可以有效地节约会议时间。
（6）可以借助视频设备。
对于有异地成员参加或者需要演示的场合，可以借用一些必要的视频设备，可以使会议达到更好效果。
（7）明确会议规则。
指定主持人，明确主持人的职责，主持人要对会议进行有效控制，并营建一个活跃的会议气氛。
主持人要事先陈述基本规则。
主持人根据会议议程的规定控制会议的节奏。
保证每一个问题都得到讨论。
（8）会议后要总结，提炼结论。
主持人在会后总结问题的讨论结果，重申有关决议，明确责任人和完成时间。
（9）会议要有纪要。
如果将工作的结果、完成时间、责任人都记录在案，则有利于督促和检查工作的完成情况。
（10）做好会议的后勤保障。
很多会议兼有联络感情的作用，因此需要选择一个合适的地点，提供餐饮、娱乐和礼品，制定一个有张有弛的会议议程。
对于有客户或合作伙伴参加的会议更要如此。
（1）首先应对项目组成员进行沟通需求和沟通风格的分析。
（2）对于具有不同沟通需求和沟通风格的人员组合设置不同的沟通方式。
（3）除了项目例会之外，可以通过电话、电子邮件、项目管理软件、OA软件等工具。
（4）正式沟通的结果应形成记录，对于其中的决定应有人负责落实。
（5）可以引入一些标准的沟通模板。
（6）在项目组内培养团结的氛围并注意冲突管理。
2006年下项目管理师
结合题目的出题方向，并对题干进行分析，可以得出题目场景下主要存在以下多方面的问题：
（1）缺乏项目整体管理，尤其是没有进行整体问题分析，并制定整体计划。
（2）缺乏整体变更控制流程，从而导致变更过程混乱。
（3）缺乏项目干系人之间的沟通，致使项目绩效信息不畅。
（4）没有配置管理规划，缺乏整体版本管理，配置标识无序。
（5）没有整体过程控制，缺乏单元接口测试和集成测试，以至于在系统集成时在发现问题
配置管理的主要工作有：
（1）制定配置管理计划。
确定方针，分配资源，明确职责，计划培训，确定干系人，制定配置识别准则、制定基线计划、配置库备份计划、变更控制流程和审批计划。
（2）识别配置项。
为配置项分配唯一标识，明确配置项特征，记录配置项进入时间等。
（3）建立配置管理系统。
建立分级的配置管理机制。
（4）建立基线。
获得授权，建立和发布基线，形成文件，使基线可用。
（5）建立配置库。
建立动态库、受控库和静态库。
（6）配置变更控制流程。
包括配置变更申请、变更方案的评审
（7）配置审计。
包括功能配置审计和物理配置审计
（8）配置状态统计。
统计配置项的各种状态，并使之可用
针对题目场景，应该保护已有工作成果，并从以下各方面采取补救措施：
（1）根据项目目前状态，建立或调整基线。
（2）建立统一的变更控制流程，使所有变更都按照同一策略进行实施，保证变更有序。
（3）梳理各个配置项及其版本演化过程，并对各个配置项进行双向跟踪，确保需求和产品的一致性。
（4）做好项目整体规划，加强单元接口测试和系统集成测试。
（1）由于乙方对项目干系人及其关系分析不到位，缺乏足够的信息来源，范围定义不全面、不准确。
（2）缺乏客户参与。
（3）甲方没有对各部门的需求及其变更进行统一的组织和管理。
（4）缺乏变更的接受或拒绝准则。
（5）合同没有定好，没有就具体完成的工作形成明晰的条款。
（6）双方没有就项目范围达成一致认可或承诺。
（7）缺乏项目全生命周期的范围控制。
（1）合同谈判阶段：
取得明确的工作说明书或更细化的合同条款。
在合同中明确双方的权利、义务，尤其变更问题的约定。
确保双方对项目合同的理解失一致的。
（2）计划阶段：
编制项目范围说明书。
创建WBS。
制定项目范围管理计划。
（3）执行阶段：
加强对WBS的跟踪和记录。
建立通畅的沟通渠道。
执行变更控制系统。
加强范围确认。
（1）合同确定了信息系统实施和管理的主要目标，是合同双方在工程中各种经济活动的依据。
（合同规定了双方的经济关系。
合同规定了双方在合同实施过程中的经济责任、利益和权利。
合同是监理的基本依据。
利用合同可以对工程进度、质量和成本实施管理和控制。
（2）
详细范围说明书描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
表明项目干系人之间就项目范围所达成的共识。
描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。
使项目团队能开展更详细的规划，并可在执行过程中指导项目团队的工作。
它还为评价变更请求或额外工作是否超出项目边界提供基准
关键路径是ACDGH
FFB=6FFC=0FFE=5
关键路径是ACDFH，43days
2007年下项目管理师
（1）沟通，强调该项目对系统集成商B的意义，提高该项目优先级。
例如使用开会这种方式，争得相关部门的建议、支持与承诺。
（2）从现有的资源和实际情况出发，优化网络图，例如重排活动之间顺序，压缩关键路径长度。
（3）增加资源，或者使用经验丰富的员工。
（4）子任务并行、内部流程优化。
（5）尽可能地调配非关键路径上的资源用于关键路径上的任务。
（6）优化外包、采购等环节并全程监控。
（1）目前系统集成商B实施项目的组织方式是职能式的。
（2）系统集成商B实施项目的组织方式应该改进为矩阵式。
（3）最好的办法是项目下阶段人员提前介入到前一阶段，如实施阶段的项目经理正式参与售前工作。
也可选择做好各流程间交接工作，如实施与售后服务之间的技术交底。
（4）委托、分包给当地有相应资质的集成商，或在当地招人。
如果材料或服务在当地获得可降低成本，则尽量在当地采购。
尽量压缩人员差旅成本。
使用虚拟远程的沟通手段。
（1）与客户高层继续沟通，了解客户对项目实施情况的反映，维护客户关系，发掘新的项目机会。
（2）参加周例会，或至少每周收一次周报以了解项目的进展和问题。
（3）参与可能发生变更的前期评审工作。
（4）负责或者协助收款（有时商务部负责收款，售前协助）。
（1）自己内部管理有问题、至少监管缺位或不得力。
（2）系统集成商B没有或极少与客户进行直接沟通。
（3）没建立现场管理制度，或者现场管理制度不严密不明确，或现场管理制度执行不力。
（4）总承包商与分包商责任不是十分清楚。
（5）客户从总承包商或其他承包商那里获得的信息有失真。
总承包商报告渲染了问题，推卸了责任。
（6）客户自己本身的原因如资金、管理水平。
（7）可能本项目的监理工作没有到位。
（1）承建方要认识到位，承建方和监理方不是对立关系，他们有共同的目标：
把项目搞好。
（2）双方都采用项目管理的方法，承建方协助和配合监理方对项目的"
四控三管一协调"
。
（3）中间成果的评审。
（4）周期性的沟通。
（5）突发事件的协调。
（1）做好干系人分析，调研各集成商的沟通需求。
（2）发挥总承包商的牵头作用和监理方的协调作用。
（3）对共用资源的可用性进行分析，引入资源日历。
（4）解决冲突，包括干系人对项目期望之间的冲突、资源冲突等。
（5）建立健全的项目管理制度并监管其执行。
（6）采用项目管理信息系统。
（1）承建单位没有对项目进行统一管理。
（2）承揽了新的更重要的项目。
（3）项目经理忽视了单位内部可能存在的竞争性项目的出现所带来的风险。
（4）可能项目绩效不好，失去了单位有关方面额支持。
（5）有重要干系人内定项目暂停的可能。
（1）评估项目、反映情况、沟通说服、争取支持。
（2）让其他非涉密项目去社会上招聘人员。
（3）剩余较少项目工作，应该说服原来团队成员赶工以期完成项目。
（1）建议单位统一管理所有项目核资源，制定资源在项目之间的分配原则。
（2）定期检查项目执行情况，根据项目进展核企业整体绩效，重新排定项目的优先顺序。
（3）外包。
（4）必要时，增加资源。
（5）建立项目管理体系，设立项目管理办公室，统一管理单位所有项目。
2008年上项目管理师
（1）没有请技术部门参加项目启动会议。
（2）没按照变更管理流程变更。
（3）没有好的评审机制。
（4）整体管理做的不好。
（5）没有经验教训的总结，积累。
（1）改进组织形式，明确团队和职能部门的协作。
（2）加强变更管理。
（3）明确可交付物。
（4）培训学习项目管理知识，提高管理能力。
（5）做好经验的总结与归纳。
（1）建立企业级的项目管理体系和工作规范，管理上不乱。
（2）加强质量管理，采用评审机制。
（3）加强项目经验的收集，整理，共享知识。
（4）引入项目管理工具。
（5）管理好工作记录。
2008年下项目管理师
（1）采取的奖励制度没有得到公司及领导的认可。
（2）钱某的项目管理风格与公司领导的风格不同。
（3）没有对员工进行培训。
（4）没有配备合适的人员。
（5）激励风格与实际制度相违背。
（1）加强培训。
（2）加强团队建设的活动。
（3）形成共同的行为准则。
（4）争取公司认可的奖励机制。
（5）加强沟通。
（1）加强员工技能、管理能力的培训，提高工作水平。
（2）招聘掌握技能的人员加入项目团队。
（3）做好风险分析，并采取应对措施。
（4）采用项目管理管理系统，提高工作效率。
（1）张工没有为项目建立一个可行的质量管理计划，并积极的实施。
（2）仅仅向客户提交测试报告，没有全面的质量管理报告和相关绩效报告，容易让客户产生误解，并导致不必要的担心。
（1）质量方针。
（2）质量检验标准。
（3）质量管理人员与职责。
（4）质量管理的组织结构。
（5）质量管理所需的资源情况。
（6）质量管理的方法、工具和措施。
（7）质量评审机制。
（1）制定项目管理计划，并投入实践。
（2）建立质量管理体系，并有效地实施。
（3）采用质量管理的工具、方法，对质量管理进行有效控制。
（4）采取有效的质量预防措施。
质量控制与质量保证的主要区别与联系。
（1）质量控制与质量保证都是以质量管理计划为依据的。
质量保证实质上是对质量规划和质量控制过程的控制。
（2）质量控制与质量保证的目标是达到质量管理的目标。
（3）质量保证的输出是下一阶段质量控制的输入。
（4）一定时间内的质量控制的结果也可当质量保证的审计对象。
质量保证的成果又可指导下一阶段的质量工作，包括质量控制和质量的改进。
（5）质量保证一般是每隔一定时间，主要通过系统的质量审计来保证项目的质量。
（质量保证按照质量管理计划正确地做）。
（6）质量控制是实施监控项目的具体结果，以判断它们是否符合相关质量标准，制定有效的方案，以消除产生质量问题的原因。
（质量控制检查是否做的正确，并纠正。
）
造成该局面的原因：
（1）对该项目缺少可行性分析。
（2）在项目前期没有作充分的调研。
（3）对于该技术不是了解。
可能存在的风险
（1）技术风险：
还没有对应的标准。
（2）政策风险：
属于无照运营，非法行为。
（3）市场风险：
采购方面存在风险，属于山寨产品，缺少后续保障，还有系统运行上的风险，因为运营商会倒闭等等。
可行性分析的内容：
（1）技术可行性：
通过确定项目的总体和详细目标，范围，总体结构和组成。
（2）经济可行性：
（3）操作可行性：
（4）其它可行性：
如社会可行性、法律可行性等。
为走出这样的局面应该采取的措施：
（1）停止放号，系统运行只局限在本公司运行。
（2）同时咨询是否有相关法律（政策）的限制。
（3）改进技术方案，（增加无线发射点，扩大接入能力和宽带，扩大范围，降低噪声）
（4）寻找可替代的方案。
2009年上项目管理师
（1）制定的WBS不正确质量控制不严。
（2）进度计划不准。
（3）评审不认真。
（4）沟通不及时。
（1）识别和确认项目阶段和主要可交付物。
（2）分解并确认每一组成部分是否分解得足够详细。
（3）确认项目主要交付成果得组成要素。
（4）核实分解得正确性。
（1）获取项目工作绩效信息。
（2）与项目范围基准相比较。
（3）分析偏差。
（4）范围变更管理。
（1）确定进度是否已发生变化，具体工具包括：
横道图比较法、S型曲线比较法、香蕉曲线图法。
（2）对造成进度变化的因素施加影响，以保证这种变化朝着有利的方向发展，包括：
组织措施、技术措施、合同措施、经济措施、管理措施。
（3）在变化实际发生和正在发生时，对这种变化实施管理：
变更管理流程。
（1）在项目计划阶段，没有制定好的人员配备计划。
（2）项目经理没有分析到在弱矩阵环境下的人力资源管理风险。
（3）由于M隶属于研发部，他是一个风险源，在这一风险真实发生时，没有应对措施。
（4）没有找到针对M的冲突解决方法。
（5）没有同公司高层和职能进行良好沟通，说明M对项目实施的重要程度
参考问题二答案，改变说法。
（1）改进项目组织形式。
（2）建立组织管理体系。
（3）采取好的冲突解决方法。
（4）加强团队建设。
（5）通过培训，提高团队人员工作能力。
（1）组织项目管理不规范，导致项目没有尽早介入项目。
（2）沟通渠道不畅。
（3）需求开发不完善。
（1）制定需求管理计划。
（2）获得对需求的理解－确认需求。
（3）获得对需求的承诺。
（4）管理需求变更。
（5）维护对需求的双向跟踪。
（6）识别项目工作与需求之间的不一致。
（1）需求获取。
（2）需求分析。
（3）需求定义。
（4）需求确认。
2009年下项目管理师
（1）绩效报告。
（2）质量保证。
（3）测试。
（4）评审。
（5）确认。
（6）风险应对与监控。
（1）采用不同方法识别风险。
（2）从项目阶段识别风险。
（3）记录风险。
（1）产品替代。
（2）技术攻关。
（3）新方案。
（1）并行施工和压缩进度会带来风险，缺乏相应的风险控制。
（2）项目实施过程中，缺少对已完成可交付物的范围确认。
（3）由于原有计划的变更，缺少相应的沟通管理计划的变更。
（4）
升级会员 