通信项目管理管理要点分析模板.doc

通信项目管理管理要点分析

24

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。
项目管理12点思考

1、 项目组织运作

由于一些通信设施建设中需要大量复杂的协调工作,往往并非通信项目建设单位自身力所能及, 如对于电信网络的建设, 项目承建方往往无力协调通信企业的各部门如传输、 网管、 基建、 计划、 电源等工程相关部门的合作。在这种情况下, 通信企业往往必须与项目建设单位一样, 针对同一项目抽调专门项目相关人员, 还可能成立自己相应的项目管理组织, 协调配合项目建设单位的项目管理组织参与项目建设。此时, 项目建设单位, 项目业主人员, 还可包括如项目设备制造商、 系统集成方、 技术提供方、 项目设计单位等不同项目管理和项目工程人员面临如何工作协调配合的重要问题。
解决这一问题的做法主要有;
（1） 成立统一的项目管理组织, 同时共同成立项目决策委员会, 决策人员由双方共同 担任, 共同协商进行项目决策。
（2） 各自成立项目管理组织, 各自负责项目工作中的一个部分, 同时协商彼此的工作接口, 明确项目的工作程序。这种项目管理组织方式便于分工协作, 明确各自责任, 但必须有明确的分工和规范化的工作接口程序规定, 否则会出现推诿责任的情况。
（3） 以通信企业成立项目管理组织运作为主, 适当吸收项目建设单位等部分外部人员参与项目管理。在这种项目管理组织的运作下, 通信企业容易把握项目目标的实现, 容易进行通信企业内部有关的工程协调, 易于通信企业项目决策, 但同时通信企业需要担负相应的项目决策责任。
与此同时, 能够根据部分IT企业的做法, 根据项目的不同阶段以及不同内容, 在通信企业中成立相应的项目小组, 如:
项目领导小组: 主要负责审批项目计划、 对重大事情进行决策( 如项目范围、 项目风险等) 、 组建验收小组并主持验收工作;
项目验收小组: 属于项目竣工后临时成立的组织, 一般由项目领导小组主持, 各相关部门人员参与, 主要职责是确定验收内容, 并组织项目验收;
质量监督小组: 主要负责在系统实施过程中对工程质量进行监督, 一般由技术上较为资深的第三方参加;
项目执行小组: 主要职责是制定和控制项目计划、 合理安排资源、 确定业务需求等;
项目实施小组: 主要负责主机、 数据库、 各平台软件的安装与调试等;
项目文档小组: 制定项目文档管理计划及文档的输出、 归档等;
项目支持组: 主要针对技术难题的支持和问题的远程处理, 在项目实施过程中支持组无须全程驻扎在现场。
项目组织结构应保证用户的充分参与, 并充分发挥项目组织中用户资源的积极性。高效健全的项目组织结构是项目成功实现的有力保障。项目组织结构也要求每位成员必须能胜任其角色任务, 承担相应的责任。

2、 项目沟通是润滑剂

项目沟通管理的目的是使项目组内部成员和项目干系人能及时、 准确地得到她所需要的信息, 并能正确地理解相关信息。
良好的沟通机制是项目各干系人之间思想交流的重要保障。有效的项目沟通管理, 使全体项目组成员的思想高度统一、 步伐协调一致。因此, 项目沟通是项目管理的一个重要组成部分, 也是项目管理成功与否及执行好坏程度的一个关键问题。
一个项目涉及到的各种未知和风险因素很多, 需要协调的事情也多。项目经理的任务之一就是做好沟通和交流。项目的沟通包括项目组内的沟通及项目组与外部之间的沟通。
项目组内的沟通主要指项目组成员内部的交流沟通。为了让项目组每个成员都能很好地领会项目的目标和下一步计划, 让每位成员都清楚自己的任务和责任, 项目经理必须保持与项目组成员的日常沟通, 听取每位成员的工作心得及其工作进展情况, 激励项目组成员的工作积极性。
随时的交流与沟通: 对于重大的工程, 会不定期地或在每天下班后进行一次针对当天工作情况的小沟通, 时间较短, 一般在十几分钟内, 目的是为了及时发现项目中出现的问题, 并讨论解决措施。
定期例会: 每周五或周一项目组内部有一个定期交流会, 主题是互相交流一周内的工作进展情况; 分析已经出现和潜在的风险与问题; 总结项目实施中取得好的经验, 以保证每一位项目成员在项目中都能发挥出良好的作用。
与上级主管的沟通: 除了定期的周报和月报, 项目经理应与上级主管保持随时的交流与沟通。如果发生突发事件或重要情况, 项目经理应立即与上级主管联系, 使问题得到及时反映和解决。
项目组外的沟通主要是与用户之间的交流和沟通: 此类沟通的目的是, 使用户及时了解项目进展情况, 保证项目按照计划和用户要求的方向推进, 使用户认同项目的进度并建立预期。除了平时的口头沟通, 项目经理负责根据项目管理规范中的沟通计划( 比如双方定期的工作进展报告、 交流) , 反映项目实施中出现的问题, 并与用户协商解决方案; 正式提出需要用户提供的支持或配合事项及需要用户确定的业务流程等。在现场时, 我们每周都会与用户进行周例会总结工作、 制订计划, 并配合解决工作中遇到的相关问题。
每周的例会邀请用户相关各部门的领导参加, 有决定权的领导的出席, 交流会才有效果。我们应积极进行协调, 主动邀请用户主持此类的会议。经过增进与用户的沟通, 分散和降低项目实施的风险, 保证项目最终的顺利割接和验收。

