高项--优秀论文(9大知识领域各一篇)(2)

采购的货物众多（网络及安全设备、存储设备、服务器、负载均衡、统一认证、虚拟化平台、数据库、触摸屏等）等特点，为了保证项目圆满完成，我组建了强矩阵的项目组织结构，通过有效的项目管理，特别是出色的范围管理，带领项目团队全体成员经过奋战获得了良好的绩效，取得了项目的成功。本文将围绕该项目的范围管理进行重点讨论。

项目范围管理就是确保项目做且只做所需的全部工作，其过程主要在于定义和控制哪些工作应该包含在项目内，哪些工作不应该包含在项目内。当我接收该项目的时候，我非常清楚，项目范围是一个信息系统项目的龙头，是一个信息系统项目能否成功的前提，它是实施和验收等后续项目工作的依据，范围管理做得好，后续工作才能顺利。

鉴于对范围管理重要性的认识，考虑到在市级物价局做这样全方位的物价管理系统在省内还是第一家，在我公司也是第一次，因而项目一开始我就高度重视范围管理，我们遵循制定项目范围管理计划、定义范围、制定WBS、范围确认和范围控制五个典型的范围管理过程来进行项目范围管理。下面介绍我的具体做法。

一、制定项目范围管理计划

凡事遇则立，不预则废。进行项目的范围管理也是如此。项目启动后不久，在了解项目初步范围的基础上，我就组织项目成员制定了一个大致的《项目管理计划》，然后和项目组一起，在《项目管理计划》的总体轮廓下，依据该项目的章程和项目的初步范围，制定了《项目范围管理计划》（初稿），为范围管理的后续过程提供指南和依据。我们制定的《范围管理计划》的大致内容是：如何进行范围的定义、确认和控制，以及如何进行WBS的分解。

二、定义范围

在定义范围和调研需求方面，我花了相当多的时间和精力，目的就是要把项目需求这一源头搞清楚；在调研需求和定义范围过程中，我们主要采用的是访谈、会议和原型展示相结合的需求调研方法。初期我们主要采用访谈和会议，我将分析人员分成几个小组，每组2-3人，各小组根据区域划分深入市局各科室和区县物价局，与一线科员进行深入交流，了解他们的工作过程、存在的问题，以及他们对未来系统的期望等，每个地方驻点一周，每个地点驻点完成后要提交一份调研报告给我，每周（一般是周一早上）所有系统分析人员要召开一次碰头会，总结和交流需求调研的情况，会后形成汇总的需求调研报告。第一轮调研工作完成后，我们形成了《项目范围说明书（初步）》，然后我组织开发人员根据初步的范围说明书开发出系统原型，再由分析人员到各单位向系统未来的使用人员进行演示，进行了第二轮的需求调研。客户在这一轮的需求调研中表现出了较高的积极性，提出了很多建设性的意见，我们汇总这些意见后形成了《项目范围说明书（2.0版）》，根据2.0版的范围说明书，我再次组织开发人员进行原型开发，如此反复了几次之后客户对系统的需求基本定下，我找建设方的项目经理和分管

领导对《项目范围说明书》进行了签字确认，后续的变更就需要走变更流程才能对其进行修改了。同时我们也编制了一份《系统需求规格说明书》，作为项目组内部设计及后续开发、测试等的依据。在《项目范围说明书》中我们以客户能懂的语言描述了系统所要实现的功能、项目过程中需要提交的交付物、项目的验收标准、约束假设条件和项目的进度里程碑等。另外，我们对系统不实现哪些功能、不提交哪些交付物也进行了明确说明。

三、制定WBS

《项目范围说明书》得到用户确认后，我们进行了WBS分解。WBS的分解是一项非常重要的工作，好的WBS结构能使得原来看起来非常笼统、模糊的项目目标一下子清晰起来，使得项目管理有依据，项目团队的工作目标变清晰。由于WBS分解涉及到将要开展的具体工作，所以将来要做这些工作的项目成员最有发言权，我让小组的组长和骨干成员都参与到WBS的分解中。实践证明这样做既符合后续软硬件设计、编码、实施人员的实际水平，又能得到他们最大程度的认同。我们进行WBS分解时制定了如下原则：在各层次上都保证项目的完整性；一个工作单元只从属于一个上层工作单元；相同层次的工作包应有相同性质；工作单元应便于进行进度和成本的控制；工作包一般不大于80小时；采用滚动规划，不求一次把所有工作包都分解出来。据此我们的WBS分成四层，第一层是按照子系统划分的，包括十四个子系统和项目管理；第二层是按定义需求、设计、编码、测试、验收等生命周期来划分的；第三层是对第二层的进一步细化，比如定义需求又分成需求调研、需求分析、需求定义和需求验证等；第四层是对第三层的进一步细分，比如需求调研又分成客户现场访谈、会议、建立原型等。对于WBS中工作单元的细节信息，我们在WBS字典中加以描述。WBS分解是一项很重要的工作，在这一过程中我们发现《项目范围说明书》中存在较多不明确的方面，通过WBS分解而得到明确。WBS分解工作完成后，项目范围基准就确定了。

