1.项目的定义
项目是一项有待完成的任务，有特定的环境与要求。
项目必须在一定的组织机构内，利用有限的资源（人力、物力、财力等）在规定的时间内完成任务。
项目任务要满足一定性能、质量、数量、技术指标等要求。
2. 项目与日常工作的不同之处有以下几点。
(1)项目具有时限性和唯一性，而日常工作通常有具有连续性和重复性。
(2)项目管理以目标为导向，而日常工作是通过效率和有效性体现的。
(3)项目通常是通过项目经理及其团队工作完成的，而日常工作大多是职能式的线性管理。
(4)项目存在大量的变更管理，而日常工作则基本保持连续性和连贯性。
3.项目的特征
（1）明确的目标（目的性）
（2）项目的独特性
（3）项目的时限性
（4）项目的不确定性
（5）结果的不可逆转性
4、软件项目（快、好、直）
目标渐进性
智力密集性
5、九大知识域
(1)整体管理、主要管理过程包括制定项目章程、制定项目管理计划、项目执行指导与管理、项目工作监控、项目整体变更控制、项目收尾管理。
(2)范围管理、主要管理过程包括范围管理规划、需求收集、范围定义、WBS创建、范围核实和范围控制
(3)时间管理、主要管理过程包括进度管理规划、活动定义、活动排序、活动资源估算、活动历时估算、制定进度计划与进度控制。
(4)成本管理、主要管理过程包括成本管理规划、成本估计、制定预算、成本控制。
(5)质量管理、主要工作包括质量管理规划、质量保证、质量控制。
(6)人力资源管理、主要工作包括人力资源管理规划、团队组建、团队建设和团队管理。
(7)沟通管理、主要工作包括干系人识别、沟通管理规划、沟通管理和沟通控制。
(8)风险管理、主要工作包括制定项目风险管理规划、风险识别、风险分析(定性和定量分析)、风险应对和风险控制。
(9)采购管理、主要工作包括采购管理规划，采购实施、采购控制、采购结束管理。
6、软件生命周期
计划阶段：可行性分析、初步的解决方案、实施计划等
需求分析阶段：初步的系统分析、数据流图等
系统设计阶段:系统的概要设计和详细设计
系统实现阶段：编码和测试
系统维护阶段
7、软件项目管理常见项目分析
缺乏专业的软件项目管理人才、项目规划不充分、管理意识淡薄、沟通意识和态度问题、风险意识问题、项目干系人管理问题、不重视项目经验总结
第二章范围管理
1、项目范围管理需要做以下三个方面的工作：
（1）明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作是不包括在项目范围之内的。
（2）对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说“不”杜绝做额外工作。
（3）防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。
2、项目范围概念
项目范围（project scope），是指产生项目产品所包括的所有工作及产生这些产品所用的过程，包含两个方面：
产品范围（product scope）：是指客户对产品或服务所期望的特征与功能总和，以产品需求作为衡量标准
项目工作范围（work scope）：是指为提供客户所期望特征与功能的产品或服务而必须要完成的工作总和，以项目管理计划（实为其中的范围管理计划）是否完成作为衡量标准。
3、范围说明书包括
（1）产品范围描述（2）产品验收标准（3）可交付成果（4）项目的除外责任，即哪些内容不属于项目范围（5）项目制约因素（6）项目假设条件
4、WBS创建—分解
分解就是把项目可交付成果划分为更小的、更便于管理的组成部分
常见的分解方法：1. 类比法2.自顶向下的分解3.自底向上的归纳4.根据交付物进行分解（软件项目常用）5.根据项目阶段进行分解（软件项目常用）
项目范围变更控制流程图
第三章时间管理
1、活动定义的方法
（1）分解：把项目工作包分解成更小的、更易于管理的组成部分——活动。
（2）滚动式规划：远期工作à粗略（如里程碑水平）；近期工作具体的活动。
（3）专家判断：富有经验并擅长制定详细项目范围说明书、工作分解结构和项目进度计划的项目团队成员或其他专家
2、活动清单
3、三点估算
首先需要估算出进度的3个估算值，然后使用这3种估算值来界定活动历时的近似区间：
最可能时间（TM）：对所需进行的工作和相关时间进行比较现实的估算，所估算的活动历时。
最乐观时间（TO）：基于最好的情况，所估算的活动历时。
最悲观时间（TP）：基于最差的情况，所估算的活动历时。
活动持续时间TE = (TO+4TM+TP)/6，标准差（TP-TO)/6，据此来界定活动历时的近似区间， 例如，3周±2天
4、关键路径法
5、进度审查
（1）趋势分析
（2）关键路径法
（3）挣值管理
采用进度绩效测量指标，如进度偏差（Schedule Variance，SV）和进度绩效指数（Schedual Perfoamance Index，SPI），评价偏离初始进度基准的程度。
第四章成本管理
1、软件项目成本
硬件成本：硬件设备成本、系统软件成本、数据资源购置
软件开发成本：开发人工成本、开发消耗成本
人员培训成本：开发人员培训费用、用户培训费用
项目管理费用：项目组织费用、项目管理费用、项目控制费用
2、成本估算方法
（1）自顶向下的估算
是根据项目管理人员的经验和判断，结合以前相关类似活动的历史数据，管理人员估计出项目整体的成本和子项目的成本，再把估计的成本给低层的管理人员，低层管理人员再对任务和子任务的成本进行估计，最后到最底层。
优点：管理层会综合考虑项目中的资源分配，避免有些任务有过多的预算而另外一些被忽视。
缺点：如果下层人员认为所估算的成本不足以完成任务时，很可能保持沉默，这样会使项目的执行出现困难；很难找到符合的项目例子做参考。
（2）类比估算
这是一种粗略的估算方法
（3）代码行估算
软件项目中，先估算活动的代码行（工作量），再乘以人工费用，可计算得到该活动的成本
（4）参数估算
SLIM模型：
L和td分别表示可交付的源指令数和开发时间（单位为年）；K是整个生命周期内人的工作量（单位为人•年）。c是根据经验数据而确定的技术状态常数，表示开发技术的先进性级别。
COCOMO模型：ED = rSc 和 TD = a(ED)b
3、成本控制方法
（1）挣值管理：
计划价值(Planned Value, PV)：经批准的成本预算，有时被称为绩效测量基准
挣值（Earned Value，EV）：是对已完成工作的测量值，用分配给该工作的预算来表示，是已完成工作的经批准的预算
实际成本（Actual Cost，AC）：在给定时段内，执行某工作而实际发生的成本
挣值管理—四个评价指标
成本偏差：成本偏差（Cost Variance，CV）是在某个给定时点的预算亏空或盈余量，它是测量项目成本绩效的一种指标，等于挣值（EV）减去实际成本（AC）。
公式：CV=EV-AC
成本绩效指数：成本绩效指数（Cost Performance Index，CPI）是测量预算资源的成本效率的一种指标，表示为挣值与实际成本之比。
公式：CPI=EV/AC
进度偏差（Schedule Variance）：在某个给定的时间点上，项目进度提前或落后的情况。
公式：SV=EV-PV
进度绩效指数（Schedule Performance Index）：测量进度效率的一种指标。
公式：SPI=EV/PV
（2）预测
随着项目进展，项目团队可根据项目绩效，对完工成本估算（Cost Estimate at Completion，EAC）进行预测，预测的结果可能与完工成本预算（BAC）存在差异，如果预测的EAC值不在可接受范围内，就是给项目管理团队发出了预警信号。
第一种是认为项目日后的工作将和以前的工作效率相同，未完成的工作的实际成本和未完成工作预算的比例和已完成工作的实际成本和预算的比率相同。
EAC=(AC/EV)×BAC
另外一种是假定未完成的工作的效率和已完成的工作的效率没有什么关系，对未完成的工作，依然使用原理的预算值，那么，对于最终估算成本就是已完成工作的实际成本加上未完成工作的预算成本：
EAC=AC+(BAC-EV)
第三种方法是重新对未完成的工作进行预算工作，这需要一定的工作量。当使用这种方法时，实际上是对计划中的成本预算的否定，认为需要进行重新的预算。
EAC=AC+重新进行的成本预算
第五章质量管理
1、软件质量要素
**正确性：**系统满足规格说明和用户的程度，即在预定环境下能正确地完成预期
功能的程度。健壮性：在硬件发生故障、输人的数据无效或操作错误等意外环境下，系统能够做出适当响应的程度。效率：为了完成预定的功能，系统需要的计算资源的多少。完整性：系统完成用户全部功能要求的程度。**可用性:**用户能否用产品完成他的任务，令人满意的程度。安全性：系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或者拒绝服务的能力。可理解性:理解和使用该系统的难易程度。可维修性:诊断和改正在运行现场发生的错误所需要的概率。**灵活性:**修改或改正在运行的系统需要的工作量的多少。可测试性:软件容易测试的程度。可移植性:把程序从一种硬件配置或软件环境转移到另一种硬件配置或软件环境时，需要的工作量的多少。可重用性:在其他应用中该程序可以被再次使用的程度(或范围)。互运行性:把该系统和另外一个系统结合起来的工作量的多少。
2、质量成本
3、质量保证思想
基本思想:对用户负责——为确立项目的质量能满足规定的质量要求，必须提供相应的证据。
（1）在产品开发的同时进行产品测试——平行测试过程
测试工作提前，可以有效地防止“失之毫厘，谬以千里”的严重后果。
（2）在项目的各个阶段保证质量的稳定性
每隔一段时期，项目组织就应花费相应的时间对当期完成的产品特性进行测试、稳定和集成。
（3）尽可能早地使项目质量测试自动化
利用自动化测试平台不仅可以降低测试成本，而且可以提高测试效率。
自动化测试工具：IBM Rational Quality Manager
（4）确保项目成员和企业文化都重视质量
产品质量是每个人的事情，而不仅是测试人员的事情
4、软件项目常见质量问题
（1）违背软件项目规律
如未经可行性论证；任意修改设计；不经过必要的测试；……
（2）技术方案本身的缺陷
（3）基本部件不合格（选购的软件组件、中间件、硬件设备等）
（4）实施中的管理问题（计划、监控、沟通障碍……）
**
第六章人力资源管理
**
1、职能型组织结构
职能型组织结构是最普遍的项目组织形式，是按职能以及职能的相似性来划分部门而形成的组织结构形式。
优点：各职能主管可以根据项目需要调配人力、物力等资源，可以充分发挥职能部门资源集中的优势。职能部门内部的技术专家在本部门内可以为不同项目同时服务，节约人力，提高了资源利用率。
同一职能内部的专业人员在一起易于交流知识和经验，
项目成员来自各职能部门，不用担心项目结束后的去向，此外，职能部门可以为本部门的专业人员提供一条正常的晋升途径。
缺点：跨部门的交流和沟通也比较困难。
职能部门往往会优先考虑本部门的利益而忽视了项目和客户的利益。
项目经理对项目成员没有完全的权力，成员积极性不高，这将对项目质量和进度都会有很大影响。
不适宜多产品种类和大规模的企业和项目，也不适宜创新性的项目
2、项目型组织结构
优点：项目经理有充分的权力调动项目内外资源。
权力的集中使决策的速度可以加快，整个项目的目标单一，项目组能够对客户的需要作出更快的响应。
每个成员只有一个领导，排除了多重领导的可能.
项目组内部的沟通更加顺畅、快捷。
缺点：由于项目组对资源具有独占的权力，在项目与项目之间的资源共享方面会存在一些问题，与项目外的其他部门之间的沟通比较困难
在相对封闭的项目环境中，容易造成对公司的规章制度执行的不一致
项目成员缺乏归属感，不利于职业生涯的发展
项目型组织结构常见于一些规模大、项目多的组织
3、矩阵型组织结构
优点：以项目为中心，有专职的项目经理负责整个项目。
项目团队共享各个职能部门的资源。
当项目结束后，项目成员可回到原来的职能部门，减少了对项目结 束后的顾虑。
对公司内部和客户的要求都能迅速地做出响应。
平衡了职能经理和项目经理的权力，保证系统总体目标的实现。
缺点：容易引起职能经理和项目经理权力的冲突。
多项目共享资源会导致项目之间的资源竞争冲突。
项目成员受职能经理和项目经理双重领导。
4、团队成员选择标准
可用性：团队成员能否在项目所需时段内为项目工作，在项目期间内是否 存在影响可用性的因素。成本：聘用团队成员所需的成本是否在规定的预算内。
经验：团队成员是否具备项目所需的相关经验。能力：团队成员是否具备项目所需的能力。意识：项目团队成员需要很强的以问题为导向的意识。技能：项目团队成员需要有解决问题和决策的技能。态度：团队成员能否与他人协同工作，以形成有凝聚力的团队。沟通能力：项目团队成员需要有人际交往的技能，项目成员能够有效地沟通与交流，能够克服个人之间常常出现的问题与矛盾。
5、塔克曼阶梯理论
（1）形成阶段
在本阶段，团队成员相互认识，并了解项目情况及他们在项目中的正式角色与职责。团队成员倾向于相互独立，不一定开诚布开诚布公。有疑问和焦虑的情绪。为减轻人们的焦虑，项目经理领导风格应该是指导型的，让团队成员着手参与一些具体工作，如制订项目计划
（2）震荡阶段
在本阶段，团队开始从事项目工作，制定技术决策和讨论项目管理方法。
这是项目经理创造一个充满理解和支持的工作环境的好时机，要允许成员表达他们所关注的问题，项目经理要致力于解决矛盾.在这个阶段，项目经理的领导风格应该是影响型的。
（3）规范阶段
在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员开始相互信任。在本阶段，项目经理应尽量减少指导性工作，经常对项目团队所取得的进步给予公开的表扬，培育团队文化，注重培养成员对团队的认同感、归属感、努力营造出相互协作、相互帮助、相互关爱、勇于奉献的精神氛围。在这个阶段，项目经理的领导风格应该是参与型的。
（4）成熟阶段
进入这一阶段后，团队就像一个组织有序的单位那样工作。团队成员之间相互依靠，平稳高效地解决问题。项目团队能开放、坦诚、及时地进行沟通。在本阶段，项目经理应完全授权，赋予团队成员权力。在这个阶段，项目经理的领导风格应该是授权型的。
（5）解散阶段
在解散阶段，团队完成所有工作，团队成员离开项目。 团队成员动机水平下降，关于团队未来的不确定性开始回升。项目领导： 为了形成新的发展阶段，有必要介绍关于新项目的好点子。 分离型领导。
6、马洛斯的需求层次理论
生理需要：维持人类自身生命的最基本需要，如吃、穿、住、行、睡等;
安全需要：如就业工作、医疗、保险、社会保障等;
社会需要：人们希望得到友情，被他人接受，成为群体的一分子;
尊重需要：个人自尊心，受他人尊敬及成就得到承认，对名誉、地位的追
求等;
自我实现需要：人类最高层次的需要，追求理想、自我价值、使命感，创造
性和独立精神等。
**
第七章沟通管理
**
- 干系人分析
干系人分析是系统地收集和分析各种定量与定性信息，以便确定在整个项目中应该考虑哪些人的利益。 - 沟通需求分析（明确4点）
（1）需要给哪些干系人发信息；WHO
（2）谁需要什么样的信息；WHAT
（3）谁什么时候需要何种信息；WHEN
（4）如何将信息发送给不同的干系人。HOW - 沟通方式
可以使用多种沟通方式在项目干系人之间共享信息，主要有：
（1）交互式沟通，如会议、电话，即时通讯等；
（2）推式沟通，如新闻、公告等；
（3）拉式沟通，如，企业内网、电子在线资源、经验教训数据库等 - 沟通技术
沟通技术是指在沟通过程中使用的具体手段和工具，如谈话、会议、书面文件、在线资料查询等。
（1）会议沟通：成本较高，沟通的时间一般比较长，因此常用于解决较重大、较复杂的问题。几种适用场景举例，见教材，7.2.4.1节
（2）Email沟通：成本低，方便快捷，小范围沟通，有时间思考斟酌，等；
（3）口头沟通：是一种自然、亲近的沟通技术。加深彼此之间的友谊、加速问题的解决。几种应用场景：办公距离近；存有误会，采用Email无效等
（4）电话沟通：成本较低，距离远无法当面沟通，问题相对简单，采用Email无效等情况下适用。
（5）即时通讯：QQ/MSN/微信（群），快捷，方便，可以群讨论，但是闲聊可能会影响工作。
5、沟通障碍
主观障碍：个人的性格、气质、态度、情绪、见解等的差别，使信息在沟通过程中受个人素质、心理因素的制约。知觉选择偏差所造成的障碍。人们总是习惯接收部分信息，而摒弃另一部分信息（对自己不利的），这就是知觉的选择性。
经理人员和下级之间相互不信任。沟通者的畏惧感及个人心理品质也会造成沟通障碍。人们一般愿意与地位较高的人沟通。
客观障碍：信息的发送者和接收者如果在空间上距离太远、接触机会少，就会造成沟通障碍。社会文化背景不同，种族不同而形成的社会距离也会影响信息沟通。信息传递层次越多，它到达目的地的时间越长，信息失真率则越大，越不利于沟通。另外，组织机构庞大，层次太多，也会影响信息沟通的及时性和真实性。
沟通方式障碍：语言系统所造成的障碍。例如，措辞不当，丢字少句，空话连篇，文字松散，使用方言等，这些都会增加沟通双方的心理负担，影响沟通的进行。
沟通方式选择不当，原则、方法使用过于死板所造成的障碍。
6、冲突
7、沟通的艺术
（1）以诚相待（2）民主作风（能虚心倾听干系人的意见，积极创造畅所欲言的气氛）（3）保持平等地位（避免居高临下，以教训人的口气）（4）学会聆听（要耐心地听对方讲话，不要随便插话和打断对方讲话）（5）以讨论和商量的方式进行双向沟通（6）要了解项目组成员（如性格、心理状态等）
第八章风险管理
1.需求风险（软件项目最大的风险是所完成的产品不能让用户满意）
识别需求风险时，重点分析以下因素：
用户是否充分参与需求分析。优先需求是否得到满足。需求变化的程度。
有无有效的需求变化管理过程。
2、风险定性分析
风险定性分析是评估并综合分析风险的概率和影响，对风险进行优先排序，从而为后续分析或行动提供基础的过程。风险定性分析
3、风险定量分析
风险定量分析的对象是在定性风险分析过程中被确定为潜在重大影响的风险，其过程就是分析这些风险对项目目标的影响，主要用来产生量化风险信息，来支持决策制定，降低项目的不确定性
4、消极风险的应对（威胁）
规避（如，更改项目管理计划，以完全消除威胁。）
转移（风险转移是指项目团队把威胁造成的影响连同应对责任一起转移给第三方。转移并不是把风险推给后续的项目，也不是未经他人知晓或同意就把风险推给他人。采用风险转移策略，几乎总是需要向风险承担者支付风险费用。）
减轻（把不利风险的概率和影响降低到可接受的临界值范围内）
接受（该策略可以是被动或主动的。被动地接受风险的情况下，可待风险发生时再由项目团队处理，不过，需要定期复查，以确保威胁没有太大的变化；最常见的主动接受策略是建立应急储备，安排一定的时间、资金或资源来应对风险。）
5、风险控制
（1）建立项目风险事件控制体制（2）确定要控制的具体项目风险（3）确定项目风险的控制责任（4）确定项目风险控制的行动时间（5）制订各具体项目风险的控制方案（6）实施具体项目风险控制方案（7）跟踪具体项目风险的控制结果（8）判断项目风险是否已经消除
第九章采购管理
1.招标与投标
通过招标与投标方式来确定开发方或软件、硬件提供商是大型软件项目普遍采用的一种形式。招标投标的主要过程有：
（1）编写招标书。招标书主要分为三大部分：程序条款、技术条款、商务条款。主要内容：招标公告（邀请函）、投标人须知、招标项目的技术要求及附件;投标书格式、投标保证文件、合同条件（合同的一般条款及特殊条款）、设计规范与标准、投标企业资格文件和合同格式等。
（2）发布招标公告。
招标之前就有很多软件供应商和咨询公司先后与组织取得联系并进行过交流与沟通，需正式对这些公司发出邀请。可以在大众出版物（如报纸）或专业出版物上刊登广告，也可以选择专业的网站来发布消息，扩充现有的潜在卖方名单。
（3）投标人会议。
又称承包商会议、供货商会议或投标前会议。就是在投标书或建议书提交之前，在买方和所有潜在卖方之间召开的会议。会议的目的是保证所有潜在卖方对采购要求都有清楚且一致的理解，给与投标单位提出疑问的机会，保证没有任何投标人会得到特别优待。公平竞争的体现。
（4）投标书格式
（5）开标。
在投标人会议后，将有一个阶段准备投标资料。在招标书规定的时间内提交投标资料后，要经过开标的过程。开标需要在公共场合下，将各家密封的标书打开，并将各家的报价公开。价格是软件项目采购中极为重要的因素。
（6）采购谈判。
采购谈判是指在合同签署之前，对合同的结构、要求及其他条款加以澄清，以取得一致意见。谈判的内容应包括责任、进行变更的权限、适用的条款和法律、技术和商务管理方法、所有权、合同融资、技术解决方案、总体进度计划、付款和价格等。
2．合同管理
一旦卖方选定，接下来就应该签订采购合同。采购合同中包括条款和条件，也可包括其他条目，如买方就卖方应实施的工作或应交付的产品所做的规定。 签订软件项目采购合同时应注意：
（1）规定项目实施的有效范围。经验表明，软件项目合同范围定义不当而导致管理失控是项目成本超支、时间延迟及质量低劣的主要原因。
（2）合同的付款方式。对于软件项目的合同而言，很少有一次性付清合同款的做法。付款条件是一个比较敏感的问题，签订合同时在付款条件上规定得越详细、越清楚越好。
（3）合同变更索赔带来的风险。在软件的设计与开发过程中，存在着很多不确定因素，因此，变更和索赔通常是合同执行过程中必然要发生的事情。
（4）系统验收的方式。从严格意义上说，成果一经客户认可，便不再有返工之说，只有索赔或变更之理。因此，客户必须高度重视系统验收这道手续。
（5）维护期问题。系统最终验收通过之后，一般都有一个较长的系统维护期，这期间客户通常保留着5%～10%的合同费用。
第十章整体管理
1.项目章程的主要作用是：
(1)正式宣布项目的存在，对项目的开始实施赋予合法地位。
(2)粗略地规定项目的范围，这也是项目范围管理后续工作的重要依据。
(3)正式任命项目经理，授权其使用组织的资源开展项目活动。
2.整体变更的控制
整体变更控制是审查所有变更请求，批准变更，管理变更，并对变更处理结果进行沟通的过程。该过程审查所有针对项目文件、可交付成果、基准或项目管理计划的变更请求，并批准或否决这些变更。
项目的任何干系人都可以提出变更请求。尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并由变更控制系统过程进行处理。
变更控制委员会（Change Control Board，CCB），负责审查、评价、批准、推迟或否决项目变更。
3.项目结束
项目结束有两种情况：正常结束和非正常结束。
（1）项目成功与失败的标准
评定项目成功与失败的标准主要有3个：是否有可交付的合格成果；是否实现了项目目标；是否达到项目客户的期望。
（2）项目结束条件
当出现下列条件之一时可以结束项目。
项目计划中确定的可交付成果已经出现，项目的目标已经成功实现。
由于各种原因导致项目无限期拖长。
项目出现了环境的变化，对项目的未来形成负面影响。
项目所有者的战略发生了变化，项目与项目所有者组织不再有战略的一致性。
项目已不具备实用价值，难以同其他更领先的项目竞争，难以生存。
4.项目评价
项目后评价（Post Project Evaluation）是指在项目已经完成并运行一段时间后，对项目的目的、执行过程、效益、作用和影响进行系统的、客观的分析和总结。
（1）项目后评价的意义
查找项目成败的原因，总结经验教训，提高未来新项目的管理水平和投资效益等。
（2）项目后评价的方法
影响评价法。项目建成后测定和调研在各阶段所产生的影响和效果，以判断决策目标是否正确。
效益评价法。把项目产生的实际效果或项目的产出，与项目的计划成本或项目投入相比较，进行盈利性分析。
过程评价法。把项目从立项决策、设计、采购直至建设实施各程序的实际进程与原定计划、目标相比较，分析项目效果好坏的原因。
系统评价方法。将上面3种评价方法有机地结合起来，进行综合评价，才能取得最佳评价结果。
（3）项目后评价的程序
接受后评价任务。
成立后评价小组，制订评价计划。
设计调查方案，聘请有关专家。
阅读文件，收集资料。
开展调查，了解情况。
分析资料、形成报告。
提交后评价报告、反馈信息。