所有与用户之间的交流沟通、 项目组内部每周的例行沟通都要列入会议纪要, 并统一作为项目管理的文档输出一部分。项目沟通的方式能够多种多样: 可采取面对面沟通、 电话沟通、 电子邮件沟通、 传真沟通或书面报告等多种方式。沟通是信息的传递, 也是相互之间加深了解的桥梁, 作为项目经理, 必须掌握一定的沟通方法和技巧。

3、 项目责任界面要清晰

一个项目的成功往往涉及到多方的合作, 特别是需方的参与。在许多的工程项目中我们发现: 客户会产生一种依赖性, 认为我花钱买了你的业务, 应该什么都是你来做, 我只需看到预期的结果。实际上, 一个项目的成功很大程度上取决于供、 需双方的配合程度。
经常有遇到过因责任界面不清晰而导致项目成本大幅上升甚至项目失败的情况。在某个112系统的项目实施中, 因对测试头进行调测时涉及到修改交换机数据, 需要用户配合完成, 但用户认为合同已经签订, 全部的工作都要由供方来做。经多次协调, 用户同意修改, 却提出每个交换局必须由供方支付费用的要求, 这样的情况, 整个项目显然已无法再进行下去。回过头来思考一下不难发现, 如果在技术方案或施工前期明晰双方的责任界面, 就不会发生此类情况。
项目责任界面按不同的实施阶段进行划分, 明确列出哪些是需方的责任, 哪些是供方的责任, 并标明完成时限。这样可有效避免施工中的种种被动局面的出现, 并促使项目在双方的共同协作下朝着既定的方向发展。

4、 项目计划要到位

项目计划是由管理者对资源、 成本和进度进行合理的估算。项目计划的目标是在管理者与项目之间、 项目组内部达成共识。

·计划编制

作为一个项目实施计划, 必须经过项目经理的深思熟虑: 考虑要周密, 资源利用要合理, WBS分解要细致、 可控。项目计划的编制工具采用当前流行的项目管理软件PROJECT, 在项目计划制订前, 客服事业部结合以往的经验制定出不同产品线( 或项目) 的标准WBS分解表模板。
模板是在先前一系列项目执行过程当中总结出来的较为合理的工作计划和工作量基准, 一般要求每个WBS子项不超过2个工作日, 对于一些小的但高频次出现的工作也必须单列, 如周报、 对用户每周的汇报等。项目经理只需按照标准的WBS分解表制订计划, 其中由于工作量和使用项目资源的不同, 在时间上也存在差别。
而且由于诸多项目之间存在相似性, 采用标准WBS分解表将大大简化项目经理制订计划的工作量, 同时也增强计划的可操作性。项目计划的制订必须按照关键路径法列出项目里程碑, 这样, 在进行计划控制时我们只要重点控制关键路径即可。
项目计划在实施前还必须由项目经理提出由项目执行部组织进行评审, 计划评审合格方可进入现场施工, 并在现场与用户进行确认。评审合格后的项目计划统一纳入配置管理。