四、范围确认

项目可交付成果、子功能被开发出来之后，我们项目组内部先对其进行评审和测试，通过后，把这些成果交付给用户，和用户一道按范围基准、质量标准等要求进行范围确认（即验收）。由于该项目范围广、功能点多，我们找客户进行局部范围确认的频次较高，在里程碑点一般举行较为正式的会议，非里程碑点一般通过当面交流的方式，虽然这样做增加了不少工作量，但对于最后一次性通过竣工验收非常有利。在范围确认时，对于局部范围的确认，我们主要是邀请客户方、监理方参与评审和测试；对于全局范围的确认，主要是由客户方邀请第三方（按照该市政府的规定，为市电子政务项目专家组）进行评审。

五、范围控制

范围控制就是监督项目的范围状态，管理范围变更的过程。该项目用户范围广、功能多（涉及建设方工作的几乎所有领域）的特点决定了该项目在开发过程中避免不了范围的变更，在项目一开始我就很清楚，如果不做好范围的控制，该

项目很难在合同规定的时间内完成，预算也必然超支，所以项目一开始我就高度重视范围的控制工作。开始时我主要是在与客户签订的合同上下功能，将经过客户方确认的《项目范围说明书》作为合同的附件附上，同时在合同正文上明确范围变更的审批权限（即CCB由哪些人组成）和变更进行的流程；在项目进行过程中，果然有很多人提出这个那个新需求，要求添加进去，我让他们提交书面申请，说明经过批准之后才能实施，开始的时候很多人认为我们很难讲话，开始不配合工作，我拿出很多时间与他们沟通，说明这样做是为他们好。经过苦口婆心的说明，部分客户有所好转，但有部分客户很难讲话，我的工作一度陷入困境，这个时候我一方面对哪些“刁难的人”采用刚性的合同来“说话”，但更多的还是用“柔性”的沟通来解决存在的问题。功夫不负有心人，到项目结束的时候，大家都理解了我的做法，说我“做事很稳，有路数”。

╳╳市物价信息管理系统项目于2013年12月20日全部上线并顺利通过了用户的验收，在合同规定的日期前10天左右圆满完成了各项任务，至今已运行一年多时间，运行状况良好，得到用户的一致好评。在本项目的范围管理中，我总结了如下几条经验：事先要有明确的计划作为指导；关于范围控制方面，一定要在项目正式开始前与用户就变更的审批权限和变更的流程达成一致意见，最好能写进合同中（或签订补充协议作为合同的一部分），在项目进行过程中一定要严格按照变更的规定流程进行，要死死的扛住，多用沟通来化解客户的不理解；必须在《项目范围说明书》上多花一些时间，比如，把范围确认（验收）的标准事前就在《项目范围说明书》中尽量说明清楚，并且经过客户确认，这样可以避免客户当事人（特别是政府部门的人）“不敢轻易签字”的问题；WBS的分解最好让执行候选工作任务的当事人参与，因为唯有参与，才有认同。

项目虽然取得了不错的成绩，但也存在需要改进的地方，如：对项目边界之外可能会有哪些工作描述得还是比较粗糙，如果能在《范围说明书》中对不应该包括在项目范围之内的工作描述得更细一点，就可以很轻松地排除客户的一些变更要求，避免一些无谓的争执；在范围确认环节，常常因为客户忙，不能及时参与而耽误了不少时间，对于这个问题，应该找客户方的领导，让领导清楚地知道，客户方的项目经理是需要投入很多时间在该项目上的，让客户方的项目经理专职（基本上很难）或将项目的工作纳入其主要（至少也是重要）工作事项和绩效考核中，这样项目经理才有时间和积极性参与到项目中。

牢记不足，吸取教训，相信通过不断的积累和不懈的努力，我的信息系统项目管理能力一定可以得到不断提高。 第3篇

论信息系统项目的时间管理

【摘要】

2013年2月，我参加了╳╳市物价局发起的物价信息管理系统的建设工作，担任承建方项目经理，该系统提供物价监测预警等十四项主要业务功能，建设费用480万元，历时11个月于2013年12月成功上线并顺利通过了用户的验收。本文结合作者的实践，以该项目为例探讨了信息系统项目的时间管理，主要遵从活动定义、活动排序、活动资源估算、活动历时估算、制定进度计划、进度控制6个典型的过程进行项目范围管理。在该项目的时间管理过程中，我本着谁负责谁分解的原则进行活动定义，通过确定依赖关系进行排序，通过专家判断进行资源和历时的估算，通过资源平衡和模拟技术制定进度进化，通过每日、每周、每二周的控制活动进行进度控制，使得该项目在时间管理上取得了较好的效果。本论文的最后部分总结了我在该项目时间管理方面的经验和不足。 【正文】

