医疗软件项目经理手册模板.doc

1.1 项目管理失败原因
造成项目失败项目管理原因能够分为3个层次。
第一层次：项目管理环境中失败
这些失败根源能够追溯到项目组织和项目目标、项目任务、高层管理部门和更大环境之间不合适“配合”。它们包含使用对于项目目标和项目环境来说不正确项目管理方法或模型，和缺乏高层管理部门对项目标支持等。
1.不合适项目管理方法
项目不含有正确组织结构、项目经理或团体（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。比如： 项目组织结构、计划和控制和项目环境、项目经理哲学，和企业文化或目标不一致或不协调。 更多关键放在保持团体忙碌而不是放在结果上。团体组员分配没有考虑其适合技能和经验。要么是没有些人对整个项目负责，要么是项目经理责任、期望和权力不明确或未定义。一个在过去项目中成功项目团体、项目经理或项目结构被“塞”进一个新项目，而不考虑目前项目标独特要求或目前项目环境不一样特征。
2.缺乏高层管理部门支持
高层管理不给达成项目目标所必需主动、连续支持。比如：高层管理部门没有把足够责任或权力下放给项目经理，或没有支持项目经理决定或行动。企业没有根据高效项目管理所需要政策和程序做出改善（预算、计划、控制系统、汇报和授权关系等）。高层管理部门没有参与审阅项目标计划和进程。
第二层次：项目管理系统中失败
这些失败根源能够追溯到项目领导及错误实践。它们包含项目经理在项目生命周期中对系统方法忽略，和项目管理技巧错误应用等。具体能够归结为：
1.不胜任项目经理
担任项目经理职位人不含有领导和管理项目标背景、技能、经验和个人品质。比如：项目经理不能面对矛盾，不能提出深层、探索性问题，不能为了项目标最大利益而进行有效辩论。项目经理不能对一个传统工作环境做出调整来适应项目标改变和不确定性。缺乏在短时间限制和有压力环境下高效工作能力。项目经理在技术和管理技能上不能令人满意。有时这源自于所谓彼得法则变更：将一个优异技术人员任命到一无所知管理职位上。其它情况是，项目经理含有管理才能，不过对具体管理细节如此投入以至于忽略了关键技术问题。这么就缺乏在项目团体中相关方面发号施令能力和号召力。
2.忽略了项目标系统本质
项目没有被当成一个系统来对待。项目标单元和步骤被划分成独立部分，而没有考虑它们相互之间作用。比如：硬件、软件、资源和设施被单独看待而没有考虑它们和整个项目目标关系。将关键放在各个单独活动上而不是放在项目总体目标上。系统开发演变过程被分段地看待，而没有考虑随即或先前阶段。这在对于未来阶段糟糕计划和对于过去阶段不合适评定中表现很显著。问题从一个阶段传送到下一个阶段。
3.管理技巧不合适或错误利用
项目管理技巧被曲解或被不合适地利用。问题在于项目经理、项目团体或被利用技术本身。比如：项目经理未能将非项目技术计划、协调及控制和项目活动所需技术区分开来。如PERT、WBS、绩效分析和团体建设等，这些技巧被错误应用或根本就没用上。项目经理未注意到项目标人力、行为方面。她没有建立一个项目团体，帮助团体组员了解项目目标，也没有激励项目团体组员朝着目标一起工作。用到技术太复杂或太简单而不适合特定项目。工期安排和汇报对于项目决议来说过于具体或不够具体。更简单、更合适、更适合小型项目标能动性技巧因为偏爱复杂（不过粗笨或不需要）计算机化汇报系统而被忽略了。
第三层次：在计划和控制过程中失败
这些失败根源来自于项目计划和控制过程。部分错误源头，像效率低下沟通和不充足用户参与，会在项目标任何阶段发生，需要给持久注意。其它，像不合适定义、估量、工期安排或控制等关键发生在项目标一些阶段。
1.项目中没有良好沟通
这些问题产生是因为信息质量、正确性，或时间性缺乏，和粗劣数据搜集和统计，或未能将信息分配给那些需要信息人。比如：在项目标早期，相关目标、责任和接收标准信息没有做成文件资料。在项目中没有相关项目状态或对于计划或最终产品变更信息统计和汇报。没有召开足够会议来搜集和公布信息。讨论没有足够深入，也未能提出探索性问题。对项目开发没有做项目日志或审查统计。
2.没有用户参与
用户或用户未能参与计划、定义、设计、实现过程，用户需要被忽略。这是最常常被提到项目失败根源之一。用户可能感到尴尬或不舒适所以想尽力降低参与。部分用户被邀请时候甚至抵制参与。项目团体行为阻碍了用户参与。项目团体组员可能表现高傲，这使得用户感到自己被忽略或感到自卑。这么行为限制了用户和项目团体之间信任，使相互沟通变得担心。
3.不充足项目计划
项目细节分析和计划不充足、马虎，从以前项目得来汇报和提议被忽略。管理不是预先做好准备，而是当事情出现时候才做出对应安排。
4.不充足项目定义
模糊不清、错误、让人误解项目定义或缺乏项目定义是被常常提到一个失败原因。对于技术要求、任务或项目范围没有正式定义。定义问题起源于：
缺乏提案、WBS、责任矩阵和工作责任等定义，或这些提案定义准备得很糟糕。
在定义项目范围、任务和要求时候缺乏用户参与。项目团体对用户操作一点也不熟悉，不能指导一个和用户要求相关设计。
5.糟糕时间和资源估量
对资源需求、活动工期、完成日期估量不现实。糟糕估量发生是因为：没有利用类似项目标标准或文件来估量本项目会连续多长时间。作估量时没有考虑职员经验，而是假设全部职员全部是教授，她们全部能够毫无差错地工作。 估量是由不熟悉细节问题人做出，那些负责工作人没有参与做估量。没有足够时间来做估量。用户施加压力，要求项目快速完成，这就造成制订了不切实际完工日期，并删除了“无须要”任务，诸如文件统计等。
6.不正确工期安排和资源处理
工期安排和资源分配不正确、没有预期工作、没有备用资源。
未能预期估量资源需求并做好预先安排，当资源问题出现时才进行处理。没有显示项目中可用技能具体目录。
项目职员被重新委任或整个换掉，但没有调整工期安排以填补失去时间或学习时间。
7.在实施阶段为数众多变更
对原始要求做了变动，但没有对对应工期安排、预算或计划其它部分做改动。这种疏忽造成不充足项目沟通、低劣项目定义、用户参与缺乏和马虎项目控制等。
8.不合适控制
项目管理不是预期可能有什么问题而是在问题出现时候才进行处理；控制集中在对于日常事务处理而不是向前看潜在问题环境；直到项目结束日期，管理部门才查看项目是否按时。控制问题根源：工作任务定义太大而不能进行有效控制；工作组或工作团体太大而不能被监督；里程碑太远以至于不能对项目进行分步监测。不遵守设计、统计、测试或评定标准或规范。审计员没有进行仔细评定。在项目早期出现问题时没有尝试去处理。控制过程不是前瞻性和预防性，而是回顾性和修补性。对于为确保项目目标完成所需要资金没有估计或计划。
9.项目终止计划很拙劣
不知道什么组成了项目标完成或最终产品，接收标准是什么，或谁必需终止项目；没有正规终止程序来处理目标、绩效、最终产品、和维护问题等；这些问题常常和拙劣项目定义和缺乏用户参与联络在一起。当项目终止还没有被清楚定义时，项目甚至在经过长时间停止后仍然被许可继续进行以做出有成本效益进步。当用户没有参与计划时，对于最终接收条件会有更多分歧。在接收以后，对于最终产品问题未加识别就经过，或不管用户不满而被许可继续向前。
1.2 项目经理角色
项目经理是实施组织委派其实现项目目标个人。项目经理角色不一样于职能经理或运行经理。通常而言，职能经理专注于监管某个行政领域，而运行经理则负责某个关键业务。基于组织结构，项目经理可能要向职能经理汇报。在其它情况下，项目经理可能要和其它项目经理一起向项目组合或项目集经理汇报，而这些项目组合或项目集经理则要对全部项目负最终责任。在这类组织结构中，项目经理和项目组合或项目集经理亲密合作，以实现项目目标，并确保项目计划符合所在项目集整体计划。管理项目所需很多工具和技术全部是项目管理特有。然而，仅了解和使用那些被公认为良好做法知识、工具和技术，还不足以实现有效项目管理。要有效地管理项目，除了应含有特定应用领域技能和通用管理方面能力外，项目经理还需含有：
1、知识。对项目管理，项目经理知道什么。
2、实践能力。项目经理能够应用项目管理知识来做什么或实现什么。
3、个人素质。在实施项目或相关活动时，项目经理怎样行动。个人素质包含态度、关键人格特征和领导力——指导项目团体实现项目目标和平衡项目制约原因能力。
我们项目工作目标
上面我们概要说明了项目成功和失败原因，同时说明项目经理工作角色，本节我们就现在企业对项目工作最终目标做简明说明。
通常情况下，项目标工作内容由项目标协议和我们投标文件描述，项目经理要时刻关注项目工作范围，协调多种资源，为项目最终验收和回款而努力。总来说，项目经理面正确工作内容关键包含以下两个方面：
1、协议要求内容：这部分内容，是项目经理需要仔细研究内容，要有效控制项目标边界。
2、协议之外内容：对于用户化修改，要归到项目变更管理中；报表，协议要求不可能具体到能知道实施程度，需要我们立即上线，对上线模块包含报表立即验收，避免项目范围无限扩大；和其它系统接口，和医院具体网络情况相关，假如在协议内没有明确要求，通常应和医院协商追加费用。
项目基础目标：完成协议要求全部模块，这是最基础要求，也是项目验收基础。
项目附加目标：建立良好用户关系，提升用户满意度；提升用户服务效率，为用户用户服务。
总来说，项目经理要以完成项目终验和回款为工作目标，不要拘泥于部分工作细节，不停自问和沟通，做这些工作是否有利于项目标验收和回款，假如不能请三思后行。“做再完善软件功效假如不能验收项目，实现回款，全部是无用工作”。
2 项目管理过程
2.1 项目开启
2.1.1 过程概述
项目开启阶段工作关键目标是定义初步项目目标和范围；识别和项目有利害关系干系人，这些干系人对项目目标可能含有主动影响，也可能含有消极影响；选派项目经理，对项目经理授权。
项目开启阶段关键工作任务有四项：
1）项目立项，编制项目任务书；
2）项目初步计划：定义项目初步范围和里程碑计划，落实初步投入资源，组建初步项目团体；
3）识别项目干系人，识别影响项目目标实现内、外部干系人，并制订初步管理策略；
4）召开内部、外部项目开启会。项目开启会目标是识别项目关键干系人，并使项目干系人清楚了解项目背景和目标，初步了解实现项目目标工作内容、关键里程碑、假设约束条件、项目风险等。
四项工作任务没有严格次序和步骤，可能存在并行和交叉，实际工作中灵活掌握。项目开启阶段工作不是孤立，它是售前咨询工作后续，是项目计划工作前续，起着承前启后作用。
2.1.2 工作任务
2.1.2.1 项目立项
项目立项标志着项目正式开始。项目立项时，项目经理会收到企业PMO发送《项目经理任命书》和《项目任务书》，项目经理依据协议或提前实施任务单，完善《项目任务书》并回复PMO。PMO在企业项目管理系统中立项，并将项目管理过程模板文件和标准配置库及说明发给项目经理。
项目经理在编制《项目任务书》时，需要依据协议或提前实施任务单，分别和销售经理、售前顾问、PMO、部门直接主管、项目所在地实施部门主管沟通。了解用户、用户背景及对项目标期望和要求，了解此项目包含相关单位、部门和干系人，初步落实项目团体关键组员。
在售前咨询阶段，销售经理是信息沟通枢纽，所以项目立项时项目经理最为关键工作是和销售经理沟通，以尽可能具体掌握项现在期相关信息，为项目计划工作打下基础。
2.1.2.2 项目初步计划
项目初步计划是依据协议或提前实施任务单，结适用户期望和要求，在了解项目总体目标前提下，综合考虑项目标范围、进度、成本、质量等多重约束，对项目进行初步计划。项目初步计划是项目经理进入项目标切入点，是召开项目开启会必需条件，是取得用户信任关键基础，是前期引导用户关键要素。
项目初步计划关键包含以下内容：
1、项目范围：通常情况下，项目范围是指协议中约定项目建设内容，以技术协议书、系统功效模块说明等作为协议附件形式存在。除此之外，项目标范围还包含用户招标文件、企业投标文件所描述内容，还包含销售在投标过程中正式、书面承诺书。项目经理需要在充足了解这些范围约定基础上，按协议回款约定来划分项目标各个阶段，并初步确定各阶段应完成建设内容。
2、项目里程碑：初步项目里程碑计划通常分为两级，一级里程碑内容和达成时间基础是按协议中回款约定制订，二级里程碑内容和达成时间则需要相关项目干系人参与和确定。如医院试验室管理系统可能是分包给另外企业做，其开工时间、验收时间需要另外企业结合本身情况制订。即使在同一企业，项目很多子系统也是需要多个部门合作完成，各部门参与项目标时间需要得到统一协调。所以，初步项目里程碑计划对后续项目具体计划有很大影响。
3、项目成本估算：概略估算项目从开启到结束连续工期，参与人员，投入人月数，多种变动成本。项目目标中应包含项目人月均回款、人月均成本、人月均利润值等经营指标，这么项目目标更能发挥项目团体主动性，激励团体向令人兴奋目标前进。
4、项目验收标准：项目验收标准定义了项目对质量要求。如医院上了新门诊系统后，收费员平均完成一个收费人次时间由6分钟降低到3分钟，患者平均排队时间由20分钟降低到5分钟，门诊人次由4000日人次上升到5500日人次。不一样协议中约定系统模块可能是一样，但对系统模块实施及预期结果要求则可能不一样。项目经理需要仔细研究招、投标及协议文件，充足和用户沟通，把握用户对项目结果期望和要求，对项目标验收标准进行计划。
同时项目质量目标中还应包含软件需求变更率、软件全生命周期缺点率、释放后缺点百分比、项目文档提交率和合格率等指标。
5、项目假设约束条件：项目标招、投标及协议文件中，隐含了很多假设约束条件，这些条件是项目目标实现风险，需要从一开始就要加以识别、分析，制订有效应对方案。如协议约定“乙方负责新门诊大楼扩容、实施”，这就是一项假设条件，乙方完成新门诊大楼扩容和实施前提是新门诊大楼能够开始扩容和实施，所以需要再加上一句“在甲方门诊大楼搬迁完成且达成扩容和实施条件后，乙方负责新门诊大楼扩容、实施”。假如协议中没有愈加明确约定，项目经理就需要提前和用户进行沟通，确保项目实施条件，这么沟通越早越好。有时候并不是用户有意要设定项目标假设条件，项目经理认真分析假设约束条件，避免项目风险发生。
项目标约束条件还包含各子系统对软、硬件环境要求和需求。这些要求和需求假如在招、投标及协议文件中标明，就需要项目经理在项目最早期和相关干系人沟通，调查、分析并确定，形成《系统软、硬件环境参数表》，以规避用户设备采购及集成不符合项目要求风险。
6、项目风险评定：项目风险管理是项目管理中一项很关键而且贯穿项目一直工作。当项目存在很多问题时，我们更多精力放在处理问题上了，而忽略了思索为何会发生这些问题。当风险发生后，假如没有计划好应对方法，风险便转化为问题了，问题是由风险转化而来。我们更多精力应放在问题发生之前，在问题出现之前处理它或避免它。所以，项现在期风险评定、分析也是项目经理必不可少一项内容。
2.1.2.3 识别项目干系人
识别项目干系人是指识别全部受项目影响人或组织，并统计其利益、参与情况和影响项目成功等情况过程。其过程输出为《干系人登记册》、《干系人管理策略》。
1、干系人登记册
l 基础信息。姓名、在组织中职位、地点、在项目中角色、联络方法。
l 评定信息。关键需求、关键期望、对项目标潜在影响、和生命周期哪个阶段最亲密相关。
l 干系人分类。内部/外部，支持者/中立者/反对者等。
2、干系人管理策略
干系人管理策略要求了在整个项目生命周期中，怎样提升干系人支持，降低干系人负面影响。它包含以下内容：
l 对项目有显著影响关键干系人。
l 期望每个干系人参与项目标程度。
l 干系人分组和按组别管理方法。
和干系人管理策略相关一些信息可能太敏感，不宜纳入公开文件中。项目经理必需进行判定，确定哪些信息应列入干系人管理策略中；对需要列入信息，还要要求其具体程度。
在项目开启阶段，干系人关键为企业和用户各级领导、项目初步团体组员、分包商或第三方合作伙伴等。通常情况下，在企业内部并不会有明确反对该项目标干系人，但用户、分包商、第三方合作伙伴内部有潜在反对者，而且在早期不易被识别，这一点项目经理要很注意，项目反对者在整个项目周期内是一个隐藏炸弹，它可能会给项目带来巨大负面影响。
在整个项目生命周期中，项目干系人支持和反正确程度是动态改变，项目经理需要对干系人期望加以管理，连续跟踪，直到项目取得成功。相关项目干系人识别内容能够参考本章控制关键点一和第11章沟通管理控制关键点一。
2.1.2.4 召开项目内、外部开启会
在完成项目初步计划后，项目经理需要策划、组织召开项目内部和外部开启会，以使项目干系人深入了解项目背景、项目总体目标、项目实施计划和项目预期效果展望等。
项目内部开启会通常先于项目外部开启会召开。内部开启会能够是电话会议、视频会议或面对面会议。经过内部开启会，内部干系人相互间有一个初步认识和了解，为未来团体合作打下良好基础。项目经理向内部干系人汇报项目初步计划，并综合各内部干系人意见，深入完善项目初步计划。
项目外部开启会除了内部干系人、用户干系人外，还需要组织项目监理、分包商、供货商、第三方合作伙伴等干系人参与。确保项目各关键干系人清楚各自角色、职责和义务，让项目干系人在项目建设过程中对所需要给支持和配合给承诺，从而让各方就项目建设相关事宜达成共识。
因为参与项目外部开启会干系人比较多，各自时间安排难统一，对项目标期望和要求差异很大。项目经理需要和用户对口联络人主动沟通，精心策划，让项目外部开启会达成预期目标和良好效果。通常情况下，项目经理需要编制《项目开启会工作计划》，协调干系人时间，策划会议内容，优先满足关键、关键干系人期望和要求。分解准备工作任务，编制《项目开启会准备工作检验表》，在筹备过程中逐项落实、检验。相关内容能够参考事业部公布用户前期引导工作规范。
2.1.3 控制关键点
2.1.3.1 怎样了解项目关键干系人对项目标期望和要求？
项目经理需要全方面了解、掌握项目关键干系人对项目标期望和要求，以使项目在推进过程中保持正确方向和正确范围。
通常情况下，每个项目标立项全部经历了一个漫长过程，大多数项目源自于用户领导最初想法，在经过和用户组织相关职能部门责任人讨论、调整后，形成了项目初步目标和建设思绪，也包含用户对项目最初始期望和要求。在经过销售经理、咨询顾问等相关干系人提议、引导，项目标目标逐步清楚，进而形成了具体项目实施方案。能够说销售和咨询是全方面了解、掌握用户关键干系人期望和要求，假如项目经理能在项目立项前期参与销售、咨询过程，也会对项目关键干系人期望和要求有一个全方面了解。但通常情况下，项目经理要到项目立项后才能参与到项目中，和销售和咨询沟通显得至关关键。首先需要销售和咨询主动通知项目经理，其次也需要项目经理在立项后要主动、立即了解项目相关背景、用户关键干系人想法、和最终形成对项目标期望和要求。
和销售、咨询了解相关信息包含但不限于：
l 了解用户组织结构，识别用户关键干系人及其相互关系。
l 了解项目背景，了解项目从最初想法发展到具体目标全过程，了解其中假设结束条件。
l 了解项目关键干系人之间冲突。
l 了解项目目标中关键干系人关注点。
l 了解销售、咨询在沟经过程中识别出来风险点、困难点，和对应应对、规避方法和方案。
通常来讲，开一个项目开启会，无法全方面掌握项目关键干系人期望和要求，需要项目经理有计划、不间断和销售、咨询、用户关键干系沟通，这个过程也会帮助项目经理识别关键干系人，和干系人特点、期望和要求，进而形成不一样干系人沟通策略。
2.1.3.2 怎样编制项目任务书、并了解其关键性？
项目经理需要经过项目任务书，向项目干系人传达、宣讲项目标背景、项目标总体目标、项目初步范围、项目假设结束条件、项目风险、项目干系人对项目标期望和要求。
在项目经理全方面掌握项目相关背景、项目目标、项目范围、项目标假设结束条件、项目风险等初步信息后，需要将这些信息汇总、整理，形成书面文档，即项目任务书。项目任务书需要经过正式、非正式方法传达给企业内部其它干系人，同时还要召开内部开启会或其它正式、非正式会议，对项目背景等相关信息做深入讲解，以使项现在期相关干系人全部能了解项目背景、总体目标、初步范围，和用户关键干系人关注点，对项目标期望和要求，和项目中存在风险。
2.1.3.3 怎样经过项目开启工作赢得用户信任？
项目开启阶段用户对项目经理信任有利于引导用户按项目经理计划去实施项目。项目经理计划具体实施方案和销售咨询前期计划方案有一定差异，项目经理编制项目实施方案对范围、进度、成本和质量限制原因了解更为深刻，对项目资源、技术水平、时间节点等约束条件考虑更为全方面。项目经理编制项目实施方案往往更现实、更客观、更可行，这可能和用户期望有一定偏差，此时项目经理取得用户信任显得很关键，因为项目实施方案和计划需要得到用户认可和确定，项目标推进才会对应保障。
通常情况下，项目经理在项目立项后开始进入项目，会感觉到用户比较信任销售和咨询，这是因为在项现在期销售和咨询和用户交流较多，相互之间已经建立起对应信任关系。这时候怎样建立用户对项目经理信任呢？有多个原因能够帮助项目经理赢得用户信任：
l 召开项目开启会：对项目背景、项目总体目标、项目初步范围、项目假设约束条件、项目风险、项目干系人对项目标期望和要求分析要全方面、充足，并经过项目开启会表示出来。首先展示项目经理对项目标了解，其次宣传企业、宣传用户，加强用户众多干系人对项目标了解，动员大家主动参与。
l 编制项目实施方案和计划：要引导用户干系人主动参与，引导其考虑项目标约束条件、限制原因，有理有据、切实可行方案和计划是赢得用户信任基础。
l 资源调度：在项现在期，用户往往期望到位大家，期望项目快速推进，但实际上资源需求是依据项目推进情况确定。盲目标调动资源不仅轻易形成资源闲置，在调离资源时不轻易得到用户认可，造成调度无方印象。有效资源调度能够提升用户满意度，赢得用户信任。
2.1.3.4 场景分析：泸州医学院隶属医院项目开启
【场景描述】
5月该项目以低价中标HIS、LIS，随即两周将进行协议洽谈，协议生效后项目立项，立项以后才能派人进驻现场。销售部门要求硬件集成部门提供系统集成方案、软件实施部门提供软件实施方案。在经过内部部分沟通后，初步选定了项目经理和项目软件经理，并依据企业历史类似项目经验，制订了系统集成方案和软件实施方案，同时还制订了需求调查表拟下发调查各部门需求。
两周后，销售经理、项目经理、项目软件经理及企业相关领导赴现场洽谈协议。在交流会上发觉医院对企业意见很大，对X软及X软产品缺乏了解，财务科、药剂科直接提出现场就要演示系统，而不是看PPT方案，甚至还有些人不知道X软还能做医院管理系统。交流会原来要讲两个方案，在讲解完系统集成方案后企业主持人取消了软件实施方案讲解，因为在那种担心气氛下，用户根本不关注什么方案，而是关注软件长什么样。在交流会后，企业领导约见了院长，就医院信息化建设进行了深入沟通，院长并没有太多想法，她将此项目交给主管副院长全权负责。项目经理对这些情况了解不多，只知道这个项目未来可能会很困难。
经过艰苦谈判，最终签署协议。6月23日项目正式立项，在和医院相关领导沟通后，决定召开一个项目开启大会，宣传项目、宣传X软，以获取医院各科室对项目标支持。但现场开启会只安排了主管副院长、大区总经理讲话，而没有安排项目经理讲话，开启大会只达了宣传X软目标，对于项目目标和预期效果、项目实施思绪和方案，并没有具体讲解。
在开启会后，医院领导和信息科一直认为项目能在6个月工期内实施完成，而这个项目最终工期却是18个月。财务科、药剂科认为系统应该是成熟，只需要做简单培训即可上线，而实际上软件系统步骤设计和原有管理步骤相差很大，随即开了很数次协调会才将原有步骤调整过来。对于系统实施具体方案，医院预期和实际情况落差比较大，造成项目进度延期尤其严重。尤其是LIS系统，开启会前、会上、会后全部缺乏交流，医院认为X软LIS能够系统完全满足她们需求，企业内部也认为LIS系统满足医院要求问题不大，但恰恰是LIS实施对项目标进度产生了很大影响。
【场景分析】
项目目标和预期效果：表面上医院目标是将老系统换掉，达成数据安全和稳定运行即可，但老系统只有财务和药品管理系统。医院选择上临床管理、LIS等系统一定是有想法，这一点销售经理、项目经理在前期全部未能就此充足沟通，未能让项目组其它组员和医院各个部门了解。
识别干系人：即使知道“一把手”工程关键性，重视了院长和信息科长交流，但忽略了主管副院长、财务科长、药剂科长、门诊部主任、检验科主任交流，她们关注点并不一样，对这个系统期望也不一样，未能识别出对这个项目不支持人，更缺乏对应应对方法了。
召开项目现场开启会：即使召开了现场大会，但只达成了宣传X软目标，很多科室领导对本项目标目标、最终效果、阶段计划知之甚少，造成后期推进时很多不了解、不支持。项目经理需要解读医院领导想法、目标、期望、关注点，经过项目实施方案系统性讲解。
项目初步计划：缺乏风险分析，对医院硬件采购、网络布线、科室人员配合等情况掌握较少，对项目标部分约束条件沟通较少，造成医院一直认为X软能在6个月内全部实施完成。而HIS快要到上线时，项目组才发觉有科室连电源插孔全部不够，在LIS实施时才发觉二者对需求了解相去甚远。通常很多医院会笼统承诺只要项目开动，相关支持会到位，这时候必需将医院帮助工作分解，只有分解、分析后大家才能共同看清哪些承诺是不一定能达成，约束条件、限制原因必需在开启阶段得到细致分析和应对计划。
2.1.3.5 场景分析：普洱市人民医院项目开启。
【场景描述】
6月该项目中标，7月10日基础谈妥协议。在协议未生效情况下，因为医院期望项目尽早开工，项目申请提前实施。企业销售部门和技术部门告诉信息科长需要召开一个项目现场开启会，信息科长在没有和X软企业相关人员沟通开启会计划情况下，提前向院长汇报，院长立即决定7月14日召开项目现场开启会，并全院下发文件要求各科室相关人员参与。而企业项目经理在开启会前两天才定下来，对项现在期情况基础是空白。
项目经理准备先内部沟通好项目开启方案再和医院信息科长联络，不料信息科长在得悉确定项目经理后主动打电话给项目经理讨论开启会准备细节，包含时间、地点、形式、讲话人及内容、参与人员等内容。
为了做好项目现场开启会准备，项目经理立即和参与项现在期销售经理、技术售前联络，分别就医院组织架构、项目背景、项目目标、项目期望和关注点进行沟通。同时和技术部门相关责任人讨论协议商务、技术细节，分析其中存在风险、相关约束条件和限制原因，制订初步实施思绪和方案。在了解到医院院长尤其支持，关键关注“银医一卡通”、临床无纸化、移动医疗管理等亮点后，决定快速推进，在10月1日前将HIS关键模块、LIS、PACS、电子病历一次性推上线。
为了使项目开启会达成良好效果，项目经理将PPT讲稿分为三个部分：一是介绍项目目标和预期效果；二是介绍X软企业及怎样实施项目建设；三是介绍项目开启会下一步工作计划。
在项目组进驻现场后，项目经理经过信息科长和院长等相关院领导面对面交流，发觉医院即使对项目建设范围计划清楚，且推进愿望迫切，但对项目进度要求并不过急、过高，主管临床副院长期望电子病历立即上线，而LIS、PACS科室领导全部期望延期上线，只是院领导期望早点开始开工。同时医院各科室网络布线工程并不足以支撑初始进度计划。项目经理还发觉项目建设内容计划和协议中回款条款并没有明确定下来，同时企业目前资源也并不能支撑最初快速推进计划，于是调整最初计划。首先修改协议，将项目建设范围中各个子系统和回款条款对应，以明确各阶段回款界限中实施内容；将第一阶段一次性上线修改分两次错开上线，先上HIS关键、电子病历，两个月后才上LIS、PACS。
项目开启会讲话人分别为：院长、X软领导、项目经理，即使最终X软领导未能成行，但开启会仍达成了良好效果。
【场景分析】
项目目标和预期效果：项目经理经过销售经理、信息科长直接和医院院领导面对面沟通，结合相关背景，有效掌握了医院对本项目标要求和期望，同时也了解除院长外其它领导关注点。
识别干系人：经过信息科长和销售经理了解各部门真实想法和期望，在实现项目整体目标前提下对项目计划方案进行调整。
召开项目现场开启会：在项目经理和信息科长精心准备下，开启会很成功。既让全院上下明白了此项目对医院关键性，同时也看到了系统未来对自己工作影响和改善，了解了X软企业在医疗行业发展，了解了项目建设阶段、推进方案，和下一步包含到自己具体工作。
项目初步计划：经过对网络布线工程进度、干系人要求和期望、企业目前资源情况、老系统使用情况等情况分析，对原有实施方案立即做出调整并得到医院认可。良好前期策划确保了项目按计划推进。
2.1.4 输出结果物
过程
活动
过程输出产物
是否必需
项目开启
项目立项
项目任务书
是
环境管理
环境确定Checklist(开发、测试、培训、实施、硬件、办公等环境)
是
环境管理
项目进驻现场条件评定汇报
是
环境管理
用户现场情况调查表
是
项目策划
项目组织结构图
是
项目管理制度
是
项目干系人管理表
是
项目初步计划（范围、目标、沟通、里程碑、）
是
风险管理
风险/问题管理表
是
配置管理
配置管理计划
是
质量确保
质量确保计划
是
管理评审
评审统计
是
开启会
内部开启会汇报
是
外部开启会汇报
是
会议统计及决议
是

