计划方面信息化建设项目往往带有较多的创新成份和不确定性，项目成果在出来之前，并不确切知道它会是什么样子。因此，用户的需求和任务目标在整体计划中都不容易表述得十分具体，特别是对要实现的功能的规定往往有相当程度的灵活余地。
由于这些原因，整体计划中的工作范围、完成各项工作（由WBS定义）所需的时间和费用都较难以准确估计，所以整体计划工作必定是一个反复修改的过程。实际工作中，人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。专家认为，项目管理的首要任务是计划！计划！还是计划！先哲说：“凡事预则立，不预则废”。因此，尽管信息化建设项目中存在诸多变数，但细致的整体计划工作是必须要做的。
实施方面项目实施过程中，项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口（界面）。对于信息化建设项目，在系统设计与开发、测试阶段，对各种技术接口的管理极为重要。而在系统分析与安装调试阶段，协调组织界面是项目管理队伍的重点工作。
实施过程中，项目队伍成员必须按计划做事！
比较我们与西方人做事的习惯不难发现，西方人总是按文档（当然首推计划）规定去做事，而我们做事主观随意性较大。应该学习和接受西方人的做事习惯！
控制方面挣值测量作为一种项目监控工具在我国使用得不多。主要原因是我们的项目管理者粗放式管理惯了，不习惯于做较精细的管理工作。当然，在信息化建设这类高科技项目的管理工作中，对工作量完成百分比做比较准确的估计（这是使用挣值测量法的前提）有些困难，也是人们不愿使用这种工具的一个原因。但笔者的体会是：对工作量完成情况做个百分比估计，比不做要好；对于类似项目第二次做时，对许多工作完成情况的估计还是有较好的置信度的。
变更控制可能是信息化建设项目中最需要但又是最困难的事。范围无止境的蔓延常常是让开发商苦不堪言。控制范围蔓延涉及到许多方面的因素，这里不一一讨论了。
四、用户对项目的管理
在项目生命周期内，用户对项目的管理主要在进度控制、范围核实、质量把关等方面。由于通常是采用固定总价合同把项目承包给开发商，因此对成本的控制不是用户主要考虑的问题（当然，非固定总价合同情况除外）。而对范围、进度、质量等方面的管理是基于同样的标准的，即是说项目所有的技术和管理文档以及任何变更后的版本，都是开发商和用户达成一致意见后形成的。
在项目生命周期内，用户项目队伍重在参与。在系统分析阶段，没有用户项目队伍的重要参与就不可能产生好的“系统说明书”，也就不可能有好的项目成果。在安装调试阶段，没有用户项目管理队伍的协调、
调度，转换工作就可能陷于混乱状态。在系统设计与开发、测试阶段，用户应着眼于未来的运行维护，派技术人员全程参与工作，其必要性有二：一是未来系统运行维护的重要责任，要求技术人员必须深度了解系统的技术情况；一是系统将来必然会不断升级，要求技术人员能够为升级方案做重要贡献。系统维护人员是了解公司业务的技术专家，不可等同于一般维护人员，也不同于一般网管人员，这点应引起用户的重视。
有些情况下，用户可以雇佣项目监理来协助自己完成项目工作。特别是项目启动前的可行性论证阶段，用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的，可能并不很清楚，这时购买项目监理或咨询公司的服务是很有效的。在项目生命周期内的各阶段，从职能上说，项目监理与项目管理是差不多的。
五、项目的组织问题
对于信息化建设项目，多数开发商、用户单位的内部组织都是传统型（职能型）的，即组织的结构是按职能划分的。在这种结构体系里，对项目的组织往往是非正式的（用户方面更是如此）。所谓的项目经理一般也就是部门内部一个领头干活的人。而另一个极端的现象是，当认为某个项目很重要时，就可能由高层人物来负责这个项目。在一些媒体甚至某些高等教育教材中，我们都能看到有这样的说法：信息化很重要，信息化建设工作应该由一把手亲自抓。
对信息化建设的项目管理工作，由一个领头干活的人负责显然不行，但由一把手亲自抓的观点，也非常值得商榷。
本文开头提过，信息建设工作是很复杂的事情。“复杂”体现在两个方面：一是把业务流程、规范、标准等搞清楚，并据此确定要建一个什么样的系统很复杂；一是技术实现上复杂。负责信息化建设的项目经理，应有这两方面的知识与经验。从开发商方面看，该项目经理应有很好的技术背景，同时要熟悉所服务行业的业务情况；从用户方面看，这个项目经理应非常清楚本单位的业务流程，同时对技术有一定的掌握。
一把手是企业战略层面上的管理者，很难要求他管好信息化建设这样具体而复杂的项目。
保证信息化建设项目的顺利进行，应从组织结构上着手。
矩阵型组织（参见下图）是西方国家许多企业采用的一种项目组织类型。
在这种组织结构里，职能部门经理承担职能性职责，项目经理承担项目职责。所谓扁平化管理指的也是这个意思。
从图中不难看出，项目经理需要在全公司内整合资源来完成项目工作。要做到这点，首先应赋予项目经理必要的权力。高层经理应充分认识到，负责=职责+职权。上图显示出，项目经理和职能经理的权力是平行的。要重视信息化项目建设工作，高层管理者在职能经理与项目经理的权力平衡中就应更倾向于项目经理一边。
这里应该强调的是，矩阵型组织是一种现代型组织结构，重视这种组织结构应用，其意义不仅仅局限在信息化建设过程中，对处在产品或服务转型期的各行业来说，都有重要的现实意义。
结束语
本文阐述了信息化建设中的项目管理。然而，在当今信息化社会里各行业都应重视项目管理。
时代的变化已越来越快。产品生命周期短了，一种型号的产品推出后，很快就被功能更强、性能更好的产品所取代；对服务的要求更高了，与时俱进的人性化、个性化服务是不断摆在人们面前的课题。创新已是这个时代出现频度很高的一个关键词。产品创新需要立项，服务创新也是项目。项目的概念已超越了我们对它的传统认识。因此，我们不仅要在信息化建设中重视项目管理工作，还需要在广泛的社会领域中重视项目管理。
航空票务系统项目进度管理[论文]
[摘要]
2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，该系统具有严格的安全，稳定，时实高效和可靠性能要求，该系统由票务管理系统和呼叫中心系统两部分组成，呼叫中心系统主要实现电话，传真和短信业务，票务管理系统是整个系统的核心，采用了struts+hibernate+spring主流WEB应用框架，实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成.
项目的成功很大程度上归功于我在项目过程中各阶段对进度的有效管理和控制，本文以该项目为例，结合作者实践，讨论信息系统项目中的进度管理问题 ，主要通过在计划阶段做好工作量估算，在项目的全过程中有效管理和控制风险因素，在实施阶段进行进度跟踪和控制，必要是调整进度表等方法和策略来有效管理和控制项目的进度，目前该系统已正式投入运行，状况良好受到客户一致好评. [正文]
2004年6月，2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，当然还做一些编码工作，主要是公用基础代码和核心代码的编写与维护。航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来，采用先进的ＣＴＩ技术和语音板卡技术，充分利用电话，短信，传真，因特网等信息化手段，解决航空公司的机票销售问题，规范了业务流程，强化了内部管理，与电子商务的完美结合，使应用系统功能更加完善，提高了整个航空业务的工作效率。 其中，票务管理系统包括：客户管理，机票管理，票证管理，销售管理，财务结算，调度管理，远程营业部（代理商／分销商）管理 ，系统管理八大功能模块，并统一于服务器端软件模块。呼叫中心系统由电话呼叫系统，短信分发系统，传真呼叫系统三部分组成。票务管理系统是整个系统的核心，在本次开发中，我把它视为整个项目的重点。
票务管理系统采用struts＋hibernate＋spring主流ＷＥＢ应用框架，使用ＲＵＰ软件工程方法，开发工具采用了ＷＳＡＤ５.０，ＷＳＡＤ５.０集成并扩展了Ｅclipse２.０的功能。硬件配置方面，ＩＢＭＲＳ／６０００用于安装websphere５.０，DELL服务器用于安装DOMINO R6和ORACLE 10g数据库，系统平台采用WINDOWS NT 实现了WEB应用服务器与协作应用程序服务器LOTUS DOMINO 的高度集成，并使用SINGLE SIGN ON （SSO）实现单点登陆。总体架构思想：用spring搭建整个框架，用hibernate取代原始的JDBC操作，并进行持久化管理，在spring 中采用Bean来管理整个持久化层和访问层，与hibernate 相连接进行数据库操作，视图层和控制器层通过STRUTS筐架实现，模型层是数据访问层DAO 和 hibernate的结合，数据库层功能使用ORACLE 数据库实现。在本系统中将订单数据的生成分析采用关系数据库实现，通过webspher架构实现业务逻辑处理，机票订单的生成和审核流程则由DOMINO 进行驱动，将基于业务为主的J2EE服务系统和基于协作为主的DOMINO 流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。
由于考虑到寒假和春运期间将会是旅客的高峰期，客户要求系统必须在12月底前交付，项目开发周期为6个月，为此我做了如下安排：前4个月主要集中精力用于开发票务管理系统，后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作。
软件的进度管理是软件项目管理中一个非常重要的组成部分，进度管理的目的是通过执行项目进度管理过程和使用一些基本的项目管理工具和技术来控制项目的进度，保证项目如期完成。项目组整体上把按进度和预算交付项目作为我们最大的挑战，因此我十分重视项目进度的管理和控制，在本项目中我们借助项目管理软件Microsoft Project 2003来辅助进度和成本的计划与管理，我们主要通过在计划阶段做好工作量估算，在项目的全过程中有效管理和控制风险因素，在实施阶段进行进度跟踪和控制，必要是调整进度表等方法和策略来有效管理和控制项目的进度。
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给客户方负责人李某，为了能尽快落实未明晰的客户需求，我与客户方负责人李某进行了面对面的沟通，通过一番利弊关系的陈
信息系统项目管理师论文材料及范例