╳╳市物价信息管理系统项目是在政府加强对市场物价调控能力的背景下于2013年2月由╳╳市物价局启动的，我公司中标该项目，中标金额为480万元，其中软件部分为360万元。本人在该项目中担任项目经理，负责项目的全面管理。项目历时11个月于2013年12月通过客户方的验收。

该项目旨在建立一套集物价信息采集、分析、处理、发布于一体的系统，包括价格监测预警、价格应急监测、价格监督检查、商品价格管理、价格认证管理、成本信息管理、价格信息发布、价格行政审批、价格调节基金监管、12358投诉举报联动、农村价格信息互动服务、收费管理、协同办公平台及物价门户网站等十四个子模块，涵盖了该单位的主要业务工作。系统采用J2EE体系结构，可实现B/S、手机客户端等多客户端接入，开发环境采用eclipse（Helios Service Release 1），数据库采用Oracle11g。

由于系统具有建设规模大（涵盖物价部门几乎所有业务），建设时间紧（建设期限为11个月），涉及的干系人多（内部干系人包括项目组各类成员、公司领导和相关部门人员，外部干系人不仅包括市局各科室，也包括9个区县物价局的相关人员），参与的项目成员多（高峰时达到31人，我将小组成员分为集成组、软件一组（负责WEB开发）、软件二组（负责手机客户端开发）三个小组），采购的货物众多（网络及安全设备、存储设备、服务器、负载均衡、统一认证、虚拟化平台、数据库、触摸屏等）等特点，为了保证项目圆满完成，我组建了强矩阵的项目组织结构，通过有效的项目管理，特别是出色的时间管理，带领项目团队全体成员经过奋战获得了良好的绩效，取得了项目的成功。本文将围绕该项目的时间管理进行重点讨论。

项目的时间管理是项目管理中的最大难点。在项目具体管理过程中，我根据项目实际情况，遵循时间管理的主要方法，对项目活动进行了定义、排序、资源估算、历时估算，然后制定了项目进度计划，并在项目执行过程中，对项目的实际进度进行监控，发现与计划之间存在偏差，及时采取措施进行纠正，或进行进度计划调整，使得项目的进度始终是可控的。下面具体介绍我的实际做法。

一、活动定义

活动定义是识别为完成项目可交付成果而需要采取的具体行动的过程。我们在完成项目范围说明书和WBS分解之后，在项目管理计划的指导下开始着手活动定义工作。我组织项目组成员本着谁负责谁进行分解的原则，对WBS中近期要完成的工作包进行分解，得到可以具体完成的活动。然后汇总形成文档，即项目活动清单。采用滚动规划的方法，随着项目的进展，项目活动清单也逐步清晰完善。

二、活动排序

有了项目活动清单，我组织项目组成员采用紧前关系绘图法、确定依赖关系、进度网络模板等工具和技术制定出项目进度网络图。在这一过程中最关键的就是确定各个活动之间的相互关系，能并列的则并列，不能并列的要确定活动之间前后依赖关系和约束关系，有了合理的活动网络图，才能制定出合理的进度计划。例如，在本项目中，开发WEB系统的小组和开发手机客户端的小组所进行的活动既相互独立有相互依赖，因而可以并行进行，但在某些时间点上又存在约束关系，一些在手机上实现的功能要等WEB系统完成后才能进行，我们经过几次反复调整之后才得到较为合理的网络图。

三、活动资源估算

对于活动资源的估算，我们主要是通过专家判断和历史项目类比的方法进行的。对于活动清单中的活动，我们组织项目组内有经验的人员参考公司以往项目的数据，先对其工作量进行估算，再根据总工期依据项目网络图中的相互依赖关系，并考虑风险因素，倒推出活动需要的时间，再根据人员的劳动生产率，计算出活动需要的资源数量。

四、活动历时估算

对于活动历时的估算，根据我们项目实践经验，它与活动资源估算常常是结合在一起进行的，在进行估算的时候，需要综合考虑时间的限制和资源的限制，平衡好活动的资源需求和时间要求。比如，当时间要求已确定的时候，就要更多考虑的资源的需求；当资源是给定的时候，就要估算时间需求；当二者都是限定的时候，就要考虑赶工等方法，以保证时间要求。所以，活动需要的时间和活动需要的资源是相互依赖的关系，需要在实践中根据实际情况灵活加以考虑。当然，在活动的工作量和资源都确定的情况下，活动需要的时间仍然存在不确定性，我们一般通过活动历时的三点估算法进行估计，以求得尽量符合实际的活动历时。

五、制定进度计划

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库高项--优秀论文(9大知识领域各一篇)(2)在线全文阅读。