【转:http://blog.csdn.net/xiaoyw71/article/details/26966237】
2、项目监督与控制
项目监控是围绕项目实施计划,跟踪进度、成本、质量、资源,掌握各项工作现状,以便进行适当的资源调配和进度调整,确定活动的开始和结束时间,并记录实际的进度情况,在一定情况下进行路径、风险、决策、度量、量化管理等方面的分析。在实施项目的过程中,要随时对项目进行跟踪监控,以使项目按计划规定的进度、技术指标完成,并提供现阶段工作的反馈信息,以利后续阶段的顺利开展和整个项目的完成。使管理者能在项目进展明显偏离项目计划时采取有效措施。
2.1、项目角色职责
项目监督与控制过程中,项目经理、组员及干系人职责如下:
2.1.1、项目经理职责
1.编写《项目工作周报》;
2.组织并参加项目组例会;
3.向部门经理提交《项目工作周报》,并及时报告项目例外情况;
4.在项目的里程碑处组织并参加项目的里程碑处评审;
5.监控项目进展,识别项目偏差,并分析、解决及跟踪偏差处理情况,更新项目计划;
6.识别跟踪风险问题,对风险进行规避,直到风险问题关闭;
7.进行干系人计划跟踪,组织干系人参与里程碑会议和其他讨论会。
2.1.2、项目成员及干系人职责
1.项目组员编写《个人工作周报》,并提交给项目经理;
2.配置管理员提交《配置管理工作周报》;
3.部门经理及副总经理接收《项目工作周报》,了解项目进展;
4.客户代表及其主管领导接收《项目(对外)工作周报》,了解项目进展。
2.2、监控对象及输入/输出
监控对象主要是所有策划阶段所制定的计划,以及实施阶段逐渐展开的开发进度计划、工作与质量、资源、沟通、采购等。
2.2.1、监控输入
项目实施计划
项目进度计划
质量保证计划与跟踪表
配置管理计划与跟踪表
风险管理跟踪表
采购计划
2.2.2、监控输出
项目进度计划(已更新)
个人工作周报
项目工作周报
项目度量数据库
里程碑报告
例会会议纪要
里程碑评审会议纪要
风险管理跟踪表(已更新)
外部干系人管理记录
2.2.3、度量指标
进度偏差率=(计划工期-实际工期)/计划工期
SPI=EV/PV
CPI=EV/AC
完成跟踪和监督活动所花费的工作量和其他资源
2.3、监控中主要活动及实践方法
在项目监控活动中,通常的做法是以自然周和项目里程碑为监控活动周期,以项目任务跟踪管理、项目周例会、项目周报及度量为主要活动,项目周报是各项工作重要载体,是项目监控信息分享与展现。而项目任务跟踪管理活动是监控活动核心管控方法,这样也要求项目进度计划及任务分解是渐进式的。总结下来,活动有:
项目进度计划细化及任务分解;
填写个人周报反馈任务完成情况;
组织并召开项目周例会;
填写项目周报并分享给项目干系人;
定期与项目干系人沟通汇报;
按里程碑组织活动,并通过里程碑会议评审里程碑报告;
处理项目偏差;
更新度量数据库。
2.3.1、项目进度计划细化及任务分解
项目经理在每一阶段结束后细化下个阶段的计划,更新《项目进度计划》。在每次周例会上,根据上次周例会到本次周例会期间工作任务完成情况及项目进度计划,确定下周工作目标,并分配下周工作任务,更新进《项目进度计划》中。
项目经理在项目初期使用Project等工具编制的项目进度计划是设定了里程碑的、比较粗粒度的WBS任务分解,而详细的任务是随着项目进度再进行细化的,没有必要在项目初期把进度计划编制的很细。例如我以前管理项目时,投入较大的精力来编制自己认为比较详细的进度计划,但出现需求、设计、人力资源出现变更时再调整非常耗费人力,看似项目跟踪比较细,实际上脱节越来越严重,而且不实用,这样经历了两个项目后,再也不迷信Project工具了。工具仅仅是工具,必须有一套体系支撑,合理使用各种工具才能做好项目。
工作细化分拆要求:
1)要将项目活动分拆到能满足下一步要实施的估算的对象所需要的粒度。
在项目的早期定义WBS的高层元素,然后在进行详细策划时再定义WBS的低层元素。
拆分从WBS的第一层开始。通常利用所选定的软件生命周期模型确定第一层和第二层,然后逐层确定各层元素,包括开发阶段、过程和产品。
一般不会超过五层,最低层的元素通常在各个阶段详细策划时定义。
2) 定义详细任务(最低层的元素)时,参照“80小时原则”,根据公司实际管理要求,原则上要尽量将所有的项目活动分拆成一个人(会议除外),不承担其他任务可以在一周(40小时)甚至更少的时间完成的任务,每一个任务应产生一个可见的工作产品。
3)任务拆分计划根据经验,两周的任务计划为宜,计划时间过长容易发生变更,产生不必要调整计划管理成本。
任务精细化管理属性:
1)精细化属性有:项目名称、里程碑,任务信息,任务信息包括:任务类型、项目阶段、项目模块、任务名称、任务分组、任务阶段类型、选择人员、计划开始时间、计划结束时间、计划工时、优先级、重要级、任务描述、是否直接分配、任务难度系数等信息;
2)管理属性有:任务实际完成时间、实际完成工作量、工作成果、完成功能点、难度系统等。
关于任务的精细化管理,详见后续的精细化管理内容。
2.3.2、填写个人周报反馈任务完成情况
项目成员(包括:项目经理)每周填写《个人工作周报_姓名》。个人周报的本周任务完成情况各列需填写完整。项目编号、项目名称并要与项目立项时确认的一致。所有任务必须填写任务名称、任务类型、所属阶段、花费小时、是否超期完成。来自《项目进度计划》的所有工作任务都要在个人周报中填写任务编号、任务名称,且必须与《项目进度计划》上的任务编号、任务名称一致。项目成员在例会前将个人周报提交项目经理。
质量保证人员只需要填写《质量保证工作周报》,配置管理人员只需要填写《配置管理工作周报》。
如果没有专业工具管理任务跟踪管理,个人周报的意义不是很大,主要是信息孤立、反馈滞后,形式大于意义,但是,没有也不行。所以,一般都采用专业工具进行任务跟踪管理、问题跟踪管理、
2.3.3、项目周例会
首先需要项目经理提前准备项目周例会内,项目经理根据项目的执行情况,参考《项目工作周报》和《度量数据库》, 从项目的进度、成本(工作量)、需求变更、过程和产品的质量、干系人参与计划跟踪、数据管理、风险及问题几个方面识别项目偏差,并针对偏差进行分析及解决,总结经验教训,细化下一里程碑工作目标及任务。
如果是里程碑会议,则需要编制《里程碑报告》。
并且,在开会前,需要将会议的日程安排通知到参与人员。
按日程安排,项目经理组织项目成员参加周例会,通常讨论如下议题:
1)本周工作进展通报,偏差通报,成员说明偏差原因。分析偏差,并给出解决措施;
2)沟通项目内部的技术问题(不超过0.5小时)。如果会上不能解决,会后单独讨论;
3)项目经理在周例会上,根据本周工作任务完成情况及项目计划,确定下周工作目标,并通过项目管理工具(PMS)分配下周工作任务;
4)跟踪项目风险、问题及采取的解决措施,识别新的风险、问题,并进行分析,制定应对策略;
5)项目级QA汇报上周审计发现的问题及改进建议;
6)项目配置管理员CM汇报配置管理情况,包括配置审计和配置变更情况;
说明:指定项目组成员将会上讨论、沟通的内容包括下周计划、问题、风险的讨论结果形成《例会会议纪要》。
2.3.4、项目周报
在项目周例会后,项目经理对项目成员提交的《个人工作周报》进行审核。并根据例会会议纪要,将任务的完成情况更新到《项目进度计划》中,将风险的识别和跟踪情况更新到《风险管理跟踪表》中。将项目的进度数据、问题、风险的跟踪及处理情况和相关干系人跟踪情况更新到《项目工作周报》中,将外部干系人管理记录中的干系人情况和干系人活动情况记录到《项目周报》中,并将《项目工作周报》提交部门经理和主管副总。
说明1:通常,用户方也需要跟踪项目,需要为用户提供用户化项目周报,公司内部管理上的一些内容不宜体现在用户化周报上,需要项目经理酌情处理。
说明2:《项目工作周报》信息来源于《项目进度计划》、《个人工作周报》、《会议纪要》、《风险管理跟踪表》。
说明3:若项目中有重大的进度调整,项目经理需要及时通知部门经理 。
1)工作完成情况
2)下周工作任务
下周工作任务与上表类似,在此略。
上述下周任务及上周完成情况的数据来源,通常来自专业项目管理工具。
3)在项目周报中进行工作量统计分析
4)通过项目周报跟踪风险与问题
5)项目周报中,集成度量数据
2.3.5、更新度量数据库
项目经理按照《项目实施计划》中的度量分析计划,根据本阶段的执行情况收集项目数据,并更新到《项目度量数据库》中,详细参见“度量分析过程”。
2.3.6、处理项目偏差
偏差处理主要分为识别,分析,解决及跟踪四个步骤:
1)识别:在项目例会、里程碑会议二个触发点,识别项目偏差,由项目经理分别记录在《项目工作周报》、《里程碑报告》中。
2)分析:与相关干系人讨论,找出偏差出现的根本原因并制定纠偏措施,分别记录到《项目工作周报》、《里程碑报告》。
3)解决:执行纠偏措施。如需修改《项目进度计划》,则组内发布,并通知部门经理。如涉及计划变更,则项目计划需重新评审,参见《项目策划过程》。
4)跟踪:项目经理负责跟踪解决措施是否执行且有效及识别新的偏差。
2.3.7、里程碑跟踪管理——召开里程碑评审会
1)准备会议
项目经理根据项目的执行情况,参考《项目工作周报》和《度量数据库》, 从项目的进度、成本(工作量)、需求变更、过程和产品的质量、干系人参与计划跟踪、数据管理、风险及问题几个方面识别项目偏差,并针对偏差进行分析及解决,总结经验教训,细化下一里程碑工作目标及任务,生成《里程碑报告》。
2)召开会议并形成会议纪要
项目经理邀请部门经理、客户经理、项目成员、项目级QA、项目级CM参加里程碑会议。可能的情况下,邀请客户、最终用户参加里程碑会议。
项目经理向部门经理汇报里程碑目标的达成情况和下一里程碑工作目标及任务,部门经理给出该里程碑评审意见和建议。
项目经理与相关干系人一起进行经验教训总结。指定项目组成员将会上讨论、沟通的内容形成《里程碑评审会议纪要》。
3)后续工作
项目经理根据里程碑会议内容和《里程碑评审会议纪要》,更新《里程碑报告》,然后在项目组内发布。
2.3.8、外部干系人管理
定期或需要时与项目组外部干系人召开会议,通报项目变更或问题(风险),并共同解决问题等。
当问题或风险的紧急程度或严重性比较低时,可以通过邮件或电话方式与项目组外部干系人进行沟通。
项目经理将项目组外部干系人的情况,以及与项目组外部干系人沟通的时间、方式、内容和结果记录到《外部干系人管理记录》中。
2.3.9、项目成本及资源监控管理
主要目的是将项目的实际开始控制在预算范围之内。记录下所有的项目开支,与计划中的开支项进行对比,看是否超出原预算,若有较大的赤字,则要找出具体的费用超出项,分析原因,并采取相应的措施。
软件项目的成本主要体现在人工成本上,也就是工作量;包括项目中外包人员,也是通过工作量来体现采购成本。另外,控制差旅等指出都属于监控范围,控制项目预算范围之内。
按项目的概算、预算、年度预算、月度预算,管理各项成本费用。
项目监控的目的是为了能够在项目执行过程中,管理者(包括项目经理和高层经理)能及时了解项目的进展状况;当项目的进展不满足之前制定的计划时,能采取必要的措施来解决问题。
相关推荐
《CMMI5软件过程成熟度模型5级项目管理模板详解》 CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是国际上评价软件企业能力成熟度的重要标准,它为组织提供了提高其软件工程过程能力的框架。...
CMMI5软件过程成熟度模型5级项目管理模板,整套CMMI5管理文档模板资源53套模板 CMMI精粹:集成化过程改进实用导论 CMMI培训PPT资料(1-8全集) 能力成熟度整合模型教程 软件工程文档全套模板等
这一方法的核心是由Watts Humphrey提出的成熟度框架,他引入了“成熟度等级”的概念,并将其应用于软件开发过程中,从而形成了软件过程成熟度框架。 1987年,SEI的Mark Paulk等人在此基础上建立了第一个CMM...
CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是软件开发过程中的一个评估标准,用于衡量组织在软件工程、系统工程、硬件工程、服务工程等方面的能力成熟度。这个标准由美国卡内基梅隆大学...
描述部分指出,文档将介绍几个关键的高成熟度过程域:量化项目管理(QPM)、组织过程性能(OPP)、组织革新与部署(OID)、原因分析与解决方案(CAR)。这些过程域是CMMI模型中针对那些追求高级别成熟度的组织设计的...
【CMMI软件项目管理与实践】 CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是一种评估和改进组织软件开发能力的框架,它为软件开发过程提供了标准化和结构化的模型。CMMI软件项目管理的核心...
**CMMI(Capability Maturity Model Integration,能力成熟度模型集成)**是软件行业内一种广泛认可的过程改进框架,旨在提升组织的软件开发能力和项目管理效率。CMMI涵盖多个领域,包括过程改进、项目管理、需求...
这要求企业根据自身的产品开发经验和管理实践,构建和完善项目管理规章制度,建立全生命周期一站式管理的管理框架,同时配置相应的业务管控工作流和软件过程管理标准。 总的来说,CMMI软件项目管理与实践是针对现代...
CMMI(Capability Maturity Model Integration)是能力成熟度模型集成,是一种用于评估组织在执行软件开发、系统工程、采购和服务等过程中能力成熟度的框架。CMMI4级是其五个级别中的第四级,代表着“量化管理”级别...
《北京用友-CMMI5软件过程管理-管理规范文档》是针对软件开发流程的一套高级别的管理标准,旨在提升软件开发效率、质量和可靠性。CMMI(Capability Maturity Model Integration,能力成熟度模型集成)5级是该模型的...
二级——受管理级,引入了七个关键过程域(PA)以规范化项目管理:项目计划(PP)、项目计划跟踪与控制(PMC)、需求管理(RM)、供应商协议管理(SAM)、度量(MA)、质量管理(QM)和配置管理(CM)。这些过程域...
CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是一种国际认可的过程改进框架,旨在提升软件组织的开发和过程管理能力。本资料包详细阐述了CMMI在软件工程文档和项目管理中的应用,旨在为软件...
作者在CMMI的认证评估和软件过程改进方面拥有丰富的实践经验,因此书中的内容不仅包含了标准的知识体系,还融入了作者的实践体会,以帮助读者更好地理解和应用CMMI。本书既适合软件技术人员自学掌握CMMI的基础知识和...
CMMI最早由美国卡内基梅隆大学的软件工程研究所(SEI)提出和发展,它融合了多种不同领域的最佳实践,包括系统工程、软件工程、集成的产品与过程开发以及供应商管理等。 #### CMMI版本1.1概述 CMMI V1.1是CMMI发展...
CMMI(Capability Maturity Model Integration)是能力成熟度模型的集成,主要用于评估和改进组织在软件开发、系统工程、采购和过程改进等领域的过程能力和成熟度。CMMI-DEV是CMMI针对软件开发领域的特定兴趣模型,...
在CMMI高成熟度的实施中,S曲线可以用来监控项目的实际进展与计划之间的差异,从而帮助项目团队更好地控制风险。 - **逃逸缺陷分析建模**:逃逸缺陷是指在交付给客户之前未能发现的软件错误或缺陷。通过对这些逃逸...
《软件开发规范与CMMI改进在项目管理中的实践》 在软件开发行业中,一套完善的规范和有效的项目管理是确保项目成功的关键因素。本资料"ZL0004整套详细软件开发完整过程规范CMMI改进软件工程文档项目管理必需.zip...
- **Quantitative Project Management (QPM)**:定量项目管理过程域通过使用统计方法来量化项目管理过程中的各种指标,以实现更精准的预测和控制。 #### 三、项目管理过程域详解 - **基本项目管理过程域**:这部分...
CMMI(Capability Maturity Model Integration)是软件开发过程成熟度模型,由美国卡内基梅隆大学软件工程研究所(SEI)开发,旨在提高软件开发过程的效率和质量。CMMI分为五个级别,分别是初始级、受管理级、已定义...