信息系统项目管理案例分析指南

信息系统项目管理案例分析指南 目录 第 1 章 项目整体管理案例 1.1 项目开始走向混乱 1.1.1 案例场景 1.1.2 案例分析 1.1.3 参考答案 1.2 谢经理项目的艰难处境 1.2.1 案例场景 1.2.2 案例分析 1.2.3 参考答案 1.3 邓工项目的可行性研究 1.3.1 案例场景 1.3.2 案例分析 1.3.3 参考答案 1.4 小丁的项目应如何启动 1.4.1 案例场景 1.4.2 案例分析 1.4.3 参考答案 1.5 资源冲突管理的问题 1.5.1 案例场景 1.5.2 案例分析 1.5.3 参考答案 1.6 “无线通”项目的问题 1.6.1 案例场景 1.6.2 案例分析 1.6.3 参考答案 第 2 章 项目范围管理案例 2.1 范围管理的内容 2.1.1 案例场景 2.1.2 案例分析 2.1.3 参考答案 2.2 创建工作分解结构 2.2.1 案例场景 2.2.2 案例分析 2.2.3 参考答案 2.3 需求管理对范围管理的影响 2.3.1 案例场景 2.3.2 案例分析 2.3.3 参考答案 2.4 范围管理与说“不” 2.4.1 案例场景 2.4.2 案例分析 2.4.3 参考答案 信息系统项目管理师 /rk/isenfd.htm 2.5 各阶段项目范围管理 2.5.1 案例场景 2.5.2 案例分析 2.5.3 参考答案 第 3 章 项目时间管理案例 3.1 关键路径与工期优化 3.1.1 案例场景 3.1.2 案例分析 3.1.3 参考答案 3.2 双代号网络图计算 3.2.1 案例场景 3.2.2 案例分析 3.2.3 参考答案 3.3 单代号网络图计算 3.3.1 案例场景 3.3.2 案例分析 3.3.3 参考答案 3.4 网络图绘制 3.4.1 案例场景 3.4.2 案例分析 3.4.3 参考答案 3.5 甘特图与网络图应用 3.5.1 案例场景 3.5.2 案例分析 3.5.3 参考答案 3.6 项目进度为什么失控 3.6.1 案例场景 3.6.2 案例分析 3.6.3 参考答案 3.7 资源配置对进度的制约 3.7.1 案例场景 3.7.2 案例分析 3.7.3 参考答案 3.8 工期估算的技术和方法 3.8.1 案例场景 3.8.2 案例分析 3.8.3 参考答案 3.9 网络计划图技术的应用 3.9.1 案例场景 3.9.2 案例分析 3.9.3 参考答案 第 4 章 项目成本管理案例 4.1 复利计算 4.1.1 案例场景 信息系统项目管理师 /rk/isenfd.htm 4.1.2 案例分析 4.1.3 参考答案 4.2 净现值与投资评估方法 4.2.1 案例场景 4.2.2 案例分析 4.2.3 参考答案 4.3 净现值与投资回报率计算 4.3.1 案例场景 4.3.2 案例分析 4.3.3 参考答案 4.4 挣值分析 4.4.1 案例场景 4.4.2 案例分析 4.4.3 参考答案 4.5 完工估算 4.5.1 案例场景 4.5.2 案例分析 4.5.3 参考答案 4.6 赶工成本与工期优化 4.6.1 案例场景 4.6.2 案例分析 4.6.3 参考答案 4.7 决策树与成本决策 4.7.1 案例场景 4.7.2 案例分析 4.7.3 参考答案 第 5 章 项目质量管理案例 5.1 客户为什么没有信心 5.1.1 案例场景 5.1.2 案例分析 5.1.3 参考答案 5.2 如何提高信息系统项目质量 5.2.1 案例场景 5.2.2 案例分析 5.2.3 参考答案 5.3 项目质量管理的启动 5.3.1 案例场景 5.3.2 案例分析 5.3.3 参考答案 5.4 质量控制 5.4.1 案例场景 5.4.2 案例分析 5.4.3 参考答案 5.5 质量保证 信息系统项目管理师 /rk/isenfd.htm 5.5.1 案例场景 5.5.2 案例分析 5.5.3 参考答案 5.6 信息系统监理与质量管理 5.6.1 案例场景 5.6.2 案例分析 5.6.3 参考答案 第 6 章 项目人力资源管理案例 6.1 项目为什么失控 6.1.1 案例场景 6.1.2 案例分析 6.1.3 参考答案 6.2 项目经理的素质 6.2.1 案例场景 6.2.2 案例分析 6.2.3 参考答案 6.3 项目中的新技术要求 6.3.1 案例场景 6.3.2 案例分析 6.3.3 参考答案 6.4 人员流失对项目的影响 6.4.1 案例场景 6.4.2 案例分析 6.4.3 参考答案 6.5 如何处理项目中存在的不同派别 6.5.1 案例场景 6.5.2 案例分析 6.5.3 参考答案 6.6 开放的管理会使项目出现危机 6.6.1 案例场景 6.6.2 案例分析 6.6.3 参考答案 6.7 成功的项目得不到员工的认可 6.7.1 案例场景 6.7.2 案例分析 6.7.3 参考答案 6.8 如何避免员工被猎 6.8.1 案例场景 6.8.2 案例分析 6.8.3 参考答案 第 7 章 项目沟通管理案例 7.1 提高项目例会的效率 7.1.1 案例场景 7.1.2 案例分析 信息系统项目管理师 /rk/isenfd.htm 7.1.3 参考答案 7.2 与多个单位进行沟通 7.2.1 案例场景 7.2.2 案例分析 7.2.3 参考答案 7.3 面对频繁的需求变更 7.3.1 案例场景 7.3.2 案例分析 7.3.3 参考答案 7.4 沟通的不同风格 7.4.1 案例场景 7.4.2 案例分析 7.4.3 参考答案 7.5 在沟通中获得正确的需求 7.5.1 案例场景 7.5.2 案例分析 7.5.3 参考答案 7.6 在项目中进行高效的沟通 7.6.1 案例场景 7.6.2 案例分析 7.6.3 参考答案 7.7 进行有效的信息分发 7.7.1 案例场景 7.7.2 案例分析 7.7.3 参考答案 第 8 章 项目风险管理案例 8.1 信息系统项目中的风险 8.1.1 案例场景 8.1.2 案例分析 8.1.3 参考答案 8.2 企业信息化建设中的风险管理 8.2.1 案例场景 8.2.2 案例分析 8.2.3 参考答案 8.3 软件项目开发中的风险管理 8.3.1 案例场景 8.3.2 案例分析 8.3.3 参考答案 8.4 决策树分析技术 8.4.1 案例场景 8.4.2 案例分析 8.4.3 参考答案 8.5 风险应对措施 8.5.1 案例场景 信息系统项目管理师 /rk/isenfd.htm 8.5.2 案例分析 8.5.3 参考答案 8.6 风险概率评估 8.6.1 案例场景 8.6.2 案例分析 8.6.3 参考答案 第 9 章 项目采购管理案例 9.1 分包合同与索赔 9.1.1 案例场景 9.1.2 案例分析 9.1.3 参考答案 9.2 招标投标流程 9.2.1 案例场景 9.2.2 案例分析 9.2.3 参考答案 9.3 合同与范围的关系 9.3.1 案例场景 9.3.2 案例分析 9.3.3 参考答案 9.4 选择合同类型 9.4.1 案例场景 9.4.2 案例分析 9.4.3 参考答案 9.5 供方选择 9.5.1 案例场景 9.5.2 案例分析 9.5.3 参考答案 9.6 外包管理 9.6.1 案例场景 9.6.2 案例分析 9.6.3 参考答案 第 10 章 项目变更管理案例 10.1 项目变更管理流程 10.1.1 案例场景 10.1.2 案例分析 10.1.3 参考答案 10.2 项目合同变更管理 10.2.1 案例场景 10.2.2 案例分析 10.2.3 参考答案 10.3 项目变更失控的原因 10.3.1 案例场景 10.3.2 案例分析 10.3.3 参考答案 信息系统项目管理师 /rk/isenfd.htm 10.4 项目需求变更管理 10.4.1 案例场景 10.4.2 案例分析 10.4.3 参考答案 10.5 项目分包中的变更管理 10.5.1 案例场景 10.5.2 案例分析 10.5.3 参考答案 10.6 监理项目中的变更管理 10.6.1 案例场景 10.6.2 案例分析 10.6.3 参考答案 10.7 版本混乱的原因 10.7.1 案例场景 10.7.2 案例分析 10.7.3 参考答案 第 11 章 综合案例 11.1 项目收尾的问题 11.1.1 案例场景 11.1.2 案例分析 11.1.3 参考答案 11.2 系统集成的问题 11.2.1 案例场景 11.2.2 案例分析 11.2.3 参考答案 11.3 项目管理体系的建立 11.3.1 案例场景 11.3.2 案例分析 11.3.3 参考答案 11.4 软件开发模型的选择 11.4.1 案例场景 11.4.2 案例分析 11.4.3 参考答案 11.5 电子政务系统建设 11.5.1 案例场景 11.5.2 案例分析 11.5.3 参考答案 11.6 软件项目综合问题 11.6.1 案例场景 11.6.2 案例分析 11.6.3 参考答案 11.7 项目团队建设 11.7.1 案例场景 11.7.2 案例分析 信息系统项目管理师 /rk/isenfd.htm 11.7.3 参考答案 第 1 章 项目整体管理案例 项目的整体管理在项目管理的 9 个知识领域中处于核心位置，其功效就是用来整合其 它 8 个知识领域，项目经理则要起到关键性的组织、协调与管理作用，然而这并非易事， 许多 IT 项目经理在做项目时总感觉需要协调各种各样的资源，然而又似乎无从下手，一些 事情好象身不由己，无法控制。 项目整体管理是围绕项目管理计划的制订、执行和控制进行的，通过项目资源的整合 将项目所有的组成要素在恰当的时间、正确的地方、合适的人物结合在一起，以成功的完 成项目。 按照 PMBOK2004（Project Management Body of Knowledge 2004,项目管理的 知识体系 2004 版）中的定义，项目整体管理的过程包括：制订项目章程、制订项目范围 说明书（初步） 、制订项目管理计划、指导和管理项目执行、监督和控制项目工作、整体变 更控制和项目收尾。 1.1 项目开始走向混乱 阅读以下关于在信息系统项目管理过程中项目整体管理方面问题的叙述，回答问题 1 至问题 3,将解答填入答题纸的对应栏内。 1.1.1 案例场景 希赛集团下属飞达信息技术有限公司新接到一个有关电子政务公文流转系统的软件项 目，王工作为公司派出的项目经理，带领项目组开始进行项目的研发工作。 王工以前是一名老技术人员，从事 Java 开发多年，是个细心而又技术扎实的老工程师。 在项目的初期，王工制订了非常详细的项目计划，项目组人员的工作都被排得满满的，为 加快项目的进度，王工制订项目计划后即分发到项目组成员手中开始实施。然而，随着项 目的进展，由于项目需求不断变更，项目组人员也有所更换，项目组已经没有再按照计划 来进行工作，大家都是在当天早上才安排当天的工作事项，王工每天都要就工作安排焦头 烂额，项目正开始走向混乱的局面。 项目组中的一名技术人员甚至在拿到项目计划的第一天就说：“计划没有变化快，要计 划有什么用“, 然后只顾埋头编写自己手头的程序。 一边是客户在催着快点将项目完工，要尽快将系统投入生产；另一边是公司分管电子 政务项目的张总在批评王工开发任务没落实好。 【问题 1】 （8 分） 请用 400 字以内的文字，王工制订的项目计划应包括的主要内容。 【问题 2】 （8 分） 请用 400 字以内的文字，围绕项目计划来说明在王工在制订项目计划时出现的问题。 【问题 3】 （9 分） 如果你是王工，面对项目开始走向混乱的局面的情况，应当如何处理呢？ 1.1.2 案例分析 项目计划是项目管理的基础，项目管理中最重要的就是项目计划的工作，项目计划是 一个综合概念，凡是为实现项目目标而进行的活动都应该纳入到计划之中。 【问题 1】 项目计划的制订是贯穿这个项目生命周期的持续不断的工作，是利用其他计划编制过 程的结果，建立一份连贯性、一致性的文档，以指导项目实施和项目控制。项目计划过程 是一个反复的过程。一个详细的项目计划过程包括： 信息系统项目管理师 /rk/isenfd.htm （1）项目计划的定义，确定项目的工作范围。 （2）确定为执行项目而需要的工作范围内的特定活动，明确每项活动的职责。 （3）确定这些活动的逻辑关系和完成顺序。 （4）估算每项活动的历时时间和资源。 （5）制订项目计划及其辅助计划。 一般而言，项目计划可以包含如下要素： （1）项目范围计划：阐述进行这个项目的原因或意义，形成项目的基本框架，使项 目所有者或项目管理者能够系统、逻辑地分析项目关键问题及项目形成中的相互作用要素， 使项目干系人在项目开始实施前或项目相关文档编写以前，能够就项目的基本内容和结构 达成一致；项目范围说明应当形成项目成果核对清单，作为项目评估的依据，在项目终止 以后或项目最终报告完成以前进行评估，以此作为评价项目成败的依据；范围说明还可以 作为项目整个生命周期监控和考核项目实施情况的基础和项目其他相关计划的基础。 （2）项目进度计划：进度计划是说明项目中各项工作的开展顺序、开始时间、完成 时间及相互依赖衔接关系的计划。通过进度计划的编制，使项目实施形成一个有机的整体。 进度计划是进度控制和管理的依据，可以分为项目进度控制计划和项目状态报告计划。 （3）项目质量计划：质量计划针对具体待定的项目，安排质量监控人员及相关资源、 规定使用那些制度、规范、程序、标准。项目质量计划应当包括和保证与控制项目质量有 关的所有活动。 （4）项目资源计划：决定在项目中的每一项工作中用什么样的资源（人、材料、设 备、信息、资金等） ，在各个阶段使用多少资源。项目费用计划包括资源计划、费用估算、 费用预算。 （5）项目沟通计划：沟通计划就是制订项目过程中项目干系人之间信息交流的内容、 人员范围、沟通方式、沟通时间或频率等沟通要求的约定。 （6）风险计划：风险计划是为了降低项目风险的损害而分析风险、制订风险应对策 略方案的过程，包括识别风险、量化风险、编制风险应对策略方案等过程。 （7）项目采购计划：项目采购计划过程就是识别哪些项目需求应通过从本企业外部 采购产品或设备来得到满足。 （8）变更控制、配置管理计划：由于项目计划无法保证一开始就预测得非常准确， 在项目进行过程中也不能保证准确有力的控制，导致项目计划与项目实际情况不符的情况 经常发生，所以必须有效处理项目的变更。变更控制计划主要是规定变更的步骤、程序， 配置管理计划就是确定项目的配置项和基线，控制配置项的变更，维护基线的完整性，向 项目干系人提供配置项的准确状态和当前配置数据。 【问题 2】 制订项目计划的目的在于建立并维护项目各项活动的计划，项目计划其实就是一个用 来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。一个好的项 目计划可为项目的成功实施打下坚实的基础。 以下这些方法能有效的帮助项目经理制订项目计划。 （1）注意项目计划的层次性 项目计划的层次及其关系如图 1-1 所示。 图 1-1 项目计划的层次 高级计划，是项目的早期计划。高级计划应当是粗粒度的，主要是进行项目的阶段划 信息系统项目管理师 /rk/isenfd.htm 分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓 的人、财、物三个要素。 大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。详细计划要 确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，项目里 程碑。 如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发 组，二级计划是各开发组制订的适合自己开发组的计划。如果开发组还分了小组，可以有 小组的三级计划。 开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制订，个人计划要 尽量细化到工作单元和时间单元。 一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率的瓶颈。合理的 划分小组，减少组织的层次，有利于项目计划的制订和实施。较小的软件项目由于工期不 长，人员较少，只有两级计划（高级计划与低级计划）也是可行的。 （2）该详细的详细，该简略的就简略 项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工 的小项目，可能项目计划就四五页纸，包括一个 WBS（Work Breakdown Structure,工 作分解结构）和一个甘特图（Gantt Chart） 。一个需要五六十个人甚至上百人，要花上半 年或更长时间的大型 IT 项目则会有更多的项目计划内容。项目经理要按照项目的特定情况 量体裁衣，要强调项目计划的指导性。项目中的工作安排一定要责任到人。如果是多个人 共同完成的任务也要指定一位主要负责人，否则工作人员会操作不便，甚至互相推卸责任。 （3）制订的项目计划要现实 制订项目计划仅靠“个人经验“是不够的，不可能面面俱到，不要寄希望于“个人经验“. 解决的办法有两个方面： 一是充分鼓励、积极接纳项目干系人（包括客户、公司高层领导、项目组成员）来参 与项目计划的制订。应主动邀请客户和公司高层领导来共同讨论高级计划的制订。客户对 项目在现场的实施和系统应用将起到很好的促进作用。公司高层领导的参与将有利于项目 获得精神上和物质上的支持。制订二级、三级项目计划要与项目组成员互动，要强调项目 计划的现实性，不现实的项目计划不但不可能指导项目的实施，还可能成为项目成功的障 碍。当规划由一个人做出而由另一个人实施时，如果项目没有按时完成，会使得他们怀疑 项目计划的可行性，也会影响开发人员的士气。项目组内部人员的沟通亦很重要。项目经 理应当关注计划的制订工作中的气氛，在轻松的氛围中去融合开发人员的意见。可以让开 发人员对自己职责范围内的事提出建议的时间和资源，再作讨论约定。这样开发人员在主 观上会更加投入工作。客观上，开发人员的能力很难用时间及工作量来衡量，一名熟练的 Java 程序员比一名初学 Java 的程序员开发效率可能快上四五倍，因而安排的时间周期、 任务量当然要不一样。可以考虑召开一次专题讨论会，事先写出一个初稿，再各抒己见， 最后作出结论。 二是充分利用历史数据。历史数据是宝贵的财富，是可复用的资源。不仅要注意积累 这些数据，也要学会从中提炼出可以为己所用的数据。如：项目计划的模板、计划的资源 数据等。成熟的项目开发组织会将历史的数据保留并作一些分析，形成一些经验计算公式、 实用的文档模板等。需要特别提到的是，有的软件项目在失败之后，项目组人员一般很不 情愿再度问津此事，一谈到做过的失败的项目就唯恐避之不及，其实，失败的项目对项目 研发具有重要的参考价值。 有必要在每做完一个项目后认真的进行总结。这是项目可持续发展的必要，也是对项 信息系统项目管理师 /rk/isenfd.htm 目和项目组成员的尊重。当前项目的经验对其它项目是有很好的借鉴意义的，特别是对类 似的软件项目，在管理上、技术上、开发过程上都是一笔财富。不仅要对项目的程序代码 存储，所有相关文档资料（包括合同、开发文档、总结文档等）也要归档。 （4）重视与客户的沟通 与客户的沟通是很重要的。不必害怕客户知道我们的开发计划，特别是项目进度情况， 应当和客户共享这些信息。 首先，客户会提出一些对项目时间、进度、效果上的要求，这些要求往往经不起推敲， 有的还带有较强的政策性。例如：在某单位的人事管理信息系统的开发中，客户方对时间 上的这个要求，是单位领导开会集体决定并形成了文件的，但是，经过认真的需求调研， 做出项目进度的粗计划和部分的二级计划后，发现按客户方要求的三个月时间是难以实现 的。这时就需要“说服“, 可以把做出的调研文档和项目计划摆出来与客户讨论，并最终使项 目的开发时间适当延长。实际上，项目组和客户的目的是一致的，所以对于合理的项目进 度客户是会理解与支持的。 其次，项目组有义务要让客户知道项目的计划，这样才能让客户实际上主动、积极参 与项目，达到项目的最终目标。项目计划取得双方签字认可是非常重要的。客户可能不愿 意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非 正式的，但留下了项目工作的痕迹。应该让客户清楚签字意味着双方对项目计划的认同。 双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促 和促进的作用。 在本案例中，王工制订了详细的项目计划，将项目组人员的工作排得满满的，在没有 和项目组人员商量的情况即下发项目计划并实施，此举不妥。制订项目计划时，需要取得 项目组人员的支持、理解，并且需要注意在项目的开始阶段往往需要的是粗粒度的，并且 是现实的项目计划。 项目计划对于项目的实施非常重要，在制订时也需要和客户、公司领导及时沟通，以 取得他们的支持。而王工对于项目运作的紧张局面既没有向公司领导汇报，也没有向客户 解释，只是一个人默默地将问题埋在心里，而采取了每天早上安排工作的临时性解决办法， 治标没有治本。 【问题 3】 王工作为项目经理应当清醒地意识到项目开始出现混乱，一是制订项目计划时不妥； 二是项目的变更没有控制好，王工需要采取一些有针对性的措施。 项目的不确定性因素导致了项目的进展未必象想象中或计划中的那样顺利，而当这种 不确定性变得明确且和当初的预测不一致的时候，就会导致项目出现变更。一般来说，项 目的目标是项目所有活动的最终判断准则。也就是说我们必须关注那些可能会引起项目目 标变化的信息。 为了对项目变更进行控制，应由项目实施组织、项目管理班子或两者共同建立变更控 制系统。变更控制系统就是一套事先确定的修改项目文件或改变项目活动时应遵循的程序， 其中包括必要的表格或其他书面文件，责任追踪和变更审批制度、人员和权限。变更控制 系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。 变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统 应当同项目管理信息系统一起通盘考虑，形成整体。 整体变更就是影响项目整体和贯穿整个项目过程的变更。整体变更控制的目的有三个： （1）查明项目进行过程中发生的变化是否构成变更。 （2）对造成变更的因素施加影响。 信息系统项目管理师 /rk/isenfd.htm （3）当变更实际出现时，设法处理之。 整体变更控制就是协调贯穿整个项目过程的变更。例如，可交付成果的技术要求说明 书发生的变更，若影响到项目范围，进而影响到费用、进度、质量、风险或其他方面，则 该变更就是整体变更，应当通过范围变更控制系统处理。 整体变更控制的依据是项目计划、进展报告和变更请求。项目班子成员或项目干系人 的变更请求可能会以多种形式提出。但除非特殊情况，只有书面提出者，才能受理。 整体变更控制的工具就是上面提到的变更控制系统。整体变更控制的结果应当有项目计划 的更新，采取将项目未来预期进展控制在项目计划范围内的纠正行动并吸取的教训。 1.1.3 参考答案 【问题 1】 王工编制的项目计划应包括： （1）项目总计划（包括范围计划、工作范围定义、活动定义、资源需求、资源计划、 活动排序、费用估算、进度计划以及费用计划） 。 （2）项目辅助计划（质量计划、沟通计划、人力资源计划、风险计划、采购计划等） 。 【问题 2】 王工在制订项目计划时，存在如下的问题： （1）初期的项目计划粒度过小，没有把握好项目计划的层次性。 （2）制订项目计划时没有和客户、公司领导和项目组人员进行及时沟通。 （3）制订的项目计划不切实际。 【问题 3】 王工可采取如下的措施： （1）重新制订一份较粗粒度的、切实可行的整体项目计划，而由项目组人员根据整 体项目计划来制订个人的项目工作计划。 （2）将项目计划与项目组人员、公司领导、客户进行沟通，并及时修正，必要时还 可以开会议讨论。 （3）在项目组中建立起变更控制系统。 1.2 谢经理项目的艰难处境 阅读以下关于在信息系统项目管理过程中有关项目整体管理方面问题的叙述，回答以 下问题,将解答填入答题纸的对应栏内。 1.2.1 案例场景 谢经理是学赛信息技术公司软件开发部的项目经理，6 个月前他被公司派往新动力贸 易集团有限公司（以下简称新动力）现场组织开发财务管理信息系统，并担任项目经理。 谢经理已经领导开发过好几家公司的财务系统，并已形成较为成熟的财务管理软件产品， 所以他认为此次去后应当只要适当地做一些二次开发，并根据用户需求作少量的新功能开 发即可大功告成。 谢经理满怀信心地带着他的项目团队进驻新动力了，谢经理和项目团队在技术上已经 历过多次考验，他们在 3 个月的时间就将系统开发完毕，项目很快进入了验收阶段。可是 新动力分管财务的陈总认为，一个这么复杂的财务系统在短短的 3 个月的时间里就完成了， 这在新动力的 IT 项目中还是首次，似乎不太可能。他拒绝在验收书上签字，并要求财务部 的刘经理和业务人员认真审核集团公司及和各个子公司的财务管理上的业务需求，并严格 测试相关系统的功能。 财务部的刘经理和相关人员经过认真审核和测试，发现系统开发基本准确，但实施起 信息系统项目管理师 /rk/isenfd.htm 来比较困难，因为业务流程变更较大。这样一来，又过去了 1 个月，新动力的陈总认为系 统还没有考虑集团公司领导对财务的需求，并针对实施较困难的现状，要求项目组从集团 公司总部开始，一家一家子公司地逐步推动系统的使用。 谢经理答应了新动力陈总的要求，开始先在集团公司总部实施财务系统。可是 2 个月 过去了，连系统都没有安装成功。集团公司信息中心的人员无法顺利的购买服务器，因为 这个项目没有列入信息部门的规划；财务部门的人员说项目在集团中都推不动，何必再上。 谢经理一筹莫展：“我该如何让项目继续走向成功？“眼看半年过去了，项目似乎没有了终 结之日，更不用说为学赛信息技术公司带来效益了。 面对项目的艰难处境，谢经理和他的团队认真分析了他们在项目的整体管理中所做的 工作，发现了项目中存在的主要问题，主动积极的采取了应对的措施，最终圆满完成了整 个项目的开发和应用。 【问题 1】 （6 分） 请用 200 字以内的文字，描述项目干系人中需要重点关注的角色。 【问题 2】 （6 分） 项目干系人分析是项目整体管理中的一项重要工作，请用 400 字以内的文字，说明如 何进行项目干系人分析。 【问题 3】 （6 分） 谢经理和他的团队认真分析了他们在项目的整体管理中所做的工作，发现了项目中存 在的主要问题，请用 400 字以内的文字，描述谢经理发现的主要问题。 【问题 4】 （7 分） 面对项目的艰难处境，如果你是谢经理，你该如何做呢？请用 400 字以内容文字描述。 1.2.2 案例分析 本题是一道关于项目整体管理中对项目关系人进行分析的试题，在项目管理中，识别 项目干系人，特别是关键的项目干系人，是一件很重要的工作。 【问题 1】 项目干系人是指与项目相关的人，项目干系人的范围较大，项目组内部与外部的人员 都会涉及，但需要重点关注以下角色： （1）客户。客户是提出项目需求的个人或组织，一般是指项目的采购方。从商品交 易的角度来看，“客户就是上帝“;同时，客户也是承包方的“衣食父母“, 即项目标的的给予者。 因此，客户成为承包方需要关注的第一对象。 （2）用户。用户是使用项目产品的人或组织，需要分析用户的使用感受，改进意向 等。 （3）项目投资人。为项目提供现金或实物等财力资源的组织或个人。 （4）项目经理。项目经理是项目的关键人物，对项目组内部来说他是领导者，承担 着项目成败的主要责任；对项目组外部来说他是外交官，起着重要的协调作用。 （5）项目组成员。项目组成员是让项目落到实处，分担项目任务的人员。项目的成 功很大程度上取决于项目团队的战斗力。 （6）高层管理人员。项目经理能否成功地领导项目的一个非常重要的因素，就是他 们从高层管理层获得支持的程度。 （7）反对项目的人。反对项目的人对项目的功能构成威胁，这种人员往往会让项目 走向成功的另一面-失败。如：采购方单位有高层管理人员反对项目的实施，项目内部成 员有反对现有技术路线的，因此需要特别关注。 （8）施加影响者。能够对项目施加影响的人可能对项目产品的取得和使用没有直接 信息系统项目管理师 /rk/isenfd.htm 的关系，但是因其在客户或用户组织中的地位而能够对项目的进程产生积极或消极的影响。 在 IT 项目中，要特别注意区分“客户“ 与“用户“这两种角色。对待不同的角色需要使用 不同的方法，但实际项目中往往容易混淆起来。一般地采购方就是使用者，而且多数情况 下采购方的人员参与了项目并提出需求，给人的直接感觉他就是使用项目产品的人。“客户 “与“用户“这两种角色对于人或组织，有时是相同的对象，有时是不同的，他们的主要区别 在于客户是具体阐明项目高层次概念和主要内容，并决定支付款项的数额和方式的决策者； 用户是提出系统功能和非功能需求，并最终使用系统的人，但他们往往对应该支付的费用 没有决定权。 高层管理人员的作用往往被项目经理和项目团队所忽视，特别是用户方的高层管理人 员，有的项目经理直到项目结束还不曾谋面，更不要说主动获得他们的支持了。因为有的 项目经理天天只想着如何做好项目中的工作，有问题自己如何去解决。然而，没有高级管 理层的参与支持，许多项目都不会成功。项目只是更大范围的组织环境中的一部分，许多 对项目的影响因素是不为项目经理所控制的。 因为项目管理的最终目的就是要使项目满足或超过项目干系人的需求和期望，因此在 项目计划中纳入项目干系人分析是非常重要的。在项目开始和进行过程中，需要认真考虑 到底有哪些人是项目干系人中的重要角色，项目进行中有些什么变化，把握住这些重要的 角色，那么项目的人脉就通了。 【问题 2】 在项目计划中纳入项目干系人分析是非常重要的。项目干系人分析要记录项目干系人 的姓名、单位、在项目中扮演的角色等基本情况，还要分析各自的项目利益大小、以及对 项目的影响程度，管理这些项目干系人关系的有关建议等。 每个项目都会涉及许多的项目干系人，每个干系人都会顾及项目对自己产生的利害和 影响。因此，项目经理必须高度关注项目干系人。项目管理的首要任务就是全面识别出项 目干系人及其在项目中的影响，从项目干系人的识别开始来分析和管理项目。 （1）识别项目干系人 项目干系人分析需要先仔细识别出项目的所有干系人。项目经理需要对项目干系人有 一个全面的了解，在心中有一张完整的项目干系人结构图，以后无论是启动、计划还是执 行、问题处理和收尾，都可以透过项目干系人来系统全局地思考问题。 如果不能对项目干系人进行无遗漏地识别，仅仅关注项目具体事情和计划，项目出了 问题可能都不清楚问题出在哪里。 在全部识别出了项目干系人及其角色之后，经验丰富的项目经理马上就会想到他们的 重要性是不一样的，他们在项目的不同阶段对项目目标达成的影响程度是有很大差别的。 按照一般项目的干系人分类方法，项目的甲方干系人主要有如下几类：出资人、决策者、 辅助决策者、采购者、业务负责人、业务人员、技术负责人、技术人员、使用者等，他们 的不同身份会因甲方组织的情况不同和项目的不同，将对项目产生不同程度的影响，这就 需要具体情况具体分析了。 （2）分析项目干系人的重要程度 这一步要分析出项目干系人对项目影响的程度情况，以便于项目项目干系人有区别的 对待。 希赛教育专家提示：有些干系人虽然显得并不重要，对推进项目也起不到什么实质性 的作用，但项目经理也不能忽略他们的一些需求。他们一旦对项目起反作用，利用在一些 重要干系人身边并影响他们对项目的判断，后果也会比较严重。所以，项目经理在分析重 要项目干系人的同时，一定也不要忽略了一些不怎么重要的干系人可能的影响。 信息系统项目管理师 /rk/isenfd.htm （3）项目干系人的支持度分析 项目干系人除了重要性不同之外，各干系人对项目的立场也有显著的不同。经验丰富 的项目经理，在拿到项目的时候，会主动与销售人员进行详细沟通，事先弄清楚项目干系 人对本项目的支持情况。 通过重要性的分析，能分辨出很重要的人，但他们是支持还是反对本项目的立场将决 定他们对项目产生积极或消极的影响，这说明还需要对干系人的支持度进行分析。 不同的立场，最终将体现在对项目的支持度上。就一般项目而言，按支持度依次递减 的顺序，干系人主要类别有：首倡者、内部支持者、较积极者、参与者、无所谓者、不积 极者、反对者。按照项目的前进方向，可以得出如图 1-2 所示的项目干系人支持度分析图。 图 1-2 项目干系人的支持度分析图 支持者是项目经理开展工作的合作伙伴，中间力量是项目经理需要努力争取的，反对 者是项目经理需要特别关注的。 在项目管理实战中，需要建立起项目管理的统一战线，即为了实现项目管理目标需要 争取到干系人中大部分人的支持，尤其是中间力量的支持。比较现实的做法是充分借助你 的首倡者和内部支持者、积极寻求中间力量的支持、让不支持者至少不要反对。 此外，项目干系人的支持度并不是一成不变的，有时项目的内部支持者可能会因为各 种原因在项目进行中逐渐演变成项目的反对者，也有些项目干系人前期是反对者，到后面 却逐渐对项目进行支持。随着项目的推移，情况在不断变化，各干系人的支持度也必将发 生变化。因此，项目经理需要动态调整项目干系人支持度分析图，及时分析并修正各干系 人的支持度，以便灵活应对项目的各种新变化。 细心的项目经理还会善于在对项目干系人识别后作出总结，表 1-1 给出某个项目中部 分项目干系人的分析情况表，供读者参考。 表 1-1 项目干系人分析表 【问题 3】 案例中谢经理的处境在许多 IT 项目中屡见不鲜，重要的就是找出原因，然后采取相应 的对策。通过阅读材料，可以发现项目中存在的主要问题如下： （1）没有仔细分析项目的干系人。新动力分管财务的陈总是项目的中间力量，他一 方面考虑到财务管理的方便性，另一方面还总是想到自己作为集团领导在财务方面的特权， 此外，他还有财务管理信息系统项目的否决权，有可能从项目的中间力量演变为项目的反 对者。 （2）项目缺乏新动力信息技术部门的支持。这种情况在项目合同的甲方比较常见， 信息技术部门往往地位不高，财务部门是管理部门，在公开招投标时不一定指挥了信息部 信息系统项目管理师 /rk/isenfd.htm 门。但 IT 项目在开发过程中，特别是技术方案把关、项目验收、上线、后期的运行、维护 管理工作都需要甲方信息技术部门的大力支持。 （3）项目计划沟通不够。谢经理的团队技术力量雄厚，但在与项目干系人的沟通上 做得不够，连新动力分管财务的陈总都认为提前完工是不可能的事，说明没有及早地与陈 总在项目大的方向和约束上商量，也没有将项目计划告知于陈总。 （4）承担的责任过重。在项目的甲方实施项目主要还是得靠甲方的工作人员。在开 发完工后的系统实施阶段，推广工作应当以财务部门与信息技术部门为主导，谢经理的团 队作为辅助，因为谢经理的团队对新动力的工作人员不具备号召力，更不用说变更财务管 理的业务流程了。 【问题 4】 问题找到了，相应地就要采取一定的措施，以使项目走上正轨。下面给出谢经理可能 采取的措施。 （1）与公司销售部门负责此项目的营销人员作一次细致的沟通，全面识别并分析项 目干系人。根据题目可确定新动力分管财务的陈总、财务部的刘经理和信息中心的负责人 作为目前项目干系人的重点沟通人物，尽可能与他们进行协商，争取他们对项目的认同与 支持。 （2）申请并取得公司领导的支持。通过公司领导与新动力的陈总的接触，取得陈总 的支持，再由陈总去推动项目的实施，比如可由陈总召集各个部门、子公司负责人召开协 调会，谢经理在协调会上作出项目的进度报告，并就项目的实施提出自己的看法和意见， 以争取到财务部刘经理、信息中心及各部门相关责任人、信息中心相关技术人员的支持。 （3）与新动力进行谈判，表示鉴于项目实施的复杂性，建议将项目系统的开发与实 施分为 2 个子项目，当开发子项目验收后支付部分费用；后续实施子项目由新动力主导， 谢经理的团队全力配合，主要是完成系统的培训和完善工作。 1.2.3 参考答案 【问题 1】 项目干系人中需要重点关注客户、用户、项目投资人、项目经理、高层管理人员、反 对项目的人、施加影响者等。 【问题 2】 首先要识别项目干系人，然后再分析项目干系人的重要程度，接着进行项目干系人的 支持度分析，最后针对不同的项目干系人，特别是重要的项目干系人，给出管理项目干系 人关系的建议，并予以实施。 【问题 3】 案例中存在的主要问题如下： （1）没有仔细分析项目的干系人，导致项目干系人关系管理失败。 （2）项目缺乏新动力信息技术部门的支持。 （3）项目计划沟通不够。 （4）作为项目的承建方承担的责任过重。 【问题 4】 如果我是谢经理，我将采取如下的措施： （1）与公司销售部门负责此项目的营销人员作一次细致的沟通，全面识别并分析项 目干系人。 （2）申请并取得公司领导的支持，通过公司领导与新动力的陈总的接触，取得陈总 的支持，再由陈总去推动项目的实施。 （3）与新动力进行谈判，表示鉴于项目实施的复杂性，建议将项目系统的开发与实 信息系统项目管理师 /rk/isenfd.htm 施分为 2 个子项目，当开发子项目验收后支付部分费用；后续实施子项目由新动力主导， 谢经理的团队全力配合，主要是完成系统的培训和完善工作。 1.3 邓工项目的可行性研究 阅读以下关于信息系统项目管理过程中可行性研究问题的叙述，回答问题 1 至问题 3, 将解答填入答题纸的对应栏内。 案例场景 1.3.1 案例场景 在项目计划和选择的过程中，需要完成的首要工作是对项目进行估算。项目估算的范 围涉及方方面面，例如项目或产品开发的范围、投入和回报、项目风险、作用和意义等。 在传统信息系统工程方法中，是以可行性研究的方式来组织对项目的主要估算内容的。在 企业实际的业务过程中，可行性研究通常作为一个重要的环节，被包含在整个项目立项或 项目选择和确认的过程中。 某银行为拓展业务渠道，提高服务质量，拟启动网上银行系统项目，该银行决定由信 息技术部的邓工负责开展前期工作。为稳妥起见，邓工调查了该行现有的电子银行类系统， 并前往各家已建有网上银行系统的银行及多家软件开发商进行了认真的考察，此后编写了 项目的可行性报告。 【问题 1】 （7 分） 可行性研究的步骤是什么？请使用列举的形式，不超过 200 字回答。 【问题 2】 （8 分） 可行性研究报告是可行性研究的成果体现，请使用列举的形式，不超过 150 字回答， 可行性研究报告主要包含什么内容？ 【问题 3】 （10 分） 考虑到项目的重要性，在可行性研究的基础上，邓工请第三方根据国家颁布的政策、 法律法规等，从项目、国民经济、社会角度出发，对拟建项目进行了各方面的评估，最终 形成了项目评估报告。请用不超过 50 字的文字回答，项目评估报告主要包含什么内容？ 1.3.2 案例分析 本题是一道关于可行性研究的试题，主要考查可行性研究的目的、步骤和方法。 【问题 1】 信息系统项目可行性研究的目的，就是用最小的代价在尽可能短的时间内确定以下问 题：项目有无必要？能否完成？是否值得去做？ （1）项目的必要性分析 首先应确定信息系统项目的目标，即本项目想解决哪些问题。在信息系统目标明确之 后，如果目前已经有一个（或几个）信息系统正在被人使用，就需要认真分析现有的信息 系统。显然，如果现有的信息系统是完美无缺的，完全可以实现新系统的目标要求，谁都 不会提出开发新系统的要求。在通常情况下，现有系统必然存在某些缺陷，无法完全实现 新系统的目标要求。但这一点并不能成为开发新系统的理由，我们还应仔细分析现有系统 对于新系统目标的实现的程度如何，不能实现某个具体目标的原因是什么，经过改进性维 护能否实现这些目标。 如果现有的信息系统经过简单的改进性维护就可以实现新的系统目标，就没必要重新 开发一个新系统。但在以下情况下，有必要开发新的信息系统。 原有系统开发不规范，缺少必要的技术文档，原开发人员跳槽，新接手的开发人员很 难维护原有系统，维护成本可能会接近甚至超过新开发的成本。 原系统采用落后的设计技术或因设计人员的水平所限，系统架构设计不合理，难以扩 信息系统项目管理师 /rk/isenfd.htm 充和修改。 原系统设计虽然合理，也考虑到了日后的扩充，或因业务发展太快，远远超过原来的 设想，量变引起质变。 原系统开发工具已过时，用落后的开发工具继续维护还不如用新的开发工具重新开发。 原系统所基于的硬件或软件平台已过时，在原有平台继续维护已无必要，需要开发基 于当前流行平台的新系统。 在分析新系统项目开发的必要性时，一定要注意识别是真的“必要“还是假的“必要“.某 些开发单位，由于重开发、轻维护，新系统开发人员的地位和待遇远远高于现有系统的维 护人员，维护人员考虑到开发新项目的高待遇和成就感，为尽快转入新项目的开发，极力 夸大原有系统维护的技术难度和工作量，主张开发新系统，他们所提出的对比分析（维护 VS 新开发）结果往往带有倾向性。因此，应选择那些与项目本身无利害关系的技术专家进 行项目必要性分析。当然，更重要的是，缩小现有系统维护人员和新系统开发人员的收入 差距。 另外，某些信息系统开发商往往利用客户（用户）“喜新厌旧“的心理，出于宣传和经 营的需要，每隔几年，即使没有太大的功能性和技术性突破，也要策划开发新的系统。有 时当竞争对手推出或即将推出新系统时，为保住自己的市场份额，即使条件不具备，也要 迅速推出新的系统。这些问题，应属于市场运营策略的范畴，在此不