信息系统项目管理案例分析指南.docx
《信息系统项目管理案例分析指南.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理案例分析指南.docx（50页珍藏版）》请在冰豆网上搜索。
信息系统项目管理案例分析指南
信息系统项目管理案例分析指南
名目
第 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 参考答案
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 案例场景
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 质量保证
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 案例分析
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 案例场景
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 参考答案
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 案例分析
11.7.3 参考答案
第1章项目整体治理案例
项目的整体治理在项目治理的9个知识领域中处于核心位置，其功效确实是用来整合其它8个知识领域，项目经理则要起到关键性的组织、和谐与治理作用，然而这并非易事，许多IT项目经理在做项目时总感受需要和谐各种各样的资源，然而又看起来无从下手，一些情况仿佛身不由己，无法操纵。
项目整体治理是围绕项目治理打算的制订、执行和操纵进行的，通过项目资源的整合将项目所有的组成要素在恰当的时刻、正确的地点、合适的人物结合在一起，以成功的完成项目。
按照PMBOK2004（ProjectManagementBodyofKnowledge2004,项目治理的知识体系2004版）中的定义，项目整体治理的过程包括：
制订项目章程、制订项目范畴说明书（初步）、制订项目治理打算、指导和治理项目执行、监督和操纵项目工作、整体变更操纵和项目收尾。
1.1项目开始走向纷乱
阅读以下关于在信息系统项目治理过程中项目整体治理方面问题的叙述，回答问题1至问题3,将解答填入答题纸的对应栏内。
1.1.1案例场景
希赛集团下属飞达信息技术新接到一个有关电子政务公文流转系统的软件项目，王工作为公司派出的项目经理，带领项目组开始进行项目的研发工作。
王工往常是一名老技术人员，从事Java开发多年，是个细心而又技术扎实的老工程师。
在项目的初期，王工制订了专门详细的项目打算，项目组人员的工作都被排得满满的，为加快项目的进度，王工制订项目打算后即分发到项目组成员手中开始实施。
然而，随着项目的进展，由于项目需求不断变更，项目组人员也有所更换，项目组差不多没有再按照打算来进行工作，大伙儿差不多上在当天早上才安排当天的工作事项，王工每天都要就工作安排焦头烂额，项目正开始走向纷乱的局面。
项目组中的一名技术人员甚至在拿到项目打算的第一天就说：
"打算没有变化快，要打算有什么用",然后只顾埋头编写自己手头的程序。
一边是客户在催着快点将项目完工，要尽快将系统投入生产；另一边是公司分管电子政务项目的张总在批判王工开发任务没落实好。
【问题1】（8分）
请用400字以内的文字，王工制订的项目打算应包括的要紧内容。
【问题2】（8分）
请用400字以内的文字，围绕项目打算来说明在王工在制订项目打算时显现的问题。
【问题3】（9分）
假如你是王工，面对项目开始走向纷乱的局面的情形，应当如何处理呢？
1.1.2案例分析
项目打确实是项目治理的基础，项目治理中最重要的确实是项目打算的工作，项目打确实是一个综合概念，凡是为实现项目目标而进行的活动都应该纳入到打算之中。
【问题1】
项目打算的制订是贯穿那个项目生命周期的连续不断的工作，是利用其他打算编制过程的结果，建立一份连贯性、一致性的文档，以指导项目实施和项目操纵。
项目打算过程是一个反复的过程。
一个详细的项目打算过程包括：
（1）项目打算的定义，确定项目的工作范畴。
（2）确定为执行项目而需要的工作范畴内的特定活动，明确每项活动的职责。
（3）确定这些活动的逻辑关系和完成顺序。
（4）估算每项活动的历时时刻和资源。
（5）制订项目打算及其辅助打算。
一样而言，项目打算能够包含如下要素：
（1）项目范畴打算：
阐述进行那个项目的缘故或意义，形成项目的差不多框架，使项目所有者或项目治理者能够系统、逻辑地分析项目关键问题及项目形成中的相互作用要素，使项目干系人在项目开始实施前或项目相关文档编写往常，能够就项目的差不多内容和结构达成一致；项目范畴说明应当形成项目成果核对清单，作为项目评估的依据，在项目终止以后或项目最终报告完成往常进行评估，以此作为评判项目成败的依据；范畴说明还能够作为项目整个生命周期监控和考核项目实施情形的基础和项目其他相关打算的基础。
（2）项目进度打算：
进度打确实是说明项目中各项工作的开展顺序、开始时刻、完成时刻及相互依靠衔接关系的打算。
通过进度打算的编制，使项目实施形成一个有机的整体。
进度打确实是进度操纵和治理的依据，能够分为项目进度操纵打算和项目状态报告打算。
（3）项目质量打算：
质量打算针对具体待定的项目，安排质量监控人员及相关资源、规定使用那些制度、规范、程序、标准。
项目质量打算应当包括和保证与操纵项目质量有关的所有活动。
（4）项目资源打算：
决定在项目中的每一项工作中用什么样的资源（人、材料、设备、信息、资金等），在各个时期使用多少资源。
项目费用打算包括资源打算、费用估算、费用预算。
（5）项目沟通打算：
沟通打算确实是制订项目过程中项目干系人之间信息交流的内容、人员范畴、沟通方式、沟通时刻或频率等沟通要求的约定。
（6）风险打算：
风险打确实是为了降低项目风险的损害而分析风险、制订风险应计策略方案的过程，包括识别风险、量化风险、编制风险应计策略方案等过程。
（7）项目采购打算：
项目采购打算过程确实是识别哪些项目需求应通过从本企业外部采购产品或设备来得到满足。
（8）变更操纵、配置治理打算：
由于项目打算无法保证一开始就推测得专门准确，在项目进行过程中也不能保证准确有力的操纵，导致项目打算与项目实际情形不符的情形经常发生，因此必须有效处理项目的变更。
变更操纵打算要紧是规定变更的步骤、程序，配置治理打算确实是确定项目的配置项和基线，操纵配置项的变更，爱护基线的完整性，向项目干系人提供配置项的准确状态和当前配置数据。
【问题2】
制订项目打算的目的在于建立并爱护项目各项活动的打算，项目打算事实上确实是一个用来和谐软件项目中其它所有打算，指导项目组对项目进行执行和监控的文件。
一个好的项目打算可为项目的成功实施打下坚实的基础。
以下这些方法能有效的关心项目经理制订项目打算。
（1）注意项目打算的层次性
项目打算的层次及其关系如图1-1所示。
图1-1项目打算的层次
高级打算，是项目的早期打算。
高级打算应当是粗粒度的，要紧是进行项目的时期划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。
大的时期交替之前，应做好下一时期的详细打算，我们称之为二级打算。
详细打算要确定各项任务的负责人，开始时刻，终止时刻，任务之间的依靠关系，设备资源，项目里程碑。
假如项目规模相对较大，能够有多级的打算，比如说，一个项目组可能分为几个开发组，二级打确实是各开发组制订的适合自己开发组的打算。
假如开发组还分了小组，能够有小组的三级打算。
开发人员的个人打确实是低级打算，由开发人员依照自己的任务自行制订，个人打算要尽量细化到工作单元和时刻单元。
一样的，软件项目打算至多有四级就够了，过多的等级将会引发效率的瓶颈。
合理的划分小组，减少组织的层次，有利于项目打算的制订和实施。
较小的软件项目由于工期不长，人员较少，只有两级打算（高级打算与低级打算）也是可行的。
（2）该详细的详细，该简略的就简略
项目打算就如同软件项目本身一样有它专门性，一个三五个人花两三个月就能够完工的小项目，可能项目打算就四五页纸，包括一个WBS（WorkBreakdownStructure,工作分解结构）和一个甘特图（GanttChart）。
一个需要五六十个人甚至上百人，要花上半年或更长时刻的大型IT项目则会有更多的项目打算内容。
项目经理要按照项目的特定情形量体裁衣，要强调项目打算的指导性。
项目中的工作安排一定要责任到人。
假如是多个人共同完成的任务也要指定一位要紧负责人，否则工作人员会操作不便，甚至互相推卸责任。
（3）制订的项目打算要现实
制订项目打算仅靠"个人体会"是不够的，不可能面面俱到，不要寄期望于"个人体会".解决的方法有两个方面：
一是充分鼓舞、积极接纳项目干系人（包括客户、公司高层领导、项目组成员）来参与项目打算的制订。
应主动邀请客户和公司高层领导来共同讨论高级打算的制订。
客户对项目在现场的实施和系统应用将起到专门好的促进作用。
公司高层领导的参与将有利于项目获得精神上和物质上的支持。
制订二级、三级项目打算要与项目组成员互动，要强调项目打算的现实性，不现实的项目打算不但不可能指导项目的实施，还可能成为项目成功的障碍。
当规划由一个人做出而由另一个人实施时，假如项目没有按时完成，会使得他们怀疑项目打算的可行性，也会阻碍开发人员的士气。
项目组内部人员的沟通亦专门重要。
项目经理应当关注打算的制订工作中的气氛，在轻松的氛围中去融合开发人员的意见。
能够让开发人员对自己职责范畴内的事提出建议的时刻和资源，再作讨论约定。
如此开发人员在主观上会更加投入工作。
客观上，开发人员的能力专门难用时刻及工作量来衡量，一名熟练的Java程序员比一名初学Java的程序员开发效率可能快上四五倍，因而安排的时刻周期、任务量因此要不一样。
能够考虑召开一次专题讨论会，事先写出一个初稿，再各抒己见，最后作出结论。
二是充分利用历史数据。
历史数据是宝贵的财宝，是可复用的资源。
不仅要注意积存这些数据，也要学会从中提炼出能够为己所用的数据。
如：
项目打算的模板、打算的资源数据等。
成熟的项目开发组织会将历史的数据保留并作一些分析，形成一些体会运算公式、有用的文档模板等。
需要专门提到的是，有的软件项目在失败之后，项目组人员一样专门不情愿再度问津此事，一谈到做过的失败的项目就唯恐避之不及，事实上，失败的项目对项目研发具有重要的参考价值。
有必要在每做完一个项目后认确实进行总结。
这是项目可连续进展的必要，也是对项目和项目组成员的尊重。
当前项目的体会对其它项目是有专门好的借鉴意义的，专门是对类似的软件项目，在治理上、技术上、开发过程上差不多上一笔财宝。
不仅要对项目的程序代码储备，所有相关文档资料（包括合同、开发文档、总结文档等）也要归档。
（4）重视与客户的沟通
与客户的沟通是专门重要的。
不必可怕客户明白我们的开发打算，专门是项目进度情形，应当和客户共享这些信息。
第一，客户会提出一些对项目时刻、进度、成效上的要求，这些要求往往经不起推敲，有的还带有较强的政策性。
例如：
在某单位的人事治理信息系统的开发中，客户方对时刻上的那个要求，是单位领导开会集体决定并形成了文件的，然而，通过认确实需求调研，做出项目进度的粗打算和部分的二级打算后，发觉按客户方要求的三个月时刻是难以实现的。
这时就需要"说服",能够把做出的调研文档和项目打算摆出来与客户讨论，并最终使项目的开发时刻适当延长。
实际上，项目组和客户的目的是一致的，因此关于合理的项目进度客户是会明白得与支持的。
其次，项目组有义务要让客户明白项目的打算，如此才能让客户实际上主动、积极参与项目，达到项目的最终目标。
项目打算取得双方签字认但是专门重要的。
客户可能不情愿签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，尽管是非正式的，但留下了项目工作的痕迹。
应该让客户清晰签字意味着双方对项目打算的认同。
双方有了一个约定，既让用户感受内心踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。
在本案例中，王工制订了详细的项目打算，将项目组人员的工作排得满满的，在没有和项目组人员商量的情形即下发项目打算并实施，此举不妥。
制订项目打算时，需要取得项目组人员的支持、明白得，同时需要注意在项目的开始时期往往需要的是粗粒度的，同时是现实的项目打算。
项目打算关于项目的实施专门重要，在制订时也需要和客户、公司领导及时沟通，以取得他们的支持。
而王工关于项目运作的紧张局面既没有向公司领导汇报，也没有向客户说明，只是一个人默默地将问题埋在内心，而采取了每天早上安排工作的临时性解决方法，治标没有治本。
【问题3】
王工作为项目经理应当清醒地意识到项目开始显现纷乱，一是制订项目打算时不妥；二是项目的变更没有操纵好，王工需要采取一些有针对性的措施。
项目的不确定性因素导致了项目的进展未必象想象中或打算中的那样顺利，而当这种不确定性变得明确且和起初的推测不一致的时候，就会导致项目显现变更。
一样来说，项目的目标是项目所有活动的最终判定准则。
也确实是说我们必须关注那些可能会引起项目目标变化的信息。
为了对项目变更进行操纵，应由项目实施组织、项目治理班子或两者共同建立变更操纵系统。
变更操纵系统确实是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪和变更审批制度、人员和权限。
变更操纵系统应当明确规定变更操纵委员会的责任和权力，并由所有的项目干系人认可。
变更操纵系统可细分为整体、范畴、进度、费用和合同变更操纵系统。
变更操纵系统应当同项目治理信息系统一起通盘考虑，形成整体。
整体变更确实是阻碍项目整体和贯穿整个项目过程的变更。
整体变更操纵的目的有三个：
（1）查明项目进行过程中发
升级会员 