·计划实施与监控

对于项目计划的监控, 在某大型通信项目中, 我们要求”三天一回顾, 一周一总结”, 即要求项目经理每三天就要比较项目执行的实际情况与原项目计划, 检查是否偏离了计划, 如有偏差, 则要及时采取措施。每周要求对上周的计划执行情况进行分析总结, 并修正下一步的计划, 相对大的项目除总结分析本周计划进度, 还必须编制双周滚动计划, 并知会全体项目实施成员和项目干系人。

·计划变更

对于项目计划的变更必须有变更流程。我们在操作过程中规定: 对于三天以内的计划变更, 直接由项目经理确定, 但必须在项目计划中标明并通报项目各干系人; 如果是一周以内的计划变更, 则必须由项目执行小组审批; 超过一个星期以上的计划变更必须报项目领导小组审核或会议讨论, 同时采取紧急处理措施。

项目计划是项目执行的一条准绳, 只有合理的计划和定期的监控, 才能保证计划的持续有效性。

5、 项目评审非常有必要

项目评审一是确认准备工作是否充分, 让项目组成员对项目实施内容做到心中有数、 有据可依, 并确定项目绩效系数; 二是确定项目实施结果, 进行总结交流以持续改进项目管理方法, 并评定项目绩效; 三是引入第三方, 加强对项目的监控。
项目评审主要依据项目标准WBS、 项目实施计划、 项目实施管理规范、 项目费用预算、 项目绩效评估办法、 项目输出文档、 项目移交情况( 含项目质检内容) 、 客户满意度调查和项目总结报告等。
项目评审经过第三方在项目开始前对项目目标、 项目范围、 工作分解、 资源使用、 项目组织、 项目制度、 责任界面、 项目文档、 沟通计划、 风险控制、 质量管理、 费用预算、 项目激励等内容进行评审, 评审其科学性、 规范性、 逻辑性和合理性等等; 在项目结束后对项目实施的进度、 费用、 质量、 文档、 客户满意度等方面进行调查、 总结和改进。
项目评审的目的是: 在事前做到对项目实施成本和风险的充分估计; 对项目进度计划合理论证; 积累经验、 逐步提高、 逐步完善项目管理。

6、 项目范围管理不能忽视

在以往的工程施工我们曾有过这样的经历: 很早就听说一些系统要竣工, 却迟迟未能峻工。为什么? 这是因为用户对系统的参与比较深入, 同时也提出诸多需求, 在这些需求中, 有的已超出合同范围, 实际上, 用户方使用部门的人员对当时合同情况不知情, 她们只是从系统的实际应用情况出发, 认为需要增加功能。对于我们的工程人员来说, 事情却越做越多。根源在哪里? 就是我们没有在项目一开始就做好范围管理。范围管理主要包括如下内容:

·项目范围的确认

项目经理根据合同方案及配置的定义整理出合同项目的项目范围, 要求项目范围描述详细到系统各模块的子功能点; 整理出来的项目范围需要开发项目组、 销售项目经理/客户经理共同确认, 并作为初稿纳入项目管理规范的项目范围章节。项目开工时, 必须与用户共同确认项目范围的定义, 在项目范围确认书上签字。

·确认项目范围变更

在项目实施过程中, 项目组每个成员都有义务积极承担确认项目范围变更的角色, 一旦发现范围变更即马上与项目经理进行沟通。项目经理有责任组织讨论并确认变更类型: a)确是范围变更, b)只是范围定义不清晰, c)适应性改进或错误。如果项目组不能达成一致意见, 则把该问题上报项目领导小组解决争议。

对于情况b), 项目经理应向全项目组员阐明。
对于情况c), 则项目组内部先解决排除, 若需其它成员支持按服务流程中的问题单流程处理。
对于情况a), 继续如下步骤。

·评估项目范围变更的影响

所有被确定的范围变更将被分配一个序列号。项目经理有责任写成文档并评估它对项目计划、 资源和成本的影响。

·项目范围变更申请

根据变更的描述、 分析以及对项目的影响评估, 项目经理写出申请报告向双方项目领导小组申请, 以便该变更被批准或拒绝。如果范围变更被拒绝, 项目经理必须在项目会议上向项目干系人通报该信息。

·项目管理相关内容的调整和确认