2.1.5 参与角色及职责
角色
职责
用户方领导小组组长
同意项目开启计划，确定参与项目开启会时间、讲稿。
企业领导小组组长
同意项目开启计划，确定参与项目开启会时间、讲稿。
销售经理
配合项目经理在开启阶段和项目相关干系人沟通，搜集项目信息，编制项目初步计划，策划项目开启会。
项目经理
负责编制项目初步计划，策划项目开启会。
项目软件经理
帮助项目经理完成项目软件部分内容需求分析、开发实现、交付实施、售后服务等实施方案。
第三方项目经理
配合项目经理编制项目初步计划，负责完成第三方承建工作实施方案。
用户方项目经理接口人
帮助项目经理编制项目初步计划，和项目经理一起策划项目开启会。
PMO管理员
编制项目任务书，公布项目经理任命。
2.2 需求（现场）调研
2.2.1 过程概述
需求调研关键目标是定义项目标范围，具体描述项目最终可交付结果。了解用户相关业务背景，搜集相关资料，和用户干系人互动，了解干系人想法和期望，并对最终项目结果内容和特征达成一致，并用文字、图表、符号等语言进行具体描述。
需求调研是工作分解前提，是项目预算基础，是项目进度计划关键依据。关键任务有以下几项：
1）编制需求调研计划，确定需求调研内容、形式、方法和进度计划和需求变更管理等。
2）需求调查，为实现项目目标而定义并统计干系人需求过程。
3）需求分析，对项目目标和产品功效进行具体描述，形成项目验收标准文件，即《需求分析汇报》。
4）需求评审，组织项目干系人对《需求分析汇报》进行评审，以使甲乙双方对项目目标和产品功效描述达成清楚、一致了解，评审完成双方签字确定，形成项目范围基准。
5）需求变更管理，需求变更需要得到项目领导小组审批，需求变更是正常，但不能范围漫延，不能超出协议约定范围。
2.2.2 工作任务
2.2.2.1 编制需求调研计划
编制需求调研计划目标是让需求分析含有计划性，确保在有限时间和资源条件下，正确了解用户需求，完成需求分析任务。
项目经理依据招标文件、投标文件及协议文件等，和用户方接口人一起组织讨论需求调研计划，包含确定需求调查内容、形式、方法，分解需求调研任务，确定所需资源，分配工作任务，编制需求调研时间进度计划。
2.2.2.2 需求调查
需求调查目标是了解业务背景和干系人期望、需要，搜集意见和业务相关原始表单、信息，以备加工、分析和展现。
依据项目目标和业务系统特点，设计《需求调查表》，搜集最初步用户需求描述和业务相关原始表单。对回收《需求调查表》进行整理、分析，在必需时深入和用户沟通，以文字或图形形式大致描述双方对特定需求一致了解，并签字确定，形成需求跟踪矩阵。
2.2.2.3 需求分析
需求分析目标是为实现项目目标，整合干系人想法和意见、业务相关资料等，对项目可交付结果和验收标准进行具体描述。需求分析最关键工作是界定项目哪些是需要做工作内容，哪些是不需要做，就交付结果验收标准和用户达成一致。
在了解需求调查信息基础上，用文字、图表、符号等语言，以项目需求功效点形式，逐项对功效点进行描述，包含产品功效内容和特征、验收标准、制约原因、假设约束条件、除外责任等。描述越通俗易懂，越便于用户了解，越能和用户达成一致。需求分析时最好还包含验证功效点实现测试用例。
需求分析是一个迭代过程，需要不停和用户确定和调整。需求分析汇报越具体，项目验收中风险消极影响越低。需求分析过程输出是《需求规格说明书》。
2.2.2.4 需求评审
需求评审目标是让《需求规格说明书》得到用户干系人确实定。
需求评审能够是正式或非正式会议，能够是一次，也能够是数次，《需求规格说明书》可能会依据一次或数次评审意见不停完善，直到双方达成一致。签署《需求评审统计》。
2.2.2.5 需求变更管理
需求变更管理目标是管理变更，不是控制不变更，只要是在项目约定范围内，变更是合理。需求变更需要得到项目领导小组或变更控制委员会同意。
需求是干系人管理思想表现，通常人想全部可能存在一定不足或缺点。软件系统最终目标是帮助管理者落实管理思想，管理思想可能存在不停提升和完善过程，软件系统也会伴随这种改变而改变，所以改变是合理。许可需求变更不是意味着放纵需求变更，变更不能是随意性，需要得到领导层同意。需求变更率过高，说明有可能前期需求分析工作做得不太好，相关制约原因、假设约束条件、风险没考虑周全。
2.2.3 控制关键点
2.2.3.1 怎样有效开展需求调研？
为了有效开展需求调研，需要注意以下多个方面：
1、需求调研工作包含到众多项目干系人，需要编制具体计划。在什么时间和哪些部门业务责任人进行交流？需要搜集部分什么样材料？最关键是我们需求调研计划需要描述出此次需求调研目标和交付物，其中哪些文档是需要双方评审并签字确定？
2、需求调研中最关键干系人是用户方管理层或领导层。项目标范围是由管理层或领导层最初想法而逐步细化。所以调研应从管理层或领导层开始，了解、掌握了项目需求演变过程，更有利于项目团体识别更多项目约束、限制条件、和项目标风险，同时也有利于在随即实施层调研中把握项目总体目标、总体需求框架。
3、需求调研有多个方法，演示、访谈、书面问卷、会议等。有时候我们为了图省事，需求调研时演示一下系统、发部分书面问卷就完了，或经过部分会议进行调查搜集。这些方法并不是不好，而是不够。需求调研需要花时间和项目干系人充足交流，只有在双方经过数次沟通、交流，才会形成达成一致需求调研结果。访谈是必不可少，和干系人互动方能了解干系人真实想法和期望，这种访谈最好是一对一，而且是数次，对项目干系人需求进行口头或书面描述，然后不停确定。
4、需求调研时注意搜集原始表单和资料，需求分析结果就是在原始信息基础上进行创新、改善。有时候我们想要知道用户这个需求目标是为了实现什么？最直接方法就是看用户原来操作模式和原始表单和资料，经过这些信息我们能分析、判定用户真正目标，或许还能找到愈加好方法去实现。
5、需求调研时注意对用户进行正确引导，采取行业中最优处理方案，避免墨守陈规。现场需求调研是一项很有挑战性工作，用户常常受原