信息系统项目管理师论文材料及范例

./范文一论信息系统项目的整体管理[摘要]医疗保险管理信息系统涉及到医保管理部门、各定点结算点〔医院、药店、开发商,加之政策多变、业务不成熟,需求变化频繁,开发的难度和风险较大。在某市医保管理信息系统开发过程中,我作为用户方的项目负责人参与了项目的整体管理工作,我在项目整体管理中采取了针对性的措施,加强了参与各方的沟通,注重用户需求和需求的变化,合理配置项目组成员,对风险进行了及时的评估并顺利地控制了风险。通过这些办法,平衡了各方的利益,控制了项目的范围和进度,保证了项目的质量,顺利完成了这个项目。[正文]几年前,某市为实施城镇职工基本医疗保险,开发了一套医保管理信息系统,我作为用户方项目负责人,参与了项目管理、系统分析和编程的部分工作。这个系统的功能包含了基金征集和支付管理、参保单位〔职工管理、定点结算点管理、参保职工就诊结算管理、IC卡管理等,目标管理人数为30万、定点结算点200个,计划投资400万元；采用C/S结构,数据集中保存在市医保中心,定点结算点与医保中心之间数据实时交换。通过公开招标,明确了项目的范围、时间、成本和采购,因此,我把整体管理工作的重点放在了项目的质量、人力资源、沟通和风险管理管理,目的是保证实现计划的功能并按时投入运行。在工作中,我根据实际情况,采用了灵活的工作方法,取得了较好的效果。该系统在04年一次上线运行成功,目前运行情况良好。一、加强了沟通管理。该项目涉及到医保中心、参保单位、定点结算点、系统开发〔集成商等多个单位,从需求分析到系统设计、测试都要各方参与、协调配合,由于各方的地理位置十分分散,难以经常或长期集中,因此,各方及时有效的沟通是项目成功的必要条件。为解决好这个问题,我采取了三个办法：1、提高大家对沟通作用的认识,特别是各方主要领导人对沟通的必要性和重要性的认识,从而对沟通工作给予必需的人员、经费和时间支持,保证了沟通工作得以按计划进行。2、对项目组外部的沟通,坚持从实际出发,采用多种沟通的方式。一方面,把必要的、重要的沟通需要以联席会议、工作计划、总工作得以按计划进行。2、对项目组外部的沟通,坚持从实际出发,采用多种沟通的方式。一方面,把必要的、重要的沟通需要以联席会议、工作计划、总结报告的形式制度化。另一方面,在适用的前提下,采用灵活、经济的沟通方式,比如：对一般的小问题或者是简单问题进行电话交流,复杂一点的问题开碰头会,需要后续解决的、比较重要的及涉及面较大的问题要形成书面的会议记要,有必要的情况下要由相关单位加盖公章确认。3、对项目组内部沟通,进行适当的控制,避免形式主义,在保证效果的前提下节省时间,提高工作效率。规定项目组成员在每天工作过程遇到问题,将其记录下来,然后在以邮件方式发送给需要沟通或者询问者。大家每天下班之前收取邮件,对于可以直接回答的问题则直接以邮件方式回复,对于无法直接答复而只需与提出问题者讨论的问题,在第二天上班前进行商议确定。而需要众人一起讨论的问题,则放到每周会议上讨论,较紧急的问题召开临时性会议。通过以上方法,基本上实现了有关各方及项目组内部的有效沟通,及时发现问题、解决问题,避免了因各方立场不一致造成严重对立而影响项目进度,避免了因交流不畅形成重大质量问题。二、合理配置人员。对项目组人员进行规划配置,合理分工,明确责任,保证项目各阶段、各方面的工作能够按计划完成。我们在项目组长配置了以下人员：技术组长一名,负责技术难题攻关,组间沟通协调；需求人员5名,负责将用户需求转换成项目内的功能需求和非功能需求,编制项目需求规格说明书,针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名,负责对需求规格说明书,进行系统设计；开发人员8名,实现设计,完成用户功能；集成人员1名,负责整套系统的编译集成,督促小组系统功能提交,及时发现各模块集成问题,起到各小组之间的沟通的纽带；测试人员2名,对于集成人员集成的版本进行测试,尽可能的发现程序缺陷,以及未满足需求的设计；文档整理人员1名,负责对小组内产生文档的整合,统一；维护人员1名,系统验收后,维护人员,建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。在人员的管理方面,一方面要求项目组成员相对稳定,以保证开发工作的连续性,另一方面,不搞终身制,不能够胜任职工作的坚决调换,保证项目整体工作不受影响。通过平常和阶段性的工作考核、评审,对不合格人员进行调换。有一名需求分析人员因为工作态度不好,与客户单位业务人员关系恶化,调查落实后,我们立即把他调出项目组。三、进行风险评估,在进度和质量之间进行权衡,争取最佳平衡点。由于项目资金已经确定,我就在进度和质量之间找平衡点,力争把风险降到最低。由于医疗保险业务本身比较复杂,加之当时国家政策不稳定,业务流程不是很规范,系统需求也在不断调整、完善,给项目的进度带来一定影响。由于这个项目涉及到十余万参保职工的医疗待遇,影响很大,通过与用户方领导沟通,决定不搞"形象工程",在质量和进度之间优先考虑质量。同时,考虑到这个项目的采用了增量开发模型和模块化的设计方法,我把项目目标进行了分解,涉及到业务经办的部分优先完成,保证系统在规定的时间上线运行,其它不影响业务经办的、辅助性的功能适当延期,包括医疗监督、统计分析和部分报表。这样虽然整体工期有所延长,但没有影响系统及时上线。这种做法同时照顾到各方的利益,把整体风险降到了最低。论文范例7：论项目的风险管理摘要风险就是会给项目带来威胁或机会的一些不确定性事件．2003年5月,我参与了某机场信息系统集成项目的建设,并担任项目经理工作。整个项目总投资近亿元,建设工期为3年．因为信息系统集成在当时的国内民航系统来说,还是新兴技术,熟悉民航业务和信息集成技术的专家和技术人员很少,加上项目投资规模大、建设周期长,因此,该项目的风险很大。为了按照既定的进度、成本和质量完成项目的目标,在该项目中,我充分重视了风险管理,根据风险管理理论,结合自己的项目实践,按照风险管理计划编制、风险识别、风险分析、风险应对计划编制、风险监控等过程,有条不紊地进行风险管理．加之进行了良好的配置管理,整个项目建设过程中,始终遵循了变更控制程序,使该项目顺利完成了其目标．2006年3月,该项目建设完成,并在机场开通时投入生产运行,目前运行稳定．正文项目是在复杂的自然和社会环境中进行的,受众多因素的影响．对于这些内外因素,项目管理人员往往认识不足或者没有足够的力量加以控制．项目的过程和结果常常出乎人们的意料,有时不但未达到项目主体预期的目的,反而使其蒙受各种各样的损失,而有时又会给他们带来很好的机会。项目同其他经济活动一样带有风险．要避免和减少损失,将威胁化为机会,我们就必须了解和掌握项目风险的来源、性质和发生规律,进而实行有效的管理．项目风险是一种不确定的事件或条件,一旦发生,会对项目目标产生某种正面或负面的影响．风险有其成因,同时,如果风险发生,也导致某种后果．当事件、活动或项目有损失或收益与之相联系,涉及到某种或然性或不确定性和涉及到某种选择时,才称为有风险．以上三条,每一个都是风险定义的必要条件,不是充分条件．具有不确定性的事件不一定是风险．2003年5月,我所在的单位承接了双机场的机场信息系统集成项目的建设工作．该项目是国家重点建设工程项目的一个子项目,其主要工作是应用EAI框架,集成机场内其它各个重要信息系统,实现数据共享,整个项目总投资近亿元,建设工期3年．2006年3月,该项目建设完成,并在机场开通时投入生产运行,该信息系统集成项目以ORACLE9i为平台,建立了一个可存储机场航班信息、管理信息和运营信息的综合中心数据库,开发了航班信息管理系统、机位自动分配系统、外场管理系统、机场资源管理综合系统等,构造了千兆以太网统一的网络平台,采用了EAI框架集成了这些新开发的系统外,还集成了机场内其它各个重要信息系统如航班信息显示系统、离港系统、广播系统等,连接机场外的许多相关系统如空管飞行信息系统、财务系统、航空运营系统等,实现不同应用操作平台的集成、异构数据库的集成,达到数据共享,应用集成。在该项目中,我担任项目管理工作．到2003年为止,我虽然已经负责了近10个项目的开发和管理工作,但当时被安排担任该项目的项目经理时,感觉确实是一大挑战．因为信息系统集成在当时〔2003年的国内民航系统来说,还是新兴技术,熟悉民航业务和信息集成技术的专家和技术人员毕竟很少,因此,这种项目的风险很大。为了按照既定的进度、成本和质量,完成项目的目标,在该项目中,我充分重视了风险管理,按照项目风险管理理论,结合自己的项目实践,有条不紊地完成了该项目．具体来说,我是按照以下基本的管理过程来进行风险管理的。1.风险管理计划编制在项目初期,我组织有关人员编制了风险管理计划,具体描述如何为该项目处理和执行风险管理活动．我们采用会议的方法来制定风险计划的,因为该项目投资规模比较大,所有的项目干系人代表都被邀请参加了风险管理计划会议,全面地考虑了风险对项目的影响,制订充分的风险管理计划。在计划中,我们确定了基本的风险管理活动〔如每15天召开一次风险评估会议,根据项目管理理论和我公司的项目实践,定义了项目中的风险管理过程,估计了风险管理的时间表和费用,并把风险管理活动纳入了项目计划,把风险管理费用纳入了成本费用计划。2.风险识别根据项目的实际情况,我们把项目中的风险划分为技术风险、团队风险、外部风险三大类,采用风险分解结构〔RBS形式列举了已知的风险,如图1所示。在识别了上述风险后,我们还确定了这些风险的基本特性,引起这些风险的主要因素,以及可能会影响项目的方面,形成了详细的风险列表记录．根据试题的需要,在这里我只列出引起风险的主要因素,其他的方面限于时间和篇幅,不再介绍．风险名称引起风险的主要因素对工作的分析和评估不足缺乏类似的项目管理管理经验,对项目工作不熟悉对EAI架构不熟行业内没有使用先例关键人员流动项目周期长,需要长期出差缺乏合适的技术人员项目周期长,异地开发没有正确理解业务问题项目干系人对业务的认识不足、信息化水平低预算不能按时到位甲方资金受限3．风险定性分析我们根据风险管理计划中的定义,确定每一个风险的发生可能性,并记录下来．除了风险发生的可能性,还分析了风险对项目的影响,包括对时间、成本、范围等各方面的影响．其中不仅仅包括对项目的负面影响,还分析了风险带来的机会。在这个过程中,我们还是采用会议的方式来进行的．不过,在风险分析的会议中,除了有关项目干系人外,我们还邀请了相关领域的专家参加,以提高分析结果的准确性。例如,对于技术类风险的分析,我们就邀请了业内著名的架构专家参与评估。在确定了风险的可能性和影响后,接下来需要进一步确定风险的优先级。风险优先级是一个综合的指标,其高低反映了风险对项目的综合影响．我们采用了风险优先级矩阵来评定风险优先级的．最后得出的结果是架构风险排在第一位,该风险的可能性很高,影响也很大。4．定量风险分析对已知风险进行定性分析后,我们还进行了定量分析,定量地分析了各风险对项目目标的影响．在这个过程中,我们采用了专家评估的方法,组织相关成员对项目进行乐观、中性和悲观估计,同时,也利用了我公司历史项目的数据,用来辅助评估．进行定量分析之后,更新了风险记录列表．5．风险应对计划编制根据定性和定量分析的结果,我们对已识别的风险,制订了应对计划。对不同的风险,采取了不同的措施．风险名称应对措施对工作的分析和评估不足利用已有经验,加强学习,利用标准的技术和理论对EAI架构不熟聘请EAI专家做技术顾问,加强对有关人员进行架构培训关键人员流动紧密团结"少数人",提高顶目完成奖金,实行人才备份制缺乏合适的技术人员在当地招聘部分技术人员,加强制度建设,加强培训没有正确理解业务问题加强对机场人员的培训,提高其信息化水平预算不能按时到位在合同中明确规定,由此引起的后果由甲方负责6．风险监控经过上述5个过程后,该项目中的风险已经比较清晰,这时就要进入风险跟踪与监控过程．在这个过程中,我们对已经识别出的风险的状态进行跟踪,监控风险发生标志,更深入地分析已经识别出的风险,继续识别项目中新出现的风险,复审风险应对策略的执行情况和效果。根据目前风险监控的结果修改风险应对策略,根据新识别出的风险进行分析并制定新的风险应对措施．在这个过程中,我们主要采用了偏差分析、项目绩效分析和监控会议的方式来进行的。总之,该机场项目由于技术领先、投资规模大、建设周期长、异地开发等原因,充满着风险,但由于我们＋分重视项目的风险管理,加之进行了良好的配置管理,整个项目建设过程中,始终遵循了变更控制程序,使该项目顺利完成了其目标．2006年3月,该项目建设完成,并在机场开通时投入生产运行,目前运行稳定,得到了机场方的肯定,由此,我得到了公司董事会的嘉奖．信息化建设的项目管理计划、实施和控制目前,电子政务、企业管理信息化等已成为信息化建设的热点。这些以业务、数据流程信息化为主的建设项目相当复杂。有数据表明,这类信息化建设项目在国内外成功的比例都不是很高。正因如此,项目管理引起这个行业人士的普遍关注。同样,也有数据表明,西方国家的一些企业采用项目管理后,项目成功的比例有显著提高。作者根据十多年项目管理实践经验,以及研究、培训和咨询的知识积累写就这篇文章,相信对信息化工程项目的建设者会有帮助。本文涉及信息化建设项目管理的内容包括：项目经过的阶段；项目的计划、实施和控制；开发商对项目的管理；用户对项目的管理；项目的组织问题等。一、信息化建设的几个阶段信息化建设项目按时序划分,一般经过可行性研究、系统分析、系统设计、开发和测试、安装调试、运行维护6个阶段。1、可行性研究阶段可行性研究阶段段的主要任务是：识别需求,对项目产品进行描述,确定分阶段实施的进度,从业务、技术、经济效益等方面进行可行性研究,形成可行性报告。2、系统分析阶段系统分析阶段的任务是：对现行系统进行详细调查,分析业务流程,分析数据与数据流程,分析功能与数据之间的关系。指出现行系统存在的问题和不足之处,确立新系统的基本目标和逻辑功能要求,最后提出分析处理方式和新系统的逻辑模型。这个阶段也称为逻辑设计阶段。逻辑设计解决系统"做什么"的问题。因此,这个阶段是整个系统建设的关键阶段。系统分析阶段的工作成果为"系统说明书",这是系统建设的必备文件。系统说明书既要准确又要通俗易懂,用户根据系统说明书可以了解未来系统的功能,判断是不是他们所要求的系统。"系统说明书"一经通过,就是系统设计的依据,也是将来评价和验收系统的依据。3、系统设计阶段系统分析阶段的任务概括地讲,已解决了系统"做什么"的问题,系统设计阶段要回答的问题则是系统"怎么做"。也就是说,根据系统说明书所规定的功能要求,考虑实际情况,具体设计实现逻辑模型的技术方案,即新系统的物理模型。这个阶段也称为物理设计阶段。这个阶段又可分成总体设计和详细设计两个阶段。这个阶段的技术文档为"系统设计说明书"4、开发和测试阶段开发和测试阶段是按物理设计方案付诸系统实现的具体工作,包括开发与调试程序,采购硬件。这个阶段的工作量很大。在这个阶段,开发工作要重视文档的建设,测试工作需要写出测试分析报告,包括功能"测试分析报告"和"系统测试分析报告"。5、安装调试阶段本阶段的工作包括：硬件设备与软件平台的安装调试,用户培训,数据文件转换,系统调试与转换等。安装调试阶段实现现有系统被新系统所替换,需要用户许多部门的参与或配合。为了使系统顺利转换,必须精心安排,合理组织,统筹调度和协调。6、运行维护阶段系统投入运行后,需要进行经常性维护和评价,记录系统运行的情况,根据一定的程序对系统进行必要的修改,评价系统的工作质量和经济效益。上述6个阶段,构成信息化建设项目的全〔整个生命周期。根据美国项目管理知识体系指南〔PMBOK的定义：项目生命周期开始于项目启动〔例如签订承包合同,结束于项目收尾〔例如按合同验收。因此,信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。参见下图。本文第二部分内容——项目计划、实施和控制,是基于项目生命周期来考虑的。由于项目管理其实是一种方法论,因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。二、项目计划、实施和控制1、整体计划整体计划的核心内容包括：范围计划、时间计划、成本计划和组织计划。1范围计划项目范围由工作分解结构〔WBS界定。工作分解是一种以结果为导向的分析方法,用于分析项目所涉及的工作。工作分解结构中所包含的全部工作构成了项目的整个范围。工作分解结构是项目管理的一个非常基础性文件,因为它是计划和管理项目进度、成本和变更的基础。项目管理专家认为,没有包含在WBS中的工作是不应该做的。信息系统建设项目的工作分解结构,第一层通常是由前面所述的项目生命周期的4个阶段组成,第二层则包括每个阶段需要完成的可交付成果,第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果,…。工作分解结构层次的多少,以便于管理为划分标准。相同的项目,不同的人会做出不同的工作分解结构来。工作分解结构最底层的可交付成果叫做工作包。2时间计划时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。时间计划通常用表格或甘特图、里程碑图来表示。网络计划技术中的关键路径分析、并行工程等技术方法,可用来优化时间计划安排。由于有项目管理软件的支持,生成时间计划图表,以及用网络计划技术优化时间安排都变得十分地容易。3成本计划①制订资源计划资源计划确定了为完成项目中各活动所需要的资源〔人、设备、材料。WBS是项目资源计划最基本的输入。②成本估算成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素,通过有关算法与工具〔项目管理软件或电子表格算出完成项目所需各种资源的成本估计值。③成本预算成本预算是为了确定测量项目实际绩效的基准计划,而把整个成本估算分配到由WBS确定的各工作包上去。成本预算和成本估算通常是同步进行的。④成本基准计划成本基准计划是一种按时间分段的预算,可以用来测量和监控项目成本的绩效。按时段把估算的成本叠加起来即可求得成本基准计划。4组织计划组织计划是,利用责任矩阵确定WBS中各工作项的责任单位；利用组织图确定报告关系。但是,组织计划结果的具体形式受企事业单位的组织结构制约。〔关于项目的组织问题,在本文第五部分解析。2、项目实施项目实施总是一个阶段接一个阶段地进行的,前一个阶段的结果为下一阶段提供输入。信息化建设项目中,第一阶段的结果"系统说明书",为第二阶段系统设计提供输入；第二阶段的结果"系统设计说明书",为第三阶段的开发工作提供输入…。每个阶段实施工作也都要首先做个计划,这个计划是为完成WBS工作包而采取的行动计划,包括：基于各项活动的基准进度计划,角色、职责分配计划。类似于前面讲到的组织计划,角色、职责分配也利用了责任矩阵这种方法,只不过在这里是把职责分配到个人。项目子产品、产品实际上产生于项目实施过程中。3、项目控制项目控制包括绩效控制和变更控制1绩效控制绩效控制目的是使工作结果与计划保持一致。上面讲到,项目子产品、产品产生于项目实施过程,因此在这个过程中必须持续测量相对于项目基准计划的绩效,以便将实际绩效和基准计划进行比较,并以此为基础采取相应的纠正措施。测量绩效的方法主要有两种,一是挣值测量,一是进度跟踪。而且,这两种方法通常是结合起来使用。①挣值测量挣值测量在西方国家是测量绩效最常用的方法。它综合了范围、成本和进度测量,帮助项目管理队伍评价项目绩效。挣值测量涉及三个关键值：l计划值〔PV：在规定时间内花费的获得批准的成本预算部分l实际成本〔AC：在规定时间内完成工作发生的实际成本l挣值〔EV：在规定时间内实际完成工作的价值不难看出上述三个关键值是三个关于时间的函数。由于函数曲线呈S形状,所以通常称之为S曲线图。这三个值提供了评价工作绩效的测量尺度。包括l进度偏差〔SV：SV=EV-PVl成本偏差〔CV：CV=EV-ACl进度绩效指数〔SPI：SPI=EV/PVl成本绩效指数〔CPI：CPI=EV/AC②进度跟踪进度跟踪是输入实际工作进度,然后与基准进度计划比较,找出各项活动进度上存在的偏差。利用项目管理软件进行进度跟踪极为方便、有效。有了绩效测量结果,接着便是对偏差原因进行分析,进而根据分析结果决定纠正措施。纠正措施没有什么新东西,都是平时习以为常的一些方法,比如对进度偏差有赶工、快速跟进〔有些书上叫做并行工程等措施。理论著作上对这些方法的外延问题讲得很多,原因是在采取这些措施时,要考虑可能带来的许多问题,但这些都不是本文所要描述的内容了。2变更控制变更控制的目的是维护绩效测量基准的完整性。也就是说对基准计划的变更予以控制。基准计划变更包括：范围基准计划变更,时间基准计划变更和成本基准计划变更。一般说来,只有项目范围变更才会影响测量基准。但是,在某些情况下,进度延误或成本偏差非常严重,需要"重新确定基准计划"才能提供测量进度或成本执行情况的切合实际的数据。基准计划变更是很慎重的事,应该：l建立正式的变更程序l由变更控制领导小组负责批准或否决变更申请l定义正式文档变更的步骤前面已经讲了,一般情况下只有范围变更才会影响测量基准。而在信息化建设这样的高科技项目中,范围变更往往是因技术〔功能、性能要求的变化而起。项目管理中讲到的配置管理,讲的是项目过程中的技术管理问题。配置管理内容包括：l识别工作项或系统的物理特征和功能特征l控制这些特征的任何变更l记录和报告这些变更l审计这些工作项和系统以证实其与需求相一致。进行配置管理的目的是,项目过程中任何技术上的变更都要在范围变更中反映出来,并要得到有关各方的一致认可。三、开发商对项目的管理无疑,开发商是信息化建设项目中的主角。对项目计划、实施和控制方面的工作,开发商都需要重视。计划方面信息化建设项目往往带有较多的创新成份和不确定性,项目成果在出来之前,并不确切知道它会是什么样子。因此,用户的需求和任务目标在整体计划中都不容易表述得十分具体,特别是对要实现的功能的规定往往有相当程度的灵活余地。由于这些原因,整体计划中的工作范围、完成各项工作〔由WBS定义所需的时间和费用都较难以准确估计,所以整体计划工作必定是一个反复修改的过程。实际工作中,人们往往因为"计划赶不上变化"而不愿做计划或只做一个大致的计划。专家认为,项目管理的首要任务是计划！计划！还是计划！先哲说："凡事预则立,不预则废"。因此,尽管信息化建设项目中存在诸多变数,但细致的整体计划工作是必须要做的。实施方面项目实施过程中,项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口〔界面。对于信息化建设项目,在系统设计与开发、测试阶段,对各种技术接口的管理极为重要。而在系统分析与安装调试阶段,协调组织界面是项目管理队伍的重点工作。实施过程中,项目队伍成员必须按计划做事！比较我们与西方人做事的习惯不难发现,西方人总是按文档〔当然首推计划规定去做事,而我们做事主观随意性较大。应该学习和接受西方人的做事习惯！控制方面挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目管理者粗放式管理惯了,不习惯于做较精细的管理工作。当然,在信息化建设这类高科技项目的管理工作中,对工作量完成百分比做比较准确的估计〔这是使用挣值测量法的前提有些困难,也是人们不愿使用这种工具的一个原因。但笔者的体会是：对工作量完成情况做个百分比估计,比不做要好；对于类似项目第二次做时,对许多工作完成情况的估计还是有较好的置信度的。变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素,这里不一一讨论了。四、用户对项目的管理在项目生命周期内,用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商,因此对成本的控制不是用户主要考虑的问题〔当然,非固定总价合同情况除外。而对范围、进度、质量等方面的管理是基于同样的标准的,即是说项目所有的技术和管理文档以及任何变更后的版本,都是开发商和用户达成一致意见后形成的。在项目生命周期内,用户项目队伍重在参与。在系统分析阶段,没有用户项目队伍的重要参与就不可能产生好的"系统说明书",也就不可能有好的项目成果。在安装调试阶段,没有用户项目管理队伍的协调、调度,转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段,用户应着眼于未来的运行维护,派技术人员全程参与工作,其必要性有二：一是未来系统运行维护的重要责任,要求技术人员必须深度了解系统的技术情况；一是系统将来必然会不断升级,要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家,不可等同于一般维护人员,也不同于一般网管人员,这点应引起用户的重视。有些情况下,用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段,用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的,可能并不很清楚,这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段,从职能上说,项目监理与项目管理是差不多的。五、项目的组织问题对于信息化建设项目,多数开发商、用户单位的内部组织都是传统型〔职能型的,即组织的结构是按职能划分的。在这种结构体系里,对项目的组织往往是非正式的〔用户方面更是如此。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是,当认为某个项目很重要时,就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中,我们都能看到有这样的说法：信息化很重要,信息化建设工作应该由一把手亲自抓。对信息化建设的项目管理工作,由一个领头干活的人负责显然不行,但由一把手亲自抓的观点,也非常值得商榷。本文开头提过,信息建设工作是很复杂的事情。"复杂"体现在两个方面：一是把业务流程、规范、标准等搞清楚,并据此确定要建一个什么样的系统很复杂；一是技术实现上复杂。负责信息化建设的项目经理,应有这两方面的知识与经验。从开发商方面看,该项目经理应有很好的技术背景,同时要熟悉所服务行业的业务情况；从用户方面看,这个项目经理应非常清楚本单位的业务流程,同时对技术有一定的掌握。一把手是企业战略层面上的管理者,很难要求他管好信息化建设这样具体而复杂的项目。保证信息化建设项目的顺利进行,应从组织结构上着手。矩阵型组织〔参见下图是西方国家许多企业采用的一种项目组织类型。在这种组织结构里,职能部门经理承担职能性职责,项目经理承担项目职责。所谓扁平化管理指的也是这个意思。从图中不难看出,项目经理需要在全公司内整合资源来完成项目工作。要做到这点,首先应赋予项目经理必要的权力。高层经理应充分认识到,负责=职责+职权。上图显示出,项目经理和职能经理的权力是平行的。要重视信息化项目建设工作,高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。这里应该强调的是,矩阵型组织是一种现代型组织结构,重视这种组织结构应用,其意义不仅仅局限在信息化建设过程中,对处在产品或服务转型期的各行业来说,都有重要的现实意义。结束语本文阐述了信息化建设中的项目管理。然而,在当今信息化社会里各行业都应重视项目管理。时代的变化已越来越快。产品生命周期短了,一种型号的产品推出后,很快就被功能更强、性能更好的产品所取代；对服务的要求更高了,与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项,服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此,我们不仅要在信息化建设中重视项目管理工作,还需要在广泛的社会领域中重视项目管理。航空票务系统项目进度管理[论文][摘要]2004年6月,我作为项目经理开始参与某航空公司航空票务系统项目的开发,主要负责系统的组织规划实施开发与项目管理,该系统具有严格的安全,稳定,时实高效和可靠性能要求,该系统由票务管理系统和呼叫中心系统两部分组成,呼叫中心系统主要实现电话,传真和短信业务,票务管理系统是整个系统的核心,采用了struts+hibernate+spring主流WEB应用框架,实现了WEB应用服务器websphere与协作应用服务器lotusdomino的高度集成.项目的成功很大程度上归功于我在项目过程中各阶段对进度的有效管理和控制,本文以该项目为例,结合作者实践,讨论信息系统项目中的进度管理问题,主要通过在计划阶段做好工作量估算,在项目的全过程中有效管理和控制风险因素,在实施阶段进行进度跟踪和控制,必要是调整进度表等方法和策略来有效管理和控制项目的进度,目前该系统已正式投入运行,状况良好受到客户一致好评.[正文]2004年6月,2004年6月,我作为项目经理开始参与某航空公司航空票务系统项目的开发,主要负责系统的组织规划实施开发与项目管理,当然还做一些编码工作,主要是公用基础代码和核心代码的编写与维护。航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来,采用先进的ＣＴＩ技术和语音板卡技术,充分利用电话,短信,传真,因特网等信息化手段,解决航空公司的机票销售问题,规范了业务流程,强化了内部管理,与电子商务的完美结合,使应用系统功能更加完善,提高了整个航空业务的工作效率。其中,票务管理系统包括：客户管理,机票管理,票证管理,销售管理,财务结算,调度管理,远程营业部〔代理商／分销商管理,系统管理八大功能模块,并统一于服务器端软件模块。呼叫中心系统由电话呼叫系统,短信分发系统,传真呼叫系统三部分组成。票务管理系统是整个系统的核心,在本次开发中,我把它视为整个项目的重点。票务管理系统采用struts＋hibernate＋spring主流ＷＥＢ应用框架,使用ＲＵＰ软件工程方法,开发工具采用了ＷＳＡＤ５.０,ＷＳＡＤ５.０集成并扩展了Ｅclipse２.０的功能。硬件配置方面,ＩＢＭＲＳ／６０００用于安装websphere５.０,DELL服务器用于安装DOMINOR6和ORACLE10g数据库,系统平台采用WINDOWSNT实现了WEB应用服务器与协作应用程序服务器LOTUSDOMINO的高度集成,并使用SINGLESIGNON〔SSO实现单点登陆。总体架构思想：用spring搭建整个框架,用hibernate取代原始的JDBC操作,并进行持久化管理,在spring中采用Bean来管理整个持久化层和访问层,与hibernate相连接进行数据库操作,视图层和控制器层通过STRUTS筐架实现,模型层是数据访问层DAO和hibernate的结合,数据库层功能使用ORACLE数据库实现。在本系统中将订单数据的生成分析采用关系数据库实现,通过webspher架构实现业务逻辑处理,机票订单的生成和审核流程则由DOMINO进行驱动,将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来,确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。由于考虑到寒假和春运期间将会是旅客的高峰期,客户要求系统必须在12月底前交付,项目开发周期为6个月,为此我做了如下安排：前4个月主要集中精力用于开发票务管理系统,后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作。软件的进度管理是软件项目管理中一个非常重要的组成部分,进度管理的目的是通过执行项目进度管理过程和使用一些基本的项目管理工具和技术来控制项目的进度,保证项目如期完成。项目组整体上把按进度和预算交付项目作为我们最大的挑战,因此我十分重视项目进度的管理和控制,在本项目中我们借助项目管理软件MicrosoftProject2003来辅助进度和成本的计划与管理,我们主要通过在计划阶段做好工作量估算,在项目的全过程中有效管理和控制风险因素,在实施阶段进行进度跟踪和控制,必要是调整进度表等方法和策略来有效管理和控制项目的进度。1.计划阶段做好活动历时〔工作量估算.项目需求分析阶段结束,《软件需求说明书》得到客户的正式签字确认后,我们开始创建工作分解结构WBS和制定详细的进度表,我们认为工作量的估算是制定进度表的基础,对于项目的进度管理十分关键,由于我们对代码行〔LOC估算和功能点〔FP估算等估算方法研究不是很深入,工作量的估算还是主要采用基于公司项目历史绩效数据库和个人经验的估算方法,对于部分涉及流程的活动单位一般很难一次性把握其活动历时,事实上流程调试的工作量一般在页面基本功能〔增加/删除/修改的3倍工作量以上,例如销售模块—机票预定—顶单生成流程页面提交工作量为2日/人,而流程调试要涉及20多个角色和8条路径,对于把握不是很好的估算,我们一般通过一个乐观估算A,一个悲观估算B,一个正常估算M三次估算后利用PERT公式[1〔4*M+A+B/6]计算后取整,每项活动我都先确定具体的人员,然后需要对活动本身进行详细的分析,必要时查看公司项目历史绩效数据库,最后需要为各项活动建立依赖关系,明确各项活动的前置任务,活动的开始时间,结束时间。总体上讲活动历时的估算工作量较大,我花了数个工作日.项目组流动率较底,在J2EE和STRUTS架构下的WEB应用开发已有一定的项目积累和团队合作基础,如项目组自行开发了功能完善的STRUTS-CONFIG..XML统一维护工具,实现了FormBean和AcationBean的方便管理,有大量可供复用的东西,如公用基础代码,权限管理模块等,这些也是我们在工作量估算中应该考虑的因素.2.项目全过程有效管理和控制风险因素.项目中我们对项目进行了必要的风险管理,以避免风险时间的发生导致进度的失控,公司项目管理部门提供了完整的项目风险管理计划模板和风险时间列表模板,为了让项目组在项目各个阶段保持良好的风险意识,我尝试采用了"十大风险事项跟踪",把项目中各主要的风险时间按照排名张贴在公告栏上,由于当时有部分未明晰的需求包括：客户订票流程,调度管理部分需求,客户方面可能提出新的需求…需求范围界定不清,计划不充分,用户参与不足,缺乏领导支持,技术问题等成为我们项目的主要风险事件,事实表明,这种做法非常有效。特别是客户方面,我定期把风险事件列表EMAIL给客户方负责人李某,为了能尽快落实未明晰的客户需求,我与客户方负责人李某进行了面对面的沟通,通过一番利弊关系的陈述,达成了尽快明晰悬留部分需求的共识,需求问题很快得到解决,项目组整体信心十足,积极性和责任感增强,公司领导方面对项目组也表现出特别的关心,特别是公司胡总开始频繁的出现在项目组每周的进度评审会议上,他们也开始担心因对项目支持不够而导致项目失败。3.实施阶段进行进度的跟踪和控制,必要时调整进度表。实施阶段要进行进度的跟踪和控制,在确定项目开发计划时,我们制定了详细的工作进度表,在确定每项任务时都确定了该任务的工作量,开始时间,结束时间,持续时间,同时要让每个小组成员都知道自己承担的任务时间表,根据自己的任务制定详细的工作计划.工作日志是了解每个小组成员工作情况的最好方式,我要求每个小组成员都要对自己的工作情况做日志,详细记录自己每天的工作。在每周5下班前通过内网B/S项目管理信息系统PMIS提交《项目周报》,把各自本周内完成的任务进度情况和下周任务计划做出汇报,报告要严格按照百分比量化任务完成的情况,因为PMIS只提供具体的百分比选择,每个小组成员都要对自己的总结报告做出负责,我把各项任务实际完成数据输入到项目进度计划中,Project自动完成甘特图的绘制,通过查看甘特图就可以交好的把握项目的总体进度绩效,随时了解项目进度,并确定是否调整下一阶段的进度计划,在本项目中,为保证项目快速完成,在定义甘特图任务的依赖关系时,我在没个任务的任务信息对话框中"前置任务"一栏中的"延阁时间"我填入10%,也就是说当任务完成90%的时候就可以结束转入执行下一任务,因为本项目的所有人员几乎是全程参与,我所以不是很担心,每个任务遗留的少量问题,在下一阶段每人去负责解决。航空票务系统在2004年12月下旬正式上线,提前完成了项目,目前系统运行正常,受到客户和有关部门的一致好评,对项目的满意度较高。项目成功很大程度归功与在项目各阶段的对进度和成本的有效管理和控制,没有进度管理,项目很难如期交付,对项目质量,进度,成本三大目标的实现有巨大的风险。通过这次开发我也发现了一些问题和不足,实际工作量与计划工作量偏差较大,看来还是受到缺乏经验数据或者经验数据不够精确的影响,所以在以后的工作中要展开有效的度量工作,为公司积累覆盖面广而精确的经验数据,还有就是团对成员的协作程度不高,未最大限度的发挥团队的凝聚力,在沟通方面我还做的不够,在以后的项目中我会不断的努力和改进。