如果范围变更申请被批准, 项目经理必须修改项目管理相关内容, 包括项目范围、 计划、 资源、 预算等, 并在下一次项目会议中向所有的项目成员宣布所修改的内容。

·项目阶段性范围管理要求

项目范围管理流程开始于项目经理在项目启动会上向项目组成员宣布最初的项目范围。该流程将在每个阶段开始时都由项目经理重复一次。在每个阶段的结束时, 项目经理需再次传达经修改的项目范围, 并特别强调在本阶段修改的内容。对于范围管理不但包含范围的扩充, 也包含项目范围的缩小, 如果出现因客观原因原订合同范围内的内容无法实施等重大变故, 我们必须将相关已实施的内容、 下阶段实施的内容和变更的内容按阶段整理并发布。在项目交付时项目经理必须提交项目范围变更表。

·项目风险管理是必要的

项目一旦启动, 风险就与之并存。项目经理必须具备识别风险的能力, 并力求将风险消灭在发生之前, 对于无法安全回避的风险, 必须事先制定风险补救措施, 将风险的危害程度减少到最小化。
风险的管理一般包括: 风险的识别、 风险的分析、 风险的预防措施、 风险的补救措施、 风险的启动条件等。识别出风险后, 分析风险存在的原因, 造成的危害, 并分析风险存在的可能性及危害程度。对于风险的可能性和危害程度我们一般采用量化的方式, 如将风险的可能性分为三个等级, 3为发生的可能性极大, 2为可能性中等, 1为可能性较小; 危害程度我们也能够分为五个等级, 5为导致项目的彻底失败, 4为项目发生重大目标变化, 3为导致项目严重的质量和进度问题, 2为有一定程度的危害, 1为较小危害。将可能性和危害程度相乘, 得出该风险的权重。
我们主要关注风险权重较大的前几项, 对于不同的阶段, 风险因素是会产生变化的。比如这个阶段重点风险因素是A风险, 当某个阶段过去后, 可能A风险就消失了。因此说不同的阶段风险重点也不一样, 风险因素是一个变化的过程, 每周或每阶段我们都需要对风险因素进行一次回顾, 检查原风险因素是否消失, 新的风险因素是否已产生。对于下一步将遇到的风险, 则应立即采取预防措施。

·项目质量管理

ISO9000标准要求四个字: 说、 做、 记、 审。我们在项目管理中提出: 把要做的事写下来、 按写的内容去做、 把做的过程记下来。按照公司ISO9001质量体系, 我们确定了项目质量计划和质量方针、 目标, 然后定义项目质量、 界定质量范围、 拟订质量控制和保障措施及质量提高和改进措施, 落实质量控制组织, 明确质量标准和依据。具体为:

·项目质量定义

项目质量是指项目实施过程、 项目管理和项目交付物( 项目成果、 项目产品) 以及服务之全部特点及特性, 具有满足明确或隐含需求的能力。

·质量控制与保证措施
设备检测; 预安装测试; 计划和结果评审; 系统联调测试; 系统培训; 工程质检; 客户满意度调查等。

·质量提高与改进措施

预防; 纠正; 返工; 更换设备; 客户抱怨处理; 人员培训或更换。

·质量控制组织

为使项目质量在实施过程得到组织保障, 根据项目组织结构和质量体系要求, 设立项目监督小组, 并明确职责和权限。

7、 工作汇报制度

工作中, 经常会听到同事们的抱怨, 做了这么多, 可还是没有得到销售部门或用户的认可。为什么呢? 因为她们并不知道她们到底做了些什么, 造成一部分项目干系人处于项目信息的真空地带, 因此我们建立了工作汇报制度的规范。在PAS-1000工程中, 每周主要的汇报就是周报, 每个周末之前, 我们会按公司统一的格式撰写周报后提交部门文档管理员, 再由她提交项目执行部进行审核, 签字盖章后发给用户方的相关负责人, 并抄送给销售部门和其它项目干系人, 使所有项目干系人都能及时了解工程进展的相关信息。
工作汇报的内容主要包括: 上周的工作内容、 工作中存在的问题、 需用户配合的事项、 下周的工作计划、 费用开支计算、 风险列表等。

8、 文档的管理

