论项目的进度管理.doc

1、论项目的进度管理摘要: 本文讨论了“XX区XX局政务管理系统”项目的进度管理情况,在本项目中我作为项目经理承担了项目的日常管理工作。 2004年8月我参加了“XX区XX局政务管理系统”的开发，出任项目经理。该项目作为XX区电子政务重点工程的一个组成部份，受到局领导的充分重视，形成了一把手负责的气氛，为项目的成功打下了坚实的基础。 系统面向XX局下属的监理站、监测站、监督科、规建科四个业务科室的职能，实现了XX局在排污收费、建设项目三同时、污染源监测等日常政务管理工作的信息化，构建了面向环保局的电子政务解决方案。本文结合我的经验，从活动资源估算、活动定义、活动持续时间估算、活动排序、进度表制定、

2、进度控制等方面讨论了项目的进度管理工作。 本系统目前已经上线运行，大大提升XX区XX局的办公效率及政务公开的透明度，受到用户的好评。 正文： 一、项目概述： 为进一步加强XX区电子政务体系建设，加强XX区XX局政务公开的透明度，提升XX局面向污染源的监测能力，强化排污收费的征管力度及时准确进行建设项目三同时审批，实现面向上级单位及时、准确提供环保监测数据报表，通过互联网面向广大公众提供建设项目审批办理情况的查询服务，最终达到提升XX区环保局的综合办公能力的目标。在区领导、局领导的高度重视和支持下“XX区XX局政务管理系统”作为XX区电子政务的重点示范工程，于2004年8月启动了。 项目总投资8

3、0万元，要求2005年5月前全面竣工，投入使用。 系统要求采用框架进行开发，开发工具采用，实现基于模式的应用，数据库使用。硬件配置方面，购置了HPPC服务器，用于安装SQL SERVER 2000及WINDOWS 2003。 本项目配备了4个开发人员、界面美工1人，配置管理员1人、用户代表4人、质量管理员1人。界面美工、配置管理员、质量管理员为兼职人员，为多项目共享，用户代表来自XX局下属的监理、监测、监督、规建这四个科室，由业务经验丰富的工作人员出任。 经过项目组的并肩作战，通过8个半月的努力，项目终于在2005年4月中旬全面通过验收，正式上线运行。 在本项目的开发过程中，我从制作工作分解结

4、构（WBS）、活动资源估算、活动定义、活动持续时间估算、活动排序、进度表制定、进度控制等方面对项目进度进行管理，确保进度受控，尤其是跟踪关键路径上的任务执行情况，根据其执行情况及时调整进度计划表，确保了项目如期完成。 二、细化项目目标、制定WBS 在项目计划阶段，制定了初步的WBS，由于树立了一把手负责的项目气氛，与用户很快协商制定了详细的调研计划，并根据计划顺利开展了需求调研工作，摆脱了需求调研用户没人配合、需求调研报告无人签字等常见问题。 随着需求调研阶段落工作的不断深入，伴随着对项目目标不断得到细分，最终得到较为量化的工作分解结构即（WBS）。在制定WBS的过程中，经常与用户代表沟通，对

5、监理、监测、监督、规建这四个子系统的模块分解征求他们的意见，以使分解得到的可交附成果，获取他们的认同，加强他们参预项目的积极性，让他们对项目究竟要做什么有感性的认识。 三、以WBS为基础进行任务定义 在用户需求说明书编写完成后，将WBS作为用户需求说明书的附件一同提交评审，在通过评审的WBS基础上，开始了任务定义工作。在进行任务定义的过程中我们使用了专家判断法，对WBS底层工作包进行分解，得到任务清单。专家由经验丰富的开发人员、测试人员和项目经理组成，以保证任务清单的质量。比如为得到排污收费台帐这个工作包，必须执行数据后台统计、生成临时表、数据显示加载至页面、打印报表等任务完成后才能得到这个工

