约“项目责任状”。在这次会议上，我作为项目经理向各项目干系人，就项目的主要项目目标、项目范围、范围管理计划、进度计划安排、沟通方式作了详细的介绍，希望各项目干系人能够积极配合我们的工作，我们将尽量满足他们的要求，方便大家今后的使用。
三、 定义规划好项目范围，充分做好项目的范围管理工作
在完成项目需求分析设计后，我们通过与项目干系人多次沟通后就项目所要达到的目标、项目需求、项目边界、项目的可交付物、产品接受标准、项目的约束条件、假设条件、项目组织结构、进度里程碑等一系列描述达成一致意见，并形成书面的项目范围说明书。
另外我们还采用MS Project 2003作为项目管理工具。通过Project，我们建立了项目的WBS，对WBS的每个任务明确了其可交付物，对每一个任务我们都要求细化到每个人在一周内完成，保证每一项目都是可控的，可管理的。同时我们还制定了完善了项目范围管理计划、WBS字典、范围变更计划及规程，并交由业主、项目监理单位审核后，经业主签字确认保存形成项目范围基线。
四、 开展项目评审会，做好范围变更控制工作
我们在项目范围定义时确定好重要项目的里程碑。在每个里程碑结束后，我们邀请相关项目干系人参与项目的评审工作，目的是为了防止需求偏差、遗漏，以及收集新的需求，每次评审都给我们带来不少好的建议，让我们充分发现系统中的不足之处，发现了诸多业务上的偏差。会后我们按照项目范围变更计划，与业主、监理单位一起对这些建议进行逐一评估，将那些有益于项目建设的纳入范围管理中来，对有益于项目建设的建议分别处理对待：1、该建议实施起来比较简单，投入成本比较低廉的、对项目实施进度影响不大的按照范围变更的程序进行实施，同时对实施的结果进行跟踪;2、对花费成本较高，对项目实施进度影响较大的建议则记录在案，留于下一版本开发或作为附加项目开发。
五、 落实项目小组责任，分别对待干系人的变更请求
在项目实施过程中，由于项目小组成员和业主许多部门许多人有联系，他们是最经常会遇到范围更改请求的人，因此我们强调统一口径，不是任何人提出的请求都必须响应，必须经过项目发起人同意的变更才可以响应，同时项目小组成员不得随意对项目的进行“镀金”变更。另外我们还加强项目小组内部的沟通和交流，提高项目开发团队的开发效率，加强质量措施的落实，对成员的职责和绩效进行考核，杜绝由于项目质量问题或技术问题引起的不必要的范围变更。
六、项目存在的不足与展望
项目实施成功后，通过了省相关部门组织的验收，同时作为先进典型模式向，周边市区推广，该系统至今运行良好。但是回顾过去，系统实施过程中也存在许多不足之处。
1、 前期调研虽然做了认真细致的部署但是还不够充分，如没有考虑到垂直系统部门的权力事项，没有考虑到并联审批的情形等。在系统实际运行过程，没有考虑到乡镇实际困难，好多部门的信息化普及远远跟不上，相关的工作人员使用起来比较不熟练。
2、 测试的时间太短，没有专门的测试人员，没有全面而系统的测试，所以系统交付之后，发现了不少问题，虽然没有威胁到系统的运行，但是作为项目经理，我觉得如果多给一些时间和人员，我做得更好。在以后的工作中，我将继续努力学习，总结经验和教育，为电子政务建设和企业信息化作出更多的贡献。