文档管理历来是通信项目管理中比较薄弱的一环, 资料不齐给后期维护带来较大困难, 另一个存在的问题是: 虽然建立了文档, 但在之后的维护中没有即时更新, 造成数据陈旧、 不可用, 也容易给用户留下不规范的印象。
文档要实施规范管理, 必须使项目文档模板化。也就是先制定一个实用的模板文档, 在项目实施的过程中就能够按照统一标准来填写, 这样既可提高文档编制效率, 也能够使文档输出更标准化。
项目管理文档包括四种: 质量体系文件、 技术文件、 项目管理文件以及外来文件。质量体系文件是公司的受控文件, 对工程质量有一定指导作用; 技术文件主要指系统的安装、 使用文档和工程实施中生成的文档; 项目管理文件是项目管理中产生的文件, 如项目计划、 项目会议纪要、 风险管理、 问题管理、 项目工作总结等; 外来文件则指设备厂家提供的资料。
文档的输出必须有计划分阶段输出。每个文档必须在计划中落实到”5W1H”, 这样才具备可控性和可操作性。文档的输出必须具备下列几个条件: 及时性、 准确性、 完整性。要求项目组文档管理员定期对项目组的文档进行检查, 并将项目文档移交及检查审核的结果作为项目绩效评估的一个重要内容。
文档输出须统一纳入配置管理, 并在日后的维护和扩容工作中进行相应更新。

9、 项目的绩效评估

项目绩效评估作为保障项目管理实施的有效手段, 我们以《项目实施计划》、 《项目费用预算》和《项目实施管理规范》为基础, 客观、 公正地评价项目实施的过程与结果。
首先, 项目绩效评估的目的主要是:
1.为项目实施提供导向性管理工具, 或称之为指挥棒;
2.经过总结经验教训, 促进完善项目管理;
3.为项目激励分配和决策提供书面依据。
其次, 就是明确评估实施的内容和方法。项目绩效评估一般是从项目立项开始跟进, 在项目结束后进行。评估的内容主要是: 项目实施的时间进度、 成本费用控制、 质量控制、 客户满意度、 附加项创新能力的”4+1”体系。
总之, 项目绩效评估虽是一种管理手段, 可是, 只有不断的优化项目的管理流程, 吸取更好的项目管理经验和方法, 才能保证项目管理得以优化并持续发展的良性过程。

10、 正确处理与用户之间的关系

要把用户当作真诚的朋友, 而不是单纯的”上帝”。
在项目管理中, 首先我们必须摆正客户与用户之间的关系。有的项目经理对用户百依百顺, 用户要求什么就做什么, 有些意见明明是错误的, 也遵照执行, 出了问题责任就被推到我们身上。这样的例子屡见不鲜。有人认为对用户百依百顺是把用户当作上帝的表现, 其实不然。
在项目中, 我们应该把用户当作一个真诚的合作伙伴和朋友来对待。和用户之间的关系是一种合作的关系、 朋友的关系: 合作, 表示彼此是互赢互利的, 建立在平等的基础上; 朋友, 意指双方真诚友好、 相互尊重、 相互理解。在项目实施过程中, 我们必须强化服务意识, 将用户的满意度作为项目成功的一项重要指标来抓, 以求从质量、 服务、 满意度等各方面真正体现”以客户为中心”的体现。

11、 从项目管理中要效益

IT企业为什么会形成低薪高费用的现状? 根结还在于管理。企业至胜的关键不再是资源、 资金或技术, 而是拥有素质良好、 能快速学习及应变的管理人才。管理的不当造成了现场工作的低效率和诸多浪费。如何从项目管理中要效益?
首先, 我们要考虑项目成本的控制: 现场实施前, 项目经理必须按计划制订项目费用预算; 实施过程中, 必须每周上报每个项目成员的实际费用开支情况; 项目结束后, 根据这些数据统计出项目的总体费用情况和人均费用, 并进行科学分析, 从而得出该项目的盈亏情况及利润额。项目经理着重抓的是合理安排项目计划、 避免人员空耗; 充分调动团队成员的工作积极性和工作效率, 避免低效工作状态; 有效控制项目的工作范围, 避免因项目外的工作量导致项目成本增加; 按计划完成验收, 以确保款项的及时回收。
从以上三方面出发, 达到节约成本、 加快资金回笼的目的, 项目管理就能够出效益了。

12、 项目后评价:

