医疗软件项目经理手册.docx

CHISC.NET - 国内第一医疗信息化网站 ,为业内人士提供最强大的交流共享平台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 场景分析：泸州医学院附属医院的项目启动【场景描述】2003年5月该项目以低价中标HIS、LIS，随后两周将进行合同洽谈，合同生效后项目立项，立项之后才能派人进驻现场。销售部门要求硬件集成部门提供系统集成方案、软件实施部门提供软件实施方案。在经过内部一些沟通后，初步选定了项目经理和项目软件经理，并根据公司历史类似项目经验，制订了系统集成方案和软件实施方案，同时还制订了需求调查表拟下发调查各部门需求。两周后，销售经理、项目经理、项目软件经理及公司相关领导赴现场洽谈合同。在交流会上发现医院对公司意见很大，对X软及X软产品缺乏了解，财务科、药剂科直接提出现场就要演示系统，而不是看PPT方案，甚至还有人不知道X软还能做医院管理系统。交流会原来要讲两个方案，在讲解完系统集成方案后公司主持人取消了软件实施方案的讲解，因为在那种紧张的气氛下，用户根本不关注什么方案，而是关注软件长什么样。在交流会后，公司领导约见了院长，就医院信息化建设进行了深入沟通，院长并没有太多的想法，他将此项目交给主管副院长全权负责。项目经理对这些情况了解不多，只知道这个项目将来可能会很困难。经过艰难的谈判，终于签订合同。2003年6月23日项目正式立项，在与医院相关领导沟通后，决定召开一个项目启动大会，宣传项目、宣传X软，以获取医院各科室对项目的支持。但现场启动会只安排了主管副院长、大区总经理的发言，而没有安排项目经理的发言，启动大会只达了宣传X软的目标，对于项目目标和预期效果、项目实施思路和方案，并没有详细讲解。在启动会后，医院领导和信息科一直认为项目能在6个月工期内实施完成，而这个项目最后的工期却是18个月。财务科、药剂科认为系统应该是成熟的，只需要做简单的培训即可上线，而事实上软件系统的流程设计与原有管理流程相差很大，随后开了很多次协调会才将原有流程调整过来。对于系统实施的具体方案，医院的预期与实际情况落差比较大，导致项目进度延期特别严重。特别是LIS系统，启动会前、会上、会后都缺少交流，医院认为X软的LIS可以系统完全满足他们需求，公司内部也认为LIS系统满足医院要求问题不大，但恰恰是LIS的实施对项目的进度产生了非常大的影响。【场景分析】项目目标和预期效果：表面上医院的目标是将老系统换掉，达到数据安全和稳定运行即可，但老系统只有财务和药品管理系统。医院选择上临床管理、LIS等系统一定是有想法的，这一点销售经理、项目经理在前期都未能就此充分沟通，未能让项目组其他成员和医院各个部门理解。识别干系人：虽然知道“一把手”工程的重要性，重视了院长和信息科长的交流，但忽视了主管副院长、财务科长、药剂科长、门诊部主任、检验科主任的交流，他们的关注点并不一样，对这个系统的期望也不一样，未能识别出对这个项目不支持的人，更缺少相应的应对措施了。召开项目现场启动会：虽然召开了现场大会，但只达到了宣传X软的目标，很多科室领导对本项目的目标、最终效果、阶段计划知之甚少，导致后期推进时很多不理解、不支持。项目经理需要解读医院领导的想法、目标、期望、关注点，通过项目实施方案系统性的讲解。项目初步规划：缺少风险分析，对医院硬件采购、网络布线、科室人员配合等情况掌握较少，对项目的一些约束条件沟通较少，导致医院一直认为X软能在6个月内全部实施完成。而HIS快要到上线时，项目组才发现有的科室连电源插孔都不够，在LIS实施时才发现两者对需求的理解相去甚远。通常很多医院会笼统的承诺只要项目开动，相关支持会到位，这时候必须将医院的协助工作分解，只有分解、分析后大家才能共同看清哪些承诺是不一定能达成的，约束条件、限制因素必须在启动阶段得到细致的分析和应对规划。2.1.3.5 场景分析：普洱市人民医院的项目启动。【场景描述】2011年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、需求调研工作涉及到众多的项目干系人，需要编制详细的计划。在什么时间与哪些部门的业务负责人进行交流？需要收集一些什么样的材料？最重要的