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