根据行业特点, 电信运营项目后评价是指对企业投资建设项目在投入运营后, 用系统工程的方法, 广泛收集、 调查有关网络运行指标数据、 顾客满意信息、 投资运营财务数据和项目实施过程的各种变化和成因, 对该项目的总体结果、 项目管理等方面进行全面的、 综合的分析和评价, 总结经验教训, 做出后评价报告, 并经过及时有效的信息反馈, 为未来新项目的决策和管理提供参考。由于电信运营项目自身的特点, 使其后评价存在着特有的难点, 兼之当前国内各电信运营企业基本没有这方面的实际经验, 因此还需要做大量细致的工作, 不断总结完善。
当前存在的主要困难:
⑴ 数据处理方法及模型的建立
由于通信网络的建设、 运营具有滚动性, 即无法清晰地区分现有的哪部分用户收入是属于本期工程的, 加上影响市场发展的因素很多, 不能把本期工程投入后企业在用户、 市场占有率、 收入、 利率等方面的变化简单地与本期工程联系挂钩, 而当前相当多电信运营企业尚未建立数据库及较为完善的运营数据分析决策系统, 因此, 如何根据实际情况, 对取得的数据进行科学的处理或能否建立合适的数据处理模型成为一个重点和难点。
⑵市场发展和财务数据预测
由于通信网络项目的生产期较长, 因此, 在进行项目后评价时必须根据当前业务发展和技术更新的实际情况, 对未来若干年的市场发展和财务数据进行修正预测, 包括:
① 根据当前行业技术发展状况, 如是否开始出现替代技术或重大技术升级, 调整评价对象的生产期, 并相应调整设备折旧期等相关数据。
② 按照投入运营后市场发展和业务收入实际情况及其发展趋势, 预测评价对象寿命期内剩余时间的市场发展和财务数据, 并以此为依据调整本项目的市场和财务数据及经济评价。
由于行业发展和市场预测的复杂性, 决定了上述工作成为项目后评价的一大难点。但我们不能因此而在项目生命期结束后进行后评价, 那样就无法对正在不断扩容发展的网络建设提供决策参考, 也就失去了进行项目后评价的实际意义。
⑶ 可行性研究欠完善
由于当前国内电信运营行业的项目可行性研究及设计普遍存在轻市场重方案, 轻效益重技术的倾向, 在市场发展和经济效益分析方面普遍较弱, 很难达到指导实际生产运营的深度, 因此, 也难以为后评价提供科学的参照。另外, 更为严重的是, 有些项目为了达到获得批复及融资的目的, 在做可行性研究时就缺乏实事求是的精神, 数据取定欠科学合理性, 这样的可行性研究或设计根本不能作为项目后评价的依据。
解决方法:
⑴ 完善可行性研究和设计
可行性研究和设计文本是项目后评价的重要依据。根据当前国内实际情况, 电信运营行业设计单位普遍在网络技术方面实力较强, 而在市场需求、 定位分析方面能力不足。因此需要根据当前行业向开放和市场经济转型的实际情况作相应调整。
根据上述情况, 建议在进行可行性研究时, 在市场需求、 定位、 策略分析方面交由市场调研公司完成, 设计单位只负责将其主要数据、 方法、 结论列入可行性研究报告; 对网络建设方案, 可充分发挥设计单位的优势; 对经济效益分析, 可由设计单位在建设单位财务部门的协助下, 根据企业和项目的实际情况, 对评价方法和重要参数取值作出调整后完成。对于项目的初步设计和施工图设计, 由于其重点是对可行性研究中所推荐或选择的建设方案进行细化, 提出具体可操作方案, 因此, 一般可由设计单位独立完成。
⑵ 建立项目后评价管理规范和体系
经过建立项目后评价管理规范和体系, 一方面能够保证项目后评价所需数据的及时采集、 归档, 以确保数据的完整准确性; 另一方面能够保证项目后评价结果能够及时有效地反馈到企业相关职能部门, 以便及时调整相关决策, 积极有效地发挥项目后评价的作用。建立数据处理系统, 不断完善数据处理方法和模型。结合企业数据库及分析决策系统的建设, 建立项目后评价所需要的数据处理系统, 不断修正完善数据处理的方法和模型, 提高数据特别是市场发展和财务数据预测的完整性和准确性, 为项目后评价的有效性提供更好的保障。