《信息系统项目管理案例分析指南.docx》由会员分享，可在线阅读，更多相关《信息系统项目管理案例分析指南.docx（56页珍藏版）》请在三一办公上搜索。
1、信息系统项目管理案例分析指南目录第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、例分析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、络图绘制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.
4、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、理的启动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
6、.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、答案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、策树分析技术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、外包管理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、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、案11.7项目团队建设11.7.1案例场景11.7.2案例分析11.7.3参考答案第1章 项目整体管理案例项目的整体管理在项目管理的9个知识领域中处于核心位置，其功效就是用来整合其它8个知识领域，项目经理则要起到关键性的组织、协调与管理作用，然而这并非易事，许多IT项目经理在做项目时总感觉需要协调各种各样的资源，然而又似乎无从下手，一些事情好象身不由己，无法控制。项目整体管理是围绕项目管理计划的制订、执行和控制进行的，通过项目资源的整合将项目所有的组成要素在恰当的时间、正确的地方、合适的人物结合在一起，以成功的完成项目。按照PMBOK2004（Project Management Body o
12、f Knowledge 2004,项目管理的知识体系2004版）中的定义，项目整体管理的过程包括：制订项目章程、制订项目范围说明书（初步）、制订项目管理计划、指导和管理项目执行、监督和控制项目工作、整体变更控制和项目收尾。1.1 项目开始走向混乱阅读以下关于在信息系统项目管理过程中项目整体管理方面问题的叙述，回答问题1至问题3,将解答填入答题纸的对应栏内。1.1.1 案例场景希赛集团下属飞达信息技术有限公司新接到一个有关电子政务公文流转系统的软件项目，王工作为公司派出的项目经理，带领项目组开始进行项目的研发工作。王工以前是一名老技术人员，从事Java开发多年，是个细心而又技术扎实的老工程师。在
13、项目的初期，王工制订了非常详细的项目计划，项目组人员的工作都被排得满满的，为加快项目的进度，王工制订项目计划后即分发到项目组成员手中开始实施。然而，随着项目的进展，由于项目需求不断变更，项目组人员也有所更换，项目组已经没有再按照计划来进行工作，大家都是在当天早上才安排当天的工作事项，王工每天都要就工作安排焦头烂额，项目正开始走向混乱的局面。项目组中的一名技术人员甚至在拿到项目计划的第一天就说：计划没有变化快，要计划有什么用,然后只顾埋头编写自己手头的程序。一边是客户在催着快点将项目完工，要尽快将系统投入生产；另一边是公司分管电子政务项目的张总在批评王工开发任务没落实好。【问题1】（8分）请用4
14、00字以内的文字，王工制订的项目计划应包括的主要内容。【问题2】（8分）请用400字以内的文字，围绕项目计划来说明在王工在制订项目计划时出现的问题。【问题3】（9分）如果你是王工，面对项目开始走向混乱的局面的情况，应当如何处理呢？1.1.2 案例分析项目计划是项目管理的基础，项目管理中最重要的就是项目计划的工作，项目计划是一个综合概念，凡是为实现项目目标而进行的活动都应该纳入到计划之中。【问题1】项目计划的制订是贯穿这个项目生命周期的持续不断的工作，是利用其他计划编制过程的结果，建立一份连贯性、一致性的文档，以指导项目实施和项目控制。项目计划过程是一个反复的过程。一个详细的项目计划过程包括：（
15、1）项目计划的定义，确定项目的工作范围。（2）确定为执行项目而需要的工作范围内的特定活动，明确每项活动的职责。（3）确定这些活动的逻辑关系和完成顺序。（4）估算每项活动的历时时间和资源。（5）制订项目计划及其辅助计划。一般而言，项目计划可以包含如下要素：（1）项目范围计划：阐述进行这个项目的原因或意义，形成项目的基本框架，使项目所有者或项目管理者能够系统、逻辑地分析项目关键问题及项目形成中的相互作用要素，使项目干系人在项目开始实施前或项目相关文档编写以前，能够就项目的基本内容和结构达成一致；项目范围说明应当形成项目成果核对清单，作为项目评估的依据，在项目终止以后或项目最终报告完成以前进行评估，
16、以此作为评价项目成败的依据；范围说明还可以作为项目整个生命周期监控和考核项目实施情况的基础和项目其他相关计划的基础。（2）项目进度计划：进度计划是说明项目中各项工作的开展顺序、开始时间、完成时间及相互依赖衔接关系的计划。通过进度计划的编制，使项目实施形成一个有机的整体。进度计划是进度控制和管理的依据，可以分为项目进度控制计划和项目状态报告计划。（3）项目质量计划：质量计划针对具体待定的项目，安排质量监控人员及相关资源、规定使用那些制度、规范、程序、标准。项目质量计划应当包括和保证与控制项目质量有关的所有活动。（4）项目资源计划：决定在项目中的每一项工作中用什么样的资源（人、材料、设备、信息、资
17、金等），在各个阶段使用多少资源。项目费用计划包括资源计划、费用估算、费用预算。（5）项目沟通计划：沟通计划就是制订项目过程中项目干系人之间信息交流的内容、人员范围、沟通方式、沟通时间或频率等沟通要求的约定。（6）风险计划：风险计划是为了降低项目风险的损害而分析风险、制订风险应对策略方案的过程，包括识别风险、量化风险、编制风险应对策略方案等过程。（7）项目采购计划：项目采购计划过程就是识别哪些项目需求应通过从本企业外部采购产品或设备来得到满足。（8）变更控制、配置管理计划：由于项目计划无法保证一开始就预测得非常准确，在项目进行过程中也不能保证准确有力的控制，导致项目计划与项目实际情况不符的情况经
18、常发生，所以必须有效处理项目的变更。变更控制计划主要是规定变更的步骤、程序，配置管理计划就是确定项目的配置项和基线，控制配置项的变更，维护基线的完整性，向项目干系人提供配置项的准确状态和当前配置数据。【问题2】制订项目计划的目的在于建立并维护项目各项活动的计划，项目计划其实就是一个用来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。一个好的项目计划可为项目的成功实施打下坚实的基础。以下这些方法能有效的帮助项目经理制订项目计划。（1）注意项目计划的层次性项目计划的层次及其关系如图1-1所示。图1-1 项目计划的层次高级计划，是项目的早期计划。高级计划应当是粗粒度的，主要是进行项
19、目的阶段划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。详细计划要确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，项目里程碑。如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发组，二级计划是各开发组制订的适合自己开发组的计划。如果开发组还分了小组，可以有小组的三级计划。开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制订，个人计划要尽量细化到工作单元和时间单元。一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率
20、的瓶颈。合理的划分小组，减少组织的层次，有利于项目计划的制订和实施。较小的软件项目由于工期不长，人员较少，只有两级计划（高级计划与低级计划）也是可行的。（2）该详细的详细，该简略的就简略项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工的小项目，可能项目计划就四五页纸，包括一个WBS（Work Breakdown Structure,工作分解结构）和一个甘特图（Gantt Chart）。一个需要五六十个人甚至上百人，要花上半年或更长时间的大型IT项目则会有更多的项目计划内容。项目经理要按照项目的特定情况量体裁衣，要强调项目计划的指导性。项目中的工作安排一定要责任到人。如
21、果是多个人共同完成的任务也要指定一位主要负责人，否则工作人员会操作不便，甚至互相推卸责任。（3）制订的项目计划要现实制订项目计划仅靠个人经验是不够的，不可能面面俱到，不要寄希望于个人经验.解决的办法有两个方面：一是充分鼓励、积极接纳项目干系人（包括客户、公司高层领导、项目组成员）来参与项目计划的制订。应主动邀请客户和公司高层领导来共同讨论高级计划的制订。客户对项目在现场的实施和系统应用将起到很好的促进作用。公司高层领导的参与将有利于项目获得精神上和物质上的支持。制订二级、三级项目计划要与项目组成员互动，要强调项目计划的现实性，不现实的项目计划不但不可能指导项目的实施，还可能成为项目成功的障碍。
22、当规划由一个人做出而由另一个人实施时，如果项目没有按时完成，会使得他们怀疑项目计划的可行性，也会影响开发人员的士气。项目组内部人员的沟通亦很重要。项目经理应当关注计划的制订工作中的气氛，在轻松的氛围中去融合开发人员的意见。可以让开发人员对自己职责范围内的事提出建议的时间和资源，再作讨论约定。这样开发人员在主观上会更加投入工作。客观上，开发人员的能力很难用时间及工作量来衡量，一名熟练的Java程序员比一名初学Java的程序员开发效率可能快上四五倍，因而安排的时间周期、任务量当然要不一样。可以考虑召开一次专题讨论会，事先写出一个初稿，再各抒己见，最后作出结论。二是充分利用历史数据。历史数据是宝贵的
23、财富，是可复用的资源。不仅要注意积累这些数据，也要学会从中提炼出可以为己所用的数据。如：项目计划的模板、计划的资源数据等。成熟的项目开发组织会将历史的数据保留并作一些分析，形成一些经验计算公式、实用的文档模板等。需要特别提到的是，有的软件项目在失败之后，项目组人员一般很不情愿再度问津此事，一谈到做过的失败的项目就唯恐避之不及，其实，失败的项目对项目研发具有重要的参考价值。有必要在每做完一个项目后认真的进行总结。这是项目可持续发展的必要，也是对项目和项目组成员的尊重。当前项目的经验对其它项目是有很好的借鉴意义的，特别是对类似的软件项目，在管理上、技术上、开发过程上都是一笔财富。不仅要对项目的程序
24、代码存储，所有相关文档资料（包括合同、开发文档、总结文档等）也要归档。（4）重视与客户的沟通与客户的沟通是很重要的。不必害怕客户知道我们的开发计划，特别是项目进度情况，应当和客户共享这些信息。首先，客户会提出一些对项目时间、进度、效果上的要求，这些要求往往经不起推敲，有的还带有较强的政策性。例如：在某单位的人事管理信息系统的开发中，客户方对时间上的这个要求，是单位领导开会集体决定并形成了文件的，但是，经过认真的需求调研，做出项目进度的粗计划和部分的二级计划后，发现按客户方要求的三个月时间是难以实现的。这时就需要说服,可以把做出的调研文档和项目计划摆出来与客户讨论，并最终使项目的开发时间适当延长
25、。实际上，项目组和客户的目的是一致的，所以对于合理的项目进度客户是会理解与支持的。其次，项目组有义务要让客户知道项目的计划，这样才能让客户实际上主动、积极参与项目，达到项目的最终目标。项目计划取得双方签字认可是非常重要的。客户可能不愿意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非正式的，但留下了项目工作的痕迹。应该让客户清楚签字意味着双方对项目计划的认同。双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。在本案例中，王工制订了详细的项目计划，将项目组人员的工作排得满满的，在没有和项目组人员商量的情况即下发项目计划并实施，
26、此举不妥。制订项目计划时，需要取得项目组人员的支持、理解，并且需要注意在项目的开始阶段往往需要的是粗粒度的，并且是现实的项目计划。项目计划对于项目的实施非常重要，在制订时也需要和客户、公司领导及时沟通，以取得他们的支持。而王工对于项目运作的紧张局面既没有向公司领导汇报，也没有向客户解释，只是一个人默默地将问题埋在心里，而采取了每天早上安排工作的临时性解决办法，治标没有治本。【问题3】王工作为项目经理应当清醒地意识到项目开始出现混乱，一是制订项目计划时不妥；二是项目的变更没有控制好，王工需要采取一些有针对性的措施。项目的不确定性因素导致了项目的进展未必象想象中或计划中的那样顺利，而当这种不确定性
27、变得明确且和当初的预测不一致的时候，就会导致项目出现变更。一般来说，项目的目标是项目所有活动的最终判断准则。也就是说我们必须关注那些可能会引起项目目标变化的信息。为了对项目变更进行控制，应由项目实施组织、项目管理班子或两者共同建立变更控制系统。变更控制系统就是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪和变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。整体变更就是影响
28、项目整体和贯穿整个项目过程的变更。整体变更控制的目的有三个：（1）查明项目进行过程中发生的变化是否构成变更。（2）对造成变更的因素施加影响。（3）当变更实际出现时，设法处理之。整体变更控制就是协调贯穿整个项目过程的变更。例如，可交付成果的技术要求说明书发生的变更，若影响到项目范围，进而影响到费用、进度、质量、风险或其他方面，则该变更就是整体变更，应当通过范围变更控制系统处理。整体变更控制的依据是项目计划、进展报告和变更请求。项目班子成员或项目干系人的变更请求可能会以多种形式提出。但除非特殊情况，只有书面提出者，才能受理。整体变更控制的工具就是上面提到的变更控制系统。整体变更控制的结果应当有项目
29、计划的更新，采取将项目未来预期进展控制在项目计划范围内的纠正行动并吸取的教训。1.1.3 参考答案【问题1】王工编制的项目计划应包括：（1）项目总计划（包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划以及费用计划）。（2）项目辅助计划（质量计划、沟通计划、人力资源计划、风险计划、采购计划等）。【问题2】王工在制订项目计划时，存在如下的问题：（1）初期的项目计划粒度过小，没有把握好项目计划的层次性。（2）制订项目计划时没有和客户、公司领导和项目组人员进行及时沟通。（3）制订的项目计划不切实际。【问题3】王工可采取如下的措施：（1）重新制订一份较粗粒度的、切实
30、可行的整体项目计划，而由项目组人员根据整体项目计划来制订个人的项目工作计划。（2）将项目计划与项目组人员、公司领导、客户进行沟通，并及时修正，必要时还可以开会议讨论。（3）在项目组中建立起变更控制系统。1.2 谢经理项目的艰难处境阅读以下关于在信息系统项目管理过程中有关项目整体管理方面问题的叙述，回答以下问题,将解答填入答题纸的对应栏内。1.2.1 案例场景谢经理是学赛信息技术公司软件开发部的项目经理，6个月前他被公司派往新动力贸易集团有限公司（以下简称新动力）现场组织开发财务管理信息系统，并担任项目经理。谢经理已经领导开发过好几家公司的财务系统，并已形成较为成熟的财务管理软件产品，所以他认为
31、此次去后应当只要适当地做一些二次开发，并根据用户需求作少量的新功能开发即可大功告成。谢经理满怀信心地带着他的项目团队进驻新动力了，谢经理和项目团队在技术上已经历过多次考验，他们在3个月的时间就将系统开发完毕，项目很快进入了验收阶段。可是新动力分管财务的陈总认为，一个这么复杂的财务系统在短短的3个月的时间里就完成了，这在新动力的IT项目中还是首次，似乎不太可能。他拒绝在验收书上签字，并要求财务部的刘经理和业务人员认真审核集团公司及和各个子公司的财务管理上的业务需求，并严格测试相关系统的功能。财务部的刘经理和相关人员经过认真审核和测试，发现系统开发基本准确，但实施起来比较困难，因为业务流程变更较大
32、。这样一来，又过去了1个月，新动力的陈总认为系统还没有考虑集团公司领导对财务的需求，并针对实施较困难的现状，要求项目组从集团公司总部开始，一家一家子公司地逐步推动系统的使用。谢经理答应了新动力陈总的要求，开始先在集团公司总部实施财务系统。可是2个月过去了，连系统都没有安装成功。集团公司信息中心的人员无法顺利的购买服务器，因为这个项目没有列入信息部门的规划；财务部门的人员说项目在集团中都推不动，何必再上。谢经理一筹莫展：我该如何让项目继续走向成功？眼看半年过去了，项目似乎没有了终结之日，更不用说为学赛信息技术公司带来效益了。面对项目的艰难处境，谢经理和他的团队认真分析了他们在项目的整体管理中所做
33、的工作，发现了项目中存在的主要问题，主动积极的采取了应对的措施，最终圆满完成了整个项目的开发和应用。【问题1】（6分）请用200字以内的文字，描述项目干系人中需要重点关注的角色。【问题2】（6分）项目干系人分析是项目整体管理中的一项重要工作，请用400字以内的文字，说明如何进行项目干系人分析。【问题3】（6分）谢经理和他的团队认真分析了他们在项目的整体管理中所做的工作，发现了项目中存在的主要问题，请用400字以内的文字，描述谢经理发现的主要问题。【问题4】（7分）面对项目的艰难处境，如果你是谢经理，你该如何做呢？请用400字以内容文字描述。1.2.2 案例分析本题是一道关于项目整体管理中对项目
34、关系人进行分析的试题，在项目管理中，识别项目干系人，特别是关键的项目干系人，是一件很重要的工作。【问题1】项目干系人是指与项目相关的人，项目干系人的范围较大，项目组内部与外部的人员都会涉及，但需要重点关注以下角色：（1）客户。客户是提出项目需求的个人或组织，一般是指项目的采购方。从商品交易的角度来看，客户就是上帝;同时，客户也是承包方的衣食父母,即项目标的的给予者。因此，客户成为承包方需要关注的第一对象。（2）用户。用户是使用项目产品的人或组织，需要分析用户的使用感受，改进意向等。（3）项目投资人。为项目提供现金或实物等财力资源的组织或个人。（4）项目经理。项目经理是项目的关键人物，对项目组内
35、部来说他是领导者，承担着项目成败的主要责任；对项目组外部来说他是外交官，起着重要的协调作用。（5）项目组成员。项目组成员是让项目落到实处，分担项目任务的人员。项目的成功很大程度上取决于项目团队的战斗力。（6）高层管理人员。项目经理能否成功地领导项目的一个非常重要的因素，就是他们从高层管理层获得支持的程度。（7）反对项目的人。反对项目的人对项目的功能构成威胁，这种人员往往会让项目走向成功的另一面-失败。如：采购方单位有高层管理人员反对项目的实施，项目内部成员有反对现有技术路线的，因此需要特别关注。（8）施加影响者。能够对项目施加影响的人可能对项目产品的取得和使用没有直接的关系，但是因其在客户或用
36、户组织中的地位而能够对项目的进程产生积极或消极的影响。在IT项目中，要特别注意区分客户与用户这两种角色。对待不同的角色需要使用不同的方法，但实际项目中往往容易混淆起来。一般地采购方就是使用者，而且多数情况下采购方的人员参与了项目并提出需求，给人的直接感觉他就是使用项目产品的人。客户与用户这两种角色对于人或组织，有时是相同的对象，有时是不同的，他们的主要区别在于客户是具体阐明项目高层次概念和主要内容，并决定支付款项的数额和方式的决策者；用户是提出系统功能和非功能需求，并最终使用系统的人，但他们往往对应该支付的费用没有决定权。高层管理人员的作用往往被项目经理和项目团队所忽视，特别是用户方的高层管理
37、人员，有的项目经理直到项目结束还不曾谋面，更不要说主动获得他们的支持了。因为有的项目经理天天只想着如何做好项目中的工作，有问题自己如何去解决。然而，没有高级管理层的参与支持，许多项目都不会成功。项目只是更大范围的组织环境中的一部分，许多对项目的影响因素是不为项目经理所控制的。因为项目管理的最终目的就是要使项目满足或超过项目干系人的需求和期望，因此在项目计划中纳入项目干系人分析是非常重要的。在项目开始和进行过程中，需要认真考虑到底有哪些人是项目干系人中的重要角色，项目进行中有些什么变化，把握住这些重要的角色，那么项目的人脉就通了。【问题2】在项目计划中纳入项目干系人分析是非常重要的。项目干系人分
38、析要记录项目干系人的姓名、单位、在项目中扮演的角色等基本情况，还要分析各自的项目利益大小、以及对项目的影响程度，管理这些项目干系人关系的有关建议等。每个项目都会涉及许多的项目干系人，每个干系人都会顾及项目对自己产生的利害和影响。因此，项目经理必须高度关注项目干系人。项目管理的首要任务就是全面识别出项目干系人及其在项目中的影响，从项目干系人的识别开始来分析和管理项目。（1）识别项目干系人项目干系人分析需要先仔细识别出项目的所有干系人。项目经理需要对项目干系人有一个全面的了解，在心中有一张完整的项目干系人结构图，以后无论是启动、计划还是执行、问题处理和收尾，都可以透过项目干系人来系统全局地思考问题
39、。如果不能对项目干系人进行无遗漏地识别，仅仅关注项目具体事情和计划，项目出了问题可能都不清楚问题出在哪里。在全部识别出了项目干系人及其角色之后，经验丰富的项目经理马上就会想到他们的重要性是不一样的，他们在项目的不同阶段对项目目标达成的影响程度是有很大差别的。按照一般项目的干系人分类方法，项目的甲方干系人主要有如下几类：出资人、决策者、辅助决策者、采购者、业务负责人、业务人员、技术负责人、技术人员、使用者等，他们的不同身份会因甲方组织的情况不同和项目的不同，将对项目产生不同程度的影响，这就需要具体情况具体分析了。（2）分析项目干系人的重要程度这一步要分析出项目干系人对项目影响的程度情况，以便于项
40、目项目干系人有区别的对待。希赛教育专家提示：有些干系人虽然显得并不重要，对推进项目也起不到什么实质性的作用，但项目经理也不能忽略他们的一些需求。他们一旦对项目起反作用，利用在一些重要干系人身边并影响他们对项目的判断，后果也会比较严重。所以，项目经理在分析重要项目干系人的同时，一定也不要忽略了一些不怎么重要的干系人可能的影响。（3）项目干系人的支持度分析项目干系人除了重要性不同之外，各干系人对项目的立场也有显著的不同。经验丰富的项目经理，在拿到项目的时候，会主动与销售人员进行详细沟通，事先弄清楚项目干系人对本项目的支持情况。通过重要性的分析，能分辨出很重要的人，但他们是支持还是反对本项目的立场将
41、决定他们对项目产生积极或消极的影响，这说明还需要对干系人的支持度进行分析。不同的立场，最终将体现在对项目的支持度上。就一般项目而言，按支持度依次递减的顺序，干系人主要类别有：首倡者、内部支持者、较积极者、参与者、无所谓者、不积极者、反对者。按照项目的前进方向，可以得出如图1-2所示的项目干系人支持度分析图。图1-2 项目干系人的支持度分析图支持者是项目经理开展工作的合作伙伴，中间力量是项目经理需要努力争取的，反对者是项目经理需要特别关注的。在项目管理实战中，需要建立起项目管理的统一战线，即为了实现项目管理目标需要争取到干系人中大部分人的支持，尤其是中间力量的支持。比较现实的做法是充分借助你的首
42、倡者和内部支持者、积极寻求中间力量的支持、让不支持者至少不要反对。此外，项目干系人的支持度并不是一成不变的，有时项目的内部支持者可能会因为各种原因在项目进行中逐渐演变成项目的反对者，也有些项目干系人前期是反对者，到后面却逐渐对项目进行支持。随着项目的推移，情况在不断变化，各干系人的支持度也必将发生变化。因此，项目经理需要动态调整项目干系人支持度分析图，及时分析并修正各干系人的支持度，以便灵活应对项目的各种新变化。细心的项目经理还会善于在对项目干系人识别后作出总结，表1-1给出某个项目中部分项目干系人的分析情况表，供读者参考。表1-1 项目干系人分析表【问题3】案例中谢经理的处境在许多IT项目中屡见不鲜，重要的就是找出原因，然后采取相应的对策。通过阅读材料，可以发现项目中存在的主要问题如下：（1）没有仔细分析项目的干系人。新动力分管财务的陈总是项目的中间力量，他一方面考虑到财务管理的方便性，另一方面还总是想到自己作为集团领导在财务方面的特权，此外，他还有财务管理信息系统项目的否决权，有可能从项目的中间力量演变为项目的反对者。（2）项目缺乏新动力信息技术部门的支持。这种情况在项目合同的甲方比较常见，信息技术部门往往地位不高，财务部门是管理部门，在公开招投标时不一定指挥了信息部门。但IT项目在开发过程中，特别是技术方案把关、项目验收、上