ERP项目的风险管理摘要本文讨论了某公司实施SAP系统的风险管理．该公司原先运行着一套ERP系统,现在要转到SAP上,需要完成新系统的流程的重新定义,数据的切换,用户的培训等工作．项目要求在11个月的时间内完成．实施一个大型的ERP系统有着各种的风险,这些风险如果不加分析和控制,将会给整个项目造成致命的影响．我作为项目经理,主要从控制进度风险,人员流动风险和系统功能风险三个方面去进行风险的管理．最后这三方面的风险都得到了有效的控制,从而使项目顺利完成．正文2003年1月,我参与了西门子集团下某公司的SAP留系统的实施,提任项目经理．该公司之前运行着另一套ERP软件：QAD的MFG/PRO系统．由于集团总部的要求,要用SAP系统替换原先的MFG/PRO系统,并且要在2003年11月前完成．整个项目完成以下阶段,首先是项目的引进,包括成立项目小组,由顾问对项目小组成员进行初步的培训,让小组成员对SAP的标准流程有个大概的认识．接下来是要分模块进行讨论,制定出各模块的实施蓝图<blueprint>．该公司实施了以下的模块：SD〔销售与分销,MM〔物料管理,CO〔成本控制,QM〔质量管理,PP〔生产控制,FI〔财务核算,CO〔成本控制等．在Blueprint完成后,由顾问根据定下的流程配置一个测试的系统,用户在该测试环境下进行练习和测试．测试完成后就是数据的准备和切换了,要从MFG/PRO系统把需要的数据下载下来然后你上传到SAP系统。完成数据的切换,SAP系统正式上线,同时不再使用原先的系统。因为整个项目要在11个月的时间内完成,时间是非常紧迫的．如何在如此短的时间内使项目能顺利进行,控制各种可能出现的风险是必要的．为此,在项目的初始阶段,我召开了小组成员开会,专门针对项目的风险进行了讨论．会上,大家把想得到的风险都提了出来．经过分析筛选,我最后确定了三个重点进行控制的风险,并采取了相应的措施进行控制．1、控制进度风险ERP的实施是一个大型的项目,涉及到企业的流程改造和其它方方面面的东西．而该项目的上线时间不能改变,所以,项目进度在这里是个潜在的风险,如果不能如期上线,则公司的运作将会受到重大的影响．为此,我在项目启动后,召集了项目小组成员开会制定项目计划．我首先用MicrosoftProject制定了项目的总体计划,在这个总体计划中,明确了各个阶段的任务和完成时间．如什么时候完成设计蓝图〔Blueprint>,什么时候进行关键用户的培训,什么时候进行测试和练习,什么时候进行数据的切换等．总体计划制定出来后,各顾问在总体计划下制定各模块的实施计划,把每个模块在每一阶段的问题细化．各模块的实施计划要在总体计划的基础上进行,在任务和时间上不能滞后于总体计划．无论是总体计划和实施计划,都要求明确各步完成的时间,要精确到哪一天,而不能用模糊的描述,比如"3月初完成Blueprint"这样的低描述是不充许的．为保证项日照进度进行,每周五都要召开项目会议,检讨项目的进展情况,发现有超期的任务,分析原因,及时解决．在进度的控制方面,还要应付突发的事件造成的影响,及时地调整计划以适应新的情况．2003年4月一5月,由于受到"非典"的影响,外部顾问不能出差来我公司,这使项目的进度受到了很大的影响．为了把这种影响降到最低,我即时调整了项目计划,把这段时间安排为关键用户的培训和对系统的熟悉。因为之前顾问已对关键用户进行了一些培训,所以用户对SAP系统有了一定的认识．通过上机的操作,更进一步了解系统．有问题我们通过E-Mail与顾问联系。通过这种方法,把原本以后进行的用户练习提到了前面．虽然没有顾问的现场指导,但通过自己的摸索对系统的印象更加深刻,为之后的工作打好的基础．2、控制人员流失的风险在实施SAP过程中,有两种可能会导致人员的离职,一是工作繁重乏昧,压力大；二是积累了一定的SAP经验后找工作相对比较容易,这时如果有其它更好的机会,员工会考虑跳槽．而项目小组人员流动将会对项目造成很大的影响,甚至导致项目的失败．所以如何控制这些风险,是作为项目经理要考虑的问题．为此,我首先与人力资源部一起,制定了一套有效的激励机制．包括,把参加SAP项目作为年终的一个绩效考核内容,因为项目需要加班加点的,公司免费提供晚餐；设立项目基金,对表现突出的小组成员进行物质上的奖励；在整个公司的范围内大力宣传SAP,让项目小组成员感觉到SAP的重要性和实施项目的价值等．其次,为了避免出现某个项目小组成员离职导致项目不能进展的情况出现,我在每个模块都安排了两个人员负责,一个是主负责,一个是次要负责．这样,可以减少人员流失造成的损失。在这里,我没有采用让项目小组成员签合同的方法,即实施项目后要在公司工作多少年。我觉得这种方法会给小组一种压抑的感觉,而公司主要靠企业文化来吸引员工．事实证明,我所采用的措施是有效的：在整个项目的实施过程中,没有一个小组成员退出或是离职．在项目运行一年多来,只有两个当时的关键用户离职,而他们离职后后备人员可以马上顶上来,对系统没有造成什么影响．3、控制系统的功能有人戏称SAP是"StopAllProduction",这也从一个方面反映了实施SAP的风险所在．而造成上了系统后停产的一个原因就是系统功能不能满足物流和生产的需要,这也是我担心的一个问题．因为切换后系统不能再使用,如果这时候新系统满足不了需要,就真的会造成停产．为此,我在项目中采用了演化型的原型开发方法,用演化型的开发方法,可以让用户针对已配置好的原型进行测试,发现不能实现的功能及时提出来,改进后再测试,再改进．在这里,测试工作显得很重要．为此,我强调一定要做好测试工作．在系统测试阶段,我把所有的项目成员集中在会议室中进行系统测试．在测试中,我要求用真实的数据,模拟真实的环境进行．系统测试通过后,我还特别做了一次上线前的演习,即把所有相关的数据都导致SAP,配置一个上线后要用的系统,在此系统上进行操作．这次演习成功后,坚定了大家使用系统的信心．系统上线后也没有出现什么大的问题．通过以上措施,使把SAP的主要风险基本上都控制在萌芽状态,项目没有因为这些风险受到影响,最后项目如期上线,受到了管理层和用户的肯定．在项目进行过程中,有些风险并没有事先预计出来．比如说顾问的问题．有的顾问水平高,但项目也多．用在我们这个项目上的时间就比较少,这给项目带来了不利影响．为此,我通过和该项顾问所在的公司签定合同,注明顾问在我们公司的工作时间,否则属违约,通过这一方式使顾问的管理得到改善．我国的项目监理项目管理是以可能的最高效率执行项目,做到按工期、按预算、按要求完成任务。今天,项目管理学科已经渗透到it行业的信息系统工程建设中,在同一个项目团队里,业主、承包商、监理三方如何相互协调配合,各司其职地做好工作？现代项目管理学为项目团队各方实现项目目标提供了有效的项目管理途径。我国加入wto后,工程管理应与国际接轨,当然,这必须以符合我国的国情为基础,与项目的实际情况相结合。目前,我国的大型信息系统建设工程正在逐步实行监理制。通过将美国项目管理学会〔pmi的项目管理知识体系〔projectmanagementbodyofknowledge,pmbok的基本内容与工程监理的主要职责相比较,我们认为,工程监理是现代项目管理的一种重要的表现形式,工程监理的工作职责中包含着现代项目管理学的基本内涵,我们要用现代项目管理知识体系来增强信息系统建设工程管理体系。我国的监理工程师是独立的第三方,业主、承包商、监理这个三角形不是等边的,监理向业主倾斜,接受业主的委托进行工作。it行业工程监理的主要工作内容是"三控制二管理",即对工程项目的质量、进度、费用等过程实施控制,同时对项目合同、信息等进行管理。我国实施工程建设项目业主负责制、工程建设招投标制以及工程监理制,这是我们在项目管理方面的基本国情,现代项目管理必须关注这一现实,it行业也不能例外。从本文的分析中可以看出,pmbok的基本内容与工程监理的工作内容有着十分自然的关联。项目管理知识体系美国项目管理学会〔pmi项目管理知识体系〔pmbok是对项目管理专业知识的一个总结。诞生于20世纪80年代的pmbok第一版由多名项目管理专家历经4年而成,之后分别在1991年、1996年和2000年对其进行了增订、完善和发展。pmbok把项目管理划分为9个知识领域,即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。国际标准化组织〔iso1997年以pmbok为框架提出了"项目管理质量指南"〔iso10006,成为iso9000族中重要的支持性技术指南。近十多年来,由于pmbok的基本内容跨越行业界限而得到"普遍认可",因而受到国内外专业学术领域的广泛重视。对信息系统的建设来讲,它同样具有指导价值,it建设工程项目团队,包括业主、承包商、工程监理,也将从中受益。项目管理与其他管理学科有着密切的关系,一般性管理方法为项目管理奠定了基础。pmbok是我国入世后十分走俏的洋证书pmp〔项目管理专业人员资格认证所需的专业基础知识。据报道,我国的项目管理知识体系目前也正在制订之中。项目管理与工程监理的比较比较之一:范围管理信息系统建设中的工程监理十分注意抓好系统需求分析,弄清系统该做什么,不做什么；严格为业主把好系统功能模型、信息模型关,为系统的进一步实施打好基础。项目范围管理的首要任务是确定并控制哪些工作内容应该包含在项目范畴内,并对其他项目管理过程起指导作用。从项目管理科学来看,项目生命周期的第一阶段始于识别需求、问题或机会,终于需求建议书〔rfp的发布。准备rfp的目的就是从业主的角度,全面、详细地论述为了满足需求需要做什么准备,要清晰地定义出项目目标,项目目标必须明确、可行、具体及可以度量,并与有关方面一致。it工程中有人爱炒概念、来虚的,这有悖于现代项目管理学的要求。pmbok将项目范围管理分成启动、范围计划、范围界定、范围核实、范围变化控制五个阶段。在范围界定过程中,通过将项目目标和工作内容分解为易于管理的几部分或几个细目,以助于确保找出完成项目工作范围所需的所有工作要素。工作细分结构〔workbreakdownstructure,wbs可以帮助我们更加明确项目的工作内容,它不仅定义了工作内容,同时也定义了工作任务之间的关系,明确了工作界面。项目的wbs是我们对工作计划、进度、费用、技术状态进行部署和跟踪控制等管理活动的基础。在信息系统建设过程中,人们常用数据流图、功能层次图、业务流程图等表示系统的功能模型,它们是从不同角度对系统功能模型的表达。而wbs则可以理解为是一种以管理为导向的系统功能模型,它有更丰富的内涵和外延。wbs是项目管理的核心工具,项目的计划、进度、成本、技术状态、资源配置、合同等方面的管理都离不开项目的wbs,它的建立必须注意体现项目本身的特点和项目组织管理方式的特色,并注意其整体性、系统性、层次性和可追溯性原则。wbs技术有力地支持了信息系统建设中的项目管理,是项目团队中管理人员必须具备的基本知识。比较之二：时间管理时间管理是项目管理中的一个关键职能,也被称为进度管理,它对于项目进展的控制至关重要。在范围管理的基础上,通过确定、调整合理的工作排序和工作周期,时间管理可以在满足项目时间要求的情况下,使资源配置和成本达到最佳状态。值得注意的是,进度是计划的时间表,应该按计划安排进度。计划决定需要做什么、谁去做、花多长时间、成本是多少等问题。pmbok提出,项目时间管理由下述5项任务组成：活动〔activity定义、活动顺序、活动时间的估计、项目进度编制、项目的进度控制。pmbok的进度管理与工程监理学在项目进度控制方面所提供的方法是基本一致的。我国三峡工程实施了项目管理,其中进度管理很有特点,使人很受启发。据报道,针对三峡工程的特点、进度计划编制主体及进度计划涉及内容的范围和时段等具体情况,确定三峡工程进度计划分为三个大层次进行管理,即业主层、监理层和施工承包商层。通常业主在工程进度控制上要比监理更宏观一些,但鉴于三峡工程的特性,三峡工程业主对进度的控制要相对深入和细致。这是因为三峡工程规模大、工期长、参与工程建设的监理和施工承包商多,任何一家监理和施工承包商所监理的工程项目及施工内容都仅仅是三峡工程一个阶段中的一方面或一部分,而且业主在设备、物资供应、标段交接和协调上的介入,形成了进度计划管理的复杂关系。为满足三峡工程总体进度计划的要求,各监理单位控制的工程进度计划还需要协调一致,这个工作自然要由业主来完成,这也就是三峡工程进度计划为什么要分三大层次进行管理的客观原因和进度计划管理的特点。项目具有惟一性,根据不同的项目组织结构,由业主负责,根据自己在项目团队中不同的角色,相互协调、共同搞好工程项目的进度管理,这在信息系统建设中也不例外。比较之三：成本管理pmbok对项目成本管理的思路非常清晰,分以下四步进行：<1>制订资源计划资源计划确定了为完成项目中各活动所需要的资源〔人、设备、材料。wbs是项目资源计划最基本的输入,需结合各种资源的使用要求,制订出项目的资源需求。<2>成本估计利用wbs、资源需求、资源单价、活动时间估计等成本要素,通过有关算法或项目管理软件得到项目的成本估计,即可算出完成项目所需各资源成本的近似值。<3>成本预算利用成本估计及wbs确认的项目的细目,考虑到项目的进度,将成本分配到项目的细目上,为每个工作包建立总预算成本〔tbc。一般当实际成本超过累计预算成本〔cbc时,就要注意调控了。<4>成本控制工程监理对投资控制的主要思路也是将实际支出与计划投资相比较,结合项目进展进行调控。这一基本思路与pmbok十分类似,但是,由于管理体制不同,特别是项目财会管理水平的差异,与其接轨尚需时间。比较之四：质量管理在信息系统建设中,监理工程师把系统质量控制当做头等大事来抓,从iso9000质量保证体系的高度来控制和规范项目团队中的各方行为。pmbok在介绍项目质量管理中指出,这一部分论述的质量管理的基本方案旨在与国际标准化组织在iso9000和iso10006质量体系标准与指南中提出的方案中相一致。因此,项目管理与工程监理在质量管理方面的指导思想是完全一致的,iso9000与iso10006相互支持,相得益彰。比较结果：基本一致在项目管理过程中,项目的范围、时间、成本和质量相互间是有冲突的,项目人员对项目的不同需求和期望也同样有冲突,我们需在它们之间寻求一种平衡,这就是项目管理的基本内涵。我们对pmbok中范围、时间、成本和质量与工程监理的主要职责做了对比分析,其结论十分明显：项目管理的基本内涵与工程监理的工作职责是基本一致的。pmbok提出可以用许多方式把关于项目管理的理论知识组织起来,而工程监理制则是一种符合我们国情的项目管理方式。项目管理还有着更丰富的内容,如风险管理、沟通管理、人力资源管理、采购管理、综合管理等方面,这些常常体现了项目的外部环境,它们与监理工作的合同管理、信息管理、协调项目团队等职责有一定的交叉,项目管理有着更全面、丰富的知识体系,而实际上,这也是在接受业主委托的条件下,为工程监理工作提供更丰富的工作内容。国际咨询工程师联合会〔fidic编制了用于工程项目管理的有关标准文件,其中,《业主/咨询工程师标准服务协议书》、《电气与机械工程合同条件》是国际公认和通用的权威文件,非常详细、具体规定了项目管理中的各方面,充分体现了pmbok对项目管理的要求。现代项目管理理论进一步推动了我国工程监理制实施的健康发展。按照国家技术监督局对监理工作的要求,北京德瑞塔公司一直将这些标准文件作为信息系统建设中工程监理的指导性文件,承接了一批大型信息系统建设的监理和项目管理工程,取得了较好的效果。论项目计划摘要本文讨论了一个作者参与的软件项目的项目计划制订的若干问题．项目所开发的产品是一种智能电子教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,并可以保存、编辑、打印用户输入的数据,联网的计算机也可以实时观看用户的书写过程,并且用户还可以通过投影在硬件端的PC机画面交互操作PC机．作者是该项目的软件开发组负责人兼软件架构师．作者针对项目计划的制定采取了：分而治之,逐步求精,经验数据三个主要策略,从而得到较好的效果．正文2002年6月,作者所在公司启动了一个项目,该项目开发出来的产品是一种智能教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容,联网的计算机也可以实时观看用户的书写过程．另外,用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机．作者有幸全程参与该项目的开发,并且担任了项目PC机软件开发组的负责人兼软件构架师的角色．对于这种实时通信且具有联网功能的软件项目,我认为首先需要制定一个良好的项目计划,才可以保证项目开发的成功．总结这次项目的经验,我认为行之有效的策略有三个,分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。一、分而治之将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀,这种方法人类已经采用了几千年．这里我们也可以用于项目计划的制定．因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力．为了解决这个问题,可以将整个项目分解为一些更小的组织体,逐一进行处理,这项工作也就是项目管理中的WBS〔工作分解结构。比如针对这次项目中采取的RUP开发过程模型,我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定,最后合到一块儿就是完整的需求管理计划．除了按时间段分解的角度来制定项目计划,我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作,根据每个工作流在四个阶段业界通用的工作量估计来制定计划,安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流,我认为以这种方式分解是合理的．同时因为本项目的特点,我省略了业务建模工作流,这是因为这次的产品是以硬件为主,软件为辅的消费类产品,所以业务建模不是那么必要了．以不同的方式分解项目,可以从多个不同的角度来制定整个项目计划,有利于全面、深入地了解项目,避免"瞎子摸象"的情况发生．二、逐步求精计划工作其实是一种管理未来、管理未知的工作,而未来是变化莫测的,还存在许多自身无法掌握的因素,因此存在很大的难度．而解决这一困难的法宝就是逐步求精．按照先框架后细节,先粗后细地进行项目的计划．比如在这个项目中,在接受这个项目后就开始了做了一个初步计划,这个计划的内容主要是做出时间上的安排．因为打算在2003年的月需要用这个项目的产品申请国家中小企业创新基金的支持,所以完成时间就定在了2003年4月,预留一个月用于写申请报告．总的时间进度确定后,大概分配了三个时间段：系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结．等到确定这改项目后的RUP开发模型后,就可以继续对项目计划进行第二改求精了。其实RUP过程中出体现了逐步求精的理念,比如在初始与细化两个阶段都要产生出项目计划的制品．这样我就可以在这个两个阶段对项目计划逐步求精,比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划,然后在细化阶段我再具体地制定每类计划的详细内容．比如在初始阶段时架构设计考虑以MFC为平台,根据这个决定软件开发计划的制定是比较粗略的,在细化阶段架构设计进一步详细,这时已经清楚各个模块和MFC的Doc/View主结构的接口定义,以及各模块之间的接口定义,这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代,第一次迭代计划一个月时间,第二次迭代两周时间,第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果,第二次迭代的主要任务是根据用户反馈进行修改调整．三、经验数据要制定一个良好的计划离不开精确的估算．不过项目计划是在项目开发的早期制定的,而在早期要完成精确的估算是非常困难的．要解决这个问题的关键就在于"经验数据"．由于整个软件产业都还十分年轻,经验数据的积累都普遍不足,才导致这一现象的出现．但是因为这次项目开发的产品在国内还没有开发过,再加上公司没有积累深厚系统的项目历史数据．针对面临的困难,我选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得,同时其数据功能TLF、EIF,以及事务功能EI、EO、EQ的计算对经验数据依赖不强,只需对概念理解正确一般就可以正确估算了．在估算成本的时候,因为公司以前的生产率数据是以LOC为单位的,我利用软件工程书籍中的"逆火"经验数据,将LOC转换为功能点单位,当然,这里必然导致一些误差。为了降低估算误差,最后使用Delphi专家分析法对估算结果进行了调整．Delphi方法是一种集策法,也就是通过多名专家对估计值的不断校正的方法．当然,请专家增加了项目成本,不过最后得到高质量的项目计划还是值得的．比如,在某专家的建议下我们改变了自行开发网络层组件的计划,而是采购现有的完全可以解决项目需求的成熟的中间件产品,这个策略的调整在后来证明是正确的．一开始犯错误的原因是由于我们网络开发经验不足把用户需求想复杂了．最后谈一下使用的工具软件．在制定项目计划过程中我采用了Microsoft的Project2003绘制甘特图．因为项目的进度安排是和项目中每个人都是息息相关的,所以在做甘特图前我首先征集了大家对文字和条形图效果的意见,然后按大家的意见进行了美化,比如用鲜艳的颜色标识关键任务,放大任务摘要信息,突出里程碑信息等．这在有些项目管理者看来似乎是小事,不过我认为一个赏心悦目的甘特图可以带给观看者好的心情,而好的心情可以大大提高工作效率。同时,考虑创新基金支持的项目在交互期限上有很大压力,所以在定义甘特图任务的依赖关系时我采取了业界惯用的"时间盒"的技术,也就是在每个任务的任务信息对话框中"前置任务"一栏中的"延隔时间"我填入5%-15%,也就是说当任务完成90%左右时就可以结束转而执行下一个任务．因为本项目中的所有人员几乎是全程参与,所以我不是很担心每个任务遗留的少量问题在下一阶段没有负责人去解诀。配合Project2003使用的估算软件是SoftwareProductivityResearch的KnowledgePlan.这款工具软件的最新版加强了对MicrosoftProject2003以及RUP开发模型的支持,而且其中的ProjectTemplate功能允许用户采用自己定制的WBS来进行估算,这些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助．在上述三个策略的指导下,以及合适工具的辅助下,使最后形成的计划有效地指导了后期的开发活动。项目开发出来的产品通过了专家的鉴定,获得了国家中小企业创新基金的支持．项目完成后发现的问题是早期计划的估算结论偏差还是较大,看来还是受到缺乏经验数据或者经验数据不够精确的影响,所以在以后的工作中需要开展有效的度量的工作,为公司积累覆盖面广且尽量精确的经验数据．项目管理的沟通管理发布：华夏学习网时间：2006-11-04回想一下你所经历的项目,有没有出现过以下这样的情况：客户在检查项目阶段成果时,指出曾经要求的某个产品特性没有包含在其中,并且抱怨说早就以口头的方式反映给了项目组的成员,糟糕的是作为项目经理的你却一无所知,而那位成员解释说把这点忘记了；或者,你手下的程序员在设计评审时描述了他所负责的模块架构,然而软件开发出来后,你发现这和你所理解的结构大相径庭……可能你遇到的情况比上面谈到的还要复杂。问题到底出在哪儿呢？其实很简单,就两个字??沟通。以上这些问题都是由于沟通引起的,沟通途径不对导致信息没有到达目的地。"心有灵犀一点通"可能只是一种文学描绘出的美妙境界。在实际生活中,文化背景、工作背景、技术背景可以造成人们对同一事件理解方式偏差很大。在项目中,沟通更是不可忽视。项目经理最重要的工作之一就是沟通,通常花在这方面的时间应该占到全部工作的75%～90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。沟通管理的体系一般而言,在一个比较完整的沟通管理体系中,应该包含以下几方面的内容：沟通计划编制、信息分发、绩效报告和管理收尾。沟通计划决定项目干系人的信息沟通需求：谁需要什么信息,什么时候需要,怎样获得。信息发布使需要的信息及时发送给项目干系人。绩效报告收集和传播执行信息,包括状况报告、进度报告和预测。项目或项目阶段在达到目标或因故终止后,需要进行收尾,管理收尾包含项目结果文档的形成,包括项目记录收集、对符合最终规范的保证、对项目的效果〔成功或教训进行的分析以及这些信息的存档〔以备将来利用。项目沟通计划是项目整体计划中的一部分,它的作用非常重要,也常常容易被忽视。很多项目中没有完整的沟通计划,导致沟通非常混乱。有的项目沟通也还有效,但完全依靠客户关系或以前的项目经验,或者说完全靠项目经理个人能力的高低。然而,严格说来,一种高效的体系不应该只在大脑中存在,也不应该仅仅依靠口头传授,落实到规范的计划编制中很有必要。因而,在项目初始阶段也应该包含沟通计划。设想一下,当你被任命接替一个项目经理的职位时,最先做的应该是什么呢？召开项目组会议、约见客户、检查项目进度……都不是,你要做的第一件事就是检查整个项目的沟通计划,因为在沟通计划中描述了项目信息的收集和归档结构、信息的发布方式、信息的内容、每类沟通产生的进度计划、约定的沟通方式等等。只有把这些理解透彻,才能把握好沟通,在此基础之上熟悉项目的其它情况。在编制项目沟通计划时,最重要的是理解组织结构和做好项目干系人分析。项目经理所在的组织结构通常对沟通需求有较大影响,比如组织要求项目经理定期向项目管理部门做进展分析报告,那么沟通计划中就必须包含这条。项目干系人的利益要受到项目成败的影响,因此他们的需求必须予以考虑。最典型也最重要的项目干系人是客户,而项目组成员、项目经理以及他的上司也是较重要的项目干系人。所有这些人员各自需要什么信息、在每个阶段要求的信息是否不同、信息传递的方式上有什么偏好,都是需要细致分析的。比如有的客户希望每周提交进度报告,有的客户除周报外还希望有电话交流,也有的客户希望定期检查项目成果,种种情形都要考虑到,分析后的结果要在沟通计划中体现并能满足不同人员的信息需求,这样建立起来的沟通体系才会全面、有效。语言、文字还是"形象"项目中的沟通形式是多种多样的,通常分为书面和口头两种形式。书面沟通一般在以下情况使用：项目团队中使用的内部备忘录,或者对客户和非公司成员使用报告的方式,如正式的项目报告、年报、非正式的个人记录、报事帖。书面沟通大多用来进行通知、确认和要求等活动,一般在描述清楚事情的前提下尽可能简洁,以免增加负担而流于形式。口头沟通包括会议、评审、私人接触、自由讨论等。这一方式简单