6、作包，而这种细分都是以专家判断的方式来进行的。采用类似的这种办法，我们得到了整个项目任务清单以及任务属性集合（即任务之间的逻辑关系，资源要求、强制时间、制约因素等属性。）和里程碑清单的第一个详细版本。 进行了第一次的详细任务定义后，使项目组对项目究竟要怎么做达成了共识。为任务资源估算、任务持续时间估算打下了坚实的基础。 四、进行任务排序、识别关键任务、确定任务之间的依赖关系 任务排序的作用主要是识别与记录任务之间的逻辑关系。在任务排序的工作中我们首次结合Project 2003这个项目管理工具，使用紧前关系绘图法，得到了进度网络图，确定了任务之间的依赖关系，尤其是强制依赖关系。比如只有页面基类

7、编码这个任务完成后，才能开始所有ASPX页面编码的任务，这种完成才能开始的依赖关系。 五、全面、有效、准确的估算工作 在本项目的估算工作过程中，我们结合面向对象的分析和设计技术，采用了专家判断为主，参数估算为辅的方法，从任务资源估算，任务持续时间估算两方面入手进行了全面的估算。 本系统基于架构开发，使用了面向对象的分析和设计技术，并充分利用抽象工厂，装饰等软件设计中的经典模式。利用上述技术我们得到了高复用的功能模块，如页面基类、数据库操作基类等，很多业务类都继承基类中已有的方法，大大提高了开发的效率。比如所有的WEB页面都继承页面基类，这样页面上的通用操作功能，如填充下拉框、查询表格数据显示等

8、功能就无需编写了，这使得我们的估算更易于近行并且更准确。 正是基于上述的技术我们使用了“专家判断”这个工具，面向任务清单和任务属性集合进行了任务资源估算、任务持续时间估算的工作，得到了任务资源要求，即有每个任务究竟要使用的资源类型和数量。比如说花多少时间完成工作流子系统的设计，要使用一个高级的开发人员一个月的时间，而页面基类编码则只需1个普通开发人员一周的时间。进行完“专家判断”后我们比较准确地得到了开发的整个工作量。 为对“专家判断”得到的估算工作量有个对比，我们还使用FP功能点分析这种参数估算方法对项目的整体工作量进行估算，对比两者之单的差异，以修正专家判断的数据。 六、制定进度表、确定进

9、度基准 在得到任务清单、任务属性、项目进度网络图、任务资源估算、任务持续时间估算这五个工作成果的基础上，我们结合PROJECT 2003项目管理工具，使用关键链法绘制了项目进度网络图，根据项目人力资源方面的约束计算出关键路径，确定了进度基准。确定了页面基类、数据库操作基类等关键路径上的任务。 七、以进度基准为依据，跟踪项目进度，必要时调整进度表 在确定项目的开发计划时，我们制定了详细的进度表，同时让每个小组成员知道自已承担任务的时间表，并且及时跟踪任务完成情况。 每个任务接受者都通过MS PROJECT 2003的IE客户端，填写任务完成情况，以使任务完成情况得到精确量化，这使得项目进度跟踪的

10、效果十分高效和可视化，通过甘特图可随时、直观地显示任务的完成情况，那个任务符合进度计划，那个任务已经延误，尤其是是关键路径上的任务，如页面基类等关键路径上的任务完成情况对其它任务和进度的影响，都可以准确的显示出来。这就为及时的进行偏差分析，并为是否调整项目进度提供了很好的依据，同时也为使用挣值这个工具打下了基础。 八、不足与展望 由于项目进度控制得当，项目按期完成，受到用户的好评。但是回顾整个项目历程，发现许多不足之处，典型的两点如下； 1、 使用Project 2003这个项目管理工具，由于是第一次使用，没有做好培训工作，导致大家对这个工具的使用一度有抵触情绪。 2、 FPA参数估算法与专家估算这两种方法所得到估算工作量差异巨大，没有找到合适的办法使两者对等。 除此之处，还存在诸多不足，在此不一一列举。 在以后的工作中，我将继续努力学习、实践PMBOOK，总结经验、记录体会，并与广大项目管理爱好者分享。