【高项】项目整体管理、范围管理与进度管理(十大管理)

【高项】项目整体管理与范围管理

在这里插入图片描述

1、项目整体管理

1.1 整体管理的过程

整体管理的过程、输入、输出、工具和技术汇总表:

  • 项目整体管理是对项目管理过程组中的不同过程和活动进行识别、定义、整合、统一和协调的过程。整体管理负责管理项目的需求、范围、进度、成本、质量、人力资源、沟通、风险和采购;即(狗(沟通)子(质量)整(整体)范(范围)进(进度),成(成本)人(人力资源、干系人)风(风险)采(采购)。
  • 主要有以下6 个过程: (掌握)
    (1) 制定项目章程:编写一份正式文件的过程,这份文件就是项目章程。通过发布项目窜程,正式地批准项目并授权项目经理在项目活动中使用组织资源。
    (2) 制订目管理计划:定义、准备和协调所有子计划,并把它们整合为一份综合项目管理计划的过程。项H 管理计划包括经过整合的项目埜准和子计划。
    (3) 指导与管理项目工作:为实现项H 目标而领导和执行项H 管理计划中所确定的工作,并实施已批准变更的过程。
    (4) 监控项目工作:跟踪、审查和报告项目进展,以实现项目管理计划中确定的绩效目标的过程。
    (5) 实施整体变更控制:审查所有变更请求,批准变更管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。
    (6) 结束项目或阶段:完成所有项目管理过程组的所有活动,以正式结束项H 或阶段的过程。
    在这里插入图片描述在这里插入图片描述

1.2 制定项目章程(启动)

什么是项目章程?

  • l 、项H 章程是正式批准项目的文件。
    由项目章程要授权项目经理在项目活动中动用组织的资源,所以,项目经理任何时候都应在规划开始之前被委派,最好是在制定项目章程之时。
  • 2 、项H 章程是由项目实施组织外部签发的,项目签发章程之后,就建立了项目与组织日常工作之间的联系。(掌握)千万记住不是项目经理发布的
  • 3 、项目章程的内容:
    @项目目的或批准项目的原因
    @可测量的项H 目标和相关的成功标准
    @项目的总体要求
    @概括性的项目描述
    @项目的主要风险
    @总体里程碑进度计划
    @总体题簦
    @项目审批要苤
    @委派的项目经理及其职责和职权。
    @徇发起人或其他批准项目章程的人员的姓名和职权。

如何制定项目章程?

  • 制定项目章程是制定一份正式批准项目或阶段的文件项目章程的批准,标志着项目的正式启动。在项目中,应尽早确认并任命项目经理,由于项目章程将授权项目经理在项目活动中使用组织资源,项目经理应该参与制定项目章程。

  • 项目章程由项目以外的人员批准,如发起人、项目管理办公室或项目组合指导委员会。
    项目启动者或发起人应该具有一定的职权,能为项目提供资金。他们亲自编制项目章程,或授权项目经理代为编制。项目章程经启动者签字,即标志着项目获得批准。通过编制项目章程,就可以把项目与组织的战略及日常运营工作联系起来

  • 工作说明书是对应项目提供的产品或服务的文字说明。
    对项H 发起人或赞助人根据业务需求、产品或服务要求提供一份工作说明书。对千处工作说明书属千顾客招标文件的一部分,如建议邀请书、信息请求、招标邀请书或合同中的一部分。
    工作说明书指内容: @业务需求、@产品范围说明书、@战略计划

  • 事业环境因素:【注意和组织过程资产的区分,也叫企业环境因素,是项目经理不可控的,不可裁剪的。一般来源组织外部】
    ( 1 ) 组织或公司的文化与组成结构。
    ( 2 ) 政府或行业标准( 如管理部门的规章制度、产品标准、质量标准与工艺标准)。
    ( 3 ) 基础设施( 如现有的软件与硬件基础设施)。
    ( 4 ) 现有的人力资源( 如技能、专业与知识;例如设计、开发、法律、合同发包与采购)。
    ( 5 ) 人事管理( 如雇用与解雇指导方针、员工业绩评价与培训记录)。
    ( 6 ) 公司工作核准制度。
    ( 7 ) 市场情况。
    ( 8 ) 项目干系人风险承受力。
    ( 9 ) 商业数据库( 如标准的成本估算数据、行业风险研究信息与风险数据库)。
    ( 10 ) 项目管理信息系统

  • 组织过程资产:
    ( 1 ) 过程和程序: 叩组织的标准过枉; @标准指导方针、模板、工作指南; @用千满足项目特定需要的标准过程的修正指南; @组织的沟通要求,汇报制度; @项目收尾指南或要求;@财务控制程序; @ 问题和缺陷管理程序; @变更控制程序; @风险控制程序; 圃批准与发布工作授权程序;
    ( 2 ) 组织的全部知识: $项目档案; @过程测量数据库; @经验学习系统; @ 问题和缺陷管理数据库; @配置管理知识库; @财务数据库。

  • 事业环境因素和组织过程资产区分
    @凡是可裁剪的、可选择的均为组织过程资产;凡是不可选择的、只能适应的均为事业环境因素
    @凡是带系统的一般均为事业环境因素(比如:工作授权系统、项目管理信息系统)
    @凡是带程序的一般均为组织过程资产(比如:财务控制程序、变更控制程序、风险控制程序)

  • 财务方面
    三个主要的项目财务价值评价方法包括净现值分析、投资收益和投资回收率分近。—3 个方法的计算必须掌握。
    ( 1 ) 净现值分析(18 上57)
    ( 2 ) 投资收益率分析: ROI 是将净收入除以投资额的所得值。ROI 越大越好。ROI= (总的折现收益-总的折现成本) /折现成本(18 下31)
    ( 3 ) 投资回收期分析-静态和动态投资回收期必须会计算

  • 项目启动会议
    一殷由项目经理负责组织和召开,召开项目启动会议的主要目的在使项目的主要利益相关者明确项目的目标、范围、需求、背景及各自的职责与权限

  • 一殷来说,目标必须要量化,是可度量的。项目H 标具有如下特性:
    叩项目的目标有不同的优先级; @项目目标具有层次性(掌握)注意和项目特点的区别。
    在制定一些目标来衡量项目管理的优劣或效率时,或者将其作为激励项目班子成员的手段, 一定要注意以下几点:
    ( 1 ) 将成果目标和约束目标区分开来。
    ( 2 ) 将目的和手段区别开来。
    ( 3 ) 不制定无法量化或无法实现的H 标。
    ( 4 ) 不转移项目管理人员的努力方向。

  • 引导技术:头脑风暴、冲突处理、问题解决和会议管理等,都是引导者可以用来帮助团队和个人完成项目活动的关键技术。

1.3 制订项目管理计划(规划)

项目管理计划是什么?

  • 项目管理计划一般包括:
    项目范围管理计划、进度管理计划、成本管理计划、质量管理计划、过程改进计划、人员配备管理计划、沟通管理计划、风险管理计划、采购管理计划等分计划。项目管理计划详略均可,可由一个或多个部分计划,以及其他事项组成 。每一个分计划和其他组成部分的详细程度都要满足具体项目的需要
  • 其他组成部分可以包括这些内容:里程碑清单、资源日历、进度基准、成本基准、质量基准、风险登记册等。(掌握)
  • 项目管理计划记录了计划过程组的各个计划子过程的全部成果
    @每一选定过程的实施水平。
    @对实施这些过程时使用的工具与技术所做的说明。
    @在管理具体项目中使用选定过程的方式和方法,包括过程之间的依赖关系和相互作用,以及重要的依据和成果。
    @为了实现项H 目标所执行工作的方式、方过;
    @监控变更的方式、方法。
    @实施配置管理的方式、方法。
    @使用实施效果测量基准并使之保持完整的方式、方法。
    @项目干系人之间的沟通需要与技术。圆选定的项目生命期和多阶段项目的项目阶段。
    @高层管理人员为了加快解决未解决的问题和处理未做出的决策,对内容、范围和时间安排的关键审查。
  • 目管理计划与文件得区别,计划包括得内容是13+3 个子计划
    在这里插入图片描述

如何制定项目管理计划?

  • 初次制订项H 管理计划时,山千各方面的信息还不十分明朗,因此项目经理只盄要从宏观上把握住项目的主体管理思路,切记使项目管理计划通过整体变更控制过程得以更新与修改。
  • 补充原则:各干系人的参与(全员参与);逐步精确(迭代)
  • 变更控制系统是正式形成文件的过程的全体,用千确定控制,改变和批准项目可交付成
    果和文件的方式、方法
    。变更控制系统是配置管理系统的一个子系统。

1.4 指导与管理项目执行(执行)

l 、批准的变更请求可能是纠正措施、预防措施或缺陷补救。包括:

  • ♦ ©纠正措施:使项目实施的预期结果始终符合项目管理计划的要求(是针对实际已经出现
    的偏差);
  • ♦ @预防措施:降低潜在的消极后果发生的可能性(针对将来可能出现的偏差);
  • ♦ @缺陷补救:纠正质量过程发现的产品缺陷(产品或产品组件,缺陷补救措施只针对项目
    质量问题)。

2 、项目经理的权力包括3 个方面 :权限、感化影响和知情力

  • ( 1 ) 权限是项目经理因其在组织中的地位而拥有的。权限为他人认可的程度有限,对他
    人行为的影响一般也不大。
  • ( 2 ) 感化影响力是建立在个人知识、经验、人格和魅力基础上的,项目经理可以利用这
    类权力影响不直接参与项目但却盂要与其合作的人。
  • ( 3 ) 知情力更为重要。“没有调查,就没有发言权“,全面、及时而又准确地掌握项H 各
    方面的情况( 或称信息) ,是判断、决策和指导项目工作的基础。I

1.5 监控项目工作与实施整体变更控制(监控)

实施整体变更控制

  • l 、整体变更控制过程贯穿千项目的始终。山千项目很少会准确地按照项目管理计划进行,因而变更控制必不可少。(掌握)
  • 许多时候,整体变更控制过程包括一个负责批准或否决变更请求的变更控制委员会。变更请求由项目经理审查、评价, CCB 批准或否决。
  • 2 、配置管理活动有:@配置识别; @配置状态记录; @配置核实与审计

1.6 结束项目或阶段(结束)

  • l 、结束项目或阶段是完结所有项目管理过程组的所有活动, 以正式结束项目或阶段的过
    程。本过程的主要作用是:总结经验教训,正式结束项目工作,为开展新工作而释放组织资源。
  • 2 、在结束项目时,项目经理需要审查以前各阶段的收尾信息,确保所有项H 工作都已完成,确保项目目标已经实现。如果项目在完工前就提前终止,结束项目或阶段过程还需要制订程序,来调查和记录提前终止的原因。为了实现上述目的,项目经理应该邀请所有合适的干系人参与本过程。( 掌握)

项目收尾的内容:管理收尾、合同收尾

  • (1) 管理收尾:做好文档归类,对外宣称项目已经结束,可以转入维护期了,同时总结经
    验教训。(2) 合同收尾:正式验收、产品验收,按照合同约定,项目组和业主进行核对,检查是否完成了合同的所有要求,是否可以把项目结束;
  • 验收阶段工作内容:验收测试、系统试运行、系统文档验收以及项目终验:对千系统
  • 于5 系统集成项目,所涉及的文档应该包括:
    ①系统集成项目介绍、②系统集成项目最终报告、③信息系统说明手册、④信息系统维护手册、⑤软硬件产品说明书、质量保证书

2、项目范围管理

2.1 什么是范围管理?

  • 对项目范围的管理,是通过6 个管理过程来实现的:
    (1) 规划范围管理:对如何定义、确认和控制项目范围的过程进行描述。
    (2) 收集需求:为实现项H 目标,明确并记录项目干系人的相关需求的过程。
    (3) 定义范围:详细描述产品范围和项目范围,编制项目范围说明书,作为以后项目决策的基础。
    (4) 创建WBS: 把整个项H 工作分解为较小的、易千管理的组成部分,形成一个自上而下的分解结构。
    (5) 确认范围:正式验收已完成的可交付成果。
    (6) 范围控制:监督项目和产品的范围状态、管理范围基准变更。
    在这里插入图片描述
    在这里插入图片描述

项目范围管理的概念

  • 1、项目范围管理需要做以下三个方面的工作:
    1明确项目边界、2对项执行工作进行监控、3防止项目范围发生蔓延。
  • 2、产品范围与项目范围:
    (1)产品范围是指产品或者服务所应该包含的功能,项目范围是指为了能够交付产品,项目所必须做的工作。
    (2)产品范围是项目范围的基础,产品范围的定义是产品要求的描述,而项目范围的定义是产生项目管理计划的基础,两种范围在应用上有区别。
    3)项目的范围基准是经过批准的项目范围说明书、WBS 和 WBS 典。判断项目范围是否完成,要以范围基准来衡量。而产品范围是否完成,则根据产品是否满足了产品描述来判断
    (4)产品范围描述是项目范围说明书的重要组成部分,因此,产品范围变更后,首先受到影响的是项目的范围

2.2 如何进行项目范围管理?(规划)

1、规划范围管理

  • l 、编制范围管理计划书面描述将如何定义、确认和控制项目范围的过程,在整个项目中对如何管理范围提供指南和方向。范围管理计划需要项目管理团队全员参与。(掌握)

  • 2 、范围管理计划的内容:叩如何制订项目范围说明书
    @如何根据范围说明书创建WBS 。
    @如何维护和批准WBS 。
    @如何确认和正式验收已完成的项H 可交付成果。
    @如何处理项目范围说明书的变更,该工作与实施整体变更控制过程直接相联。

  • 例如,对WBS 的编制指南可能有( 但不限千) 如下内容:
    ( 1 ) 确定WBS 满足职能和项目的要求,包括重置和非重置成本。
    ( 2 ) 检查WBS 是否为所有的项H 工作提供了逻辑细分。
    ( 3 ) 保证每一个特定层的总成本等千下一个层次构成要素的成本和。
    ( 4 ) 从全面适应和连续角度来检查WBS 。
    ( 5 ) 所有的工作职责需分配到个人或组织单元。

  • 3 、范围管理计划描述如何管理项目范围,项H 范围怎样变化才能与项目要求相一致等问题,所以它也应该对怎样变化、变化频率如何,以及变化了多少等项目范围预期的稳定性进行评估。范围管理计划也应该包括对变化范围怎样确定,变化应归为哪一类等问题的清楚描述。

  • 项目范围管理计划可能在项目管理计划之中,也可能作为单独的一项。根据不同的项目,可以是迕细的或者概括的,可以是正式的或者非正式的。。
    如果没有范围管理计划,那么在面对范围管理出现的问题,例如,需求的变化、设计中的错误等“意外“情况时,项目团队就缺乏一个行动指导方针。范围管理计划是项目范围管理的指南。

  • 4 、需求管理贯穿千整个过程,它的最基本的任务就是明确需求,并使项目团队和用户达成共识,即建立需求基线。另外,还要建立需求跟踪能力联系链,确保所有用户需求都被正确地应用,并且在需求发生变更时,能够完全地控制其影响范围,始终保持产品与需求的一致性。(掌握)
    5 、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求
    6 、需求管理计划的内容:
    如何规划、跟踪和汇报各种盂求活动、@ 需求管理需要使用的资源、@培训计划、@项H 千系人参与需求管理的策略、@判断项目范围与需求不一致的准则和纠正规程、@ 需求跟踪结构、@配置管理活动(掌握)

  • 7 、只有明确的(可测量和可测试的)、可跟踪的、完整韵、相互协调的,且主要干系人愿意认可的需求,才能作为基准、

2、收集需求

  • 需求包括
    .•@业务需求:整个组织的高层级需要。
    .• @干系人需求:是指干系人或干系人群体的需要。 @解决方案需求
    • @过渡需求:从当前状态过渡到将来状态所盂的临时能力,如,数据转换和培训需求。
    • @项目需求:项目盂要满足的行动、过程或其他条件。
    • @质量需求:用千确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD 对质量盂求进行了细分,分为基本需求、期望需求和意外需求。

  • 2、收集需求的工具与技术主要有:
    访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分
    ♦ @访谈:通过与干系人直接交谈来获取信息的正式或非正式的方法,是最基本的一种收集盂求的手段
    ♦ @焦点小组:将预先选定的干系人和主题专家集中在一起,了解他们对所提议产品、服务或成果的期望和态度。山一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。是一种群体访谈而非一对一访谈,可以有6-10 个被访谈者参加。针对访谈者提出的问题,被访谈者之间开展庄动式讨论,以求得到更有价值的意见。
    ♦ @ 引导式研讨会:对产品盂求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调千系人差异的重要技术。由千群体互动的特点,被有效引导的研讨会有助千建立信任、促进关系、改善沟通,从而有利千参加者达成一致意见。
    ♦ @群体创新技术:指可以组织一些群体活动来识别项目和产品需求,包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。(20 下30)
    • 头脑风暴法:各抒己见、集思广益
    • 名义小组技术:通过投票来排列最有用的创意,以便进行进一步的头脑风暴或优先排序。是头脑风暴法的深化应用,是更加结构化的头脑风暴法; ( 19 下30) ( 21 下30)
    • 德尔菲技术:采用匿名或背靠背的方式、预测过程几轮反馈,使专家的意见逐渐趋同、有助于减轻数据的偏倚,防止任何个人对结果产生不恰当的影响。
    • 思维导图又称为心智图:是将从头脑风暴中获得的创意,用一张简单的图联系起来,以反映这些创意之间的共性与差异,从而引导出新的创意。
    • 亲和图又称为KJ 法:是针对某一问题,充分收集各种经验、知识、想法和意见等语言、文字资料,通过图解方式进行汇总,并按其相互亲和性归纳整理这些资料,使问题明确起来,求得统一认识,以利千解决的一种方法。
    • 多标准决策分析:是借助决策矩阵,用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准,从而对众多方案进行评估和排序的一种技术。
    ♦ @群体决策:为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求,以及对产品需求进行归类和优先排序。达成群体决策的方法有:@—致同意、@大多数原则、@相对多数原则、@独裁
    — @)一致同意:所有人都同意某个行动方案。
    — @)大多数原则:获得群体中50%以上的人的支持,就能做出决策。
    — 恒)相对多数原则:根据群体中相对多数者的意见做出决定,即便未能获得一部分人的
    支持。通常在候选项超过两个时使用该原则,例如,某个软件构件的功能有3 种实现
    方案(标记为A、B 、C) 在群体决策时,同意A 方案的人有40% ,同意B 方案的人
    有35% ,同意C 方案的人有25% ,则最终确定采用A 方案。
    — @)独裁:由某一个人( 例如,项目经理) 为群体做出决策。
    ♦ @标杆对照:将实际或计划的做法与其他类似组织的做法( 例如,流程、操作过程等) 进
    行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据。

  • 收集需求过程的输出有需求文件和需求跟踪矩阵
    需求文件描述各种单一的盂求将如何满足与项目相关的业务需求。需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。
    需求文件的内容包括: _业务需求、@于系人需求、@解决方案需求、@项目需求、@过度需求、@与需求有关的假设条件、依赖关系和制约因素

  • 需求管理
    包括在产品开发过程中维持需求一致性和精确性的所有活动,包括控制需求基线,保持项H 计划与需求一致,控制单个需求和需求文档的版本情况,管理需求和联系链之间的联系,或管理单个需求和项目其他可交付物之间的依赖关系,跟踪基线中需求的状态。

  • 可跟踪性是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪。
    每个配置项的盂求到其涉及的产品( 或构件) 需求都要具有双向可跟踪性。所谓双向跟踪,包括正向跟踪和反向跟踪:
    正向跟踪是指检查需求1 中、每个需求曰否都铲在后”工作产节( 果)中找到对应、(以免需求被做漏、做偏)
    反向跟踪也称为逆向跟踪,是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。(查需求源头,了解为什么要做这个需求,来源背景和原因是什么)

  • 具体来说,需求跟踪涉及五种类型,如图,箭头表示需求跟踪能力联系链,它能跟踪需求使用的整个周期,即从需求建议到交付的全过程。(掌握)
    在这里插入图片描述

  • 需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪(能力)矩阵,需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
    在这里插入图片描述

3、定义范围

  • 在这里插入图片描述

4、创建工作分解结构(WBS)

  • l 、里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线

  • 2 、工作包应便千完整地分派给不同的人或组织单元。工作包应该非常具体,以便承担者明确自己的任务、努力的目标和承担的责任。作为一种经验法则, 8/80 规则( 80 小时原则) 建议工作包的大小应该至少盂要8 小时来完成,而总完成时间也不应该大千80 小时(掌握)

  • 3 、控制账户是一种管理控制点
    在该控制点上,将范围、预算( 资源计划) 、实际成本和进度加以整合,并将它们与挣值进行比较,以测量绩效。
    控制账户是WBS 某个层次上的要素,既可以是工作包,也可以是比工作包更高层次上的一个要素。如果是后一种情况,一个控制账户中就包括若干个工作包,但一个工作包仅属于一个控制账户。项H 管理团队在控制账户上考核项H 的执行情况,即在控制账户的相应要素下,将项目执行情况与计划情况进行比较,以便评价执行情况好坏,并发现与纠正偏差。

  • 4 、规划包是指在控制账户之下,工作内容已知但尚缺详细进度活动的WBS 组成部分
    规划包是在控制账户之下、工作包之上的WBS 要素。规划包是暂时用来做计划的,随着情况的逐渐清晰,规划包最终将被分解成工作包以及相应的具体活动。

  • 5、WBS 词典包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。(掌握) ( WBS 字典实际是相当于新华字典,是对WBS 中每个元素的描述)

  • 6 、分解是一种将项H 可交付成果和项目工作分解成较小的、更易千管理的组件的技术。
    7 、要将整个项目工作分解为工作包,通常需要开展以下活动:
    @识别和分析可交付成果及相关工作。
    @确定WBS 的结构和编排方法。
    @自上而下逐层细化分解。
    @为WBS 组件制定和分配标识编码。
    @核实可交付成果分解的程度是恰当的。

  • 8、创建WBS 时对工作的划分原则包括:
    @功能或者技术原则:在创建WBS 时,盂要考虑将不同人员的工作分开。
    @组织结构:对千职能型的项目组织而言, WBS 也要适应项目的组织结构形式
    @系统或者子系统:总的系统划分为几个主要的子系统,然后对笝个子系统再进行分解。

  • WBS 分解的方法:
    @)项目生命周期的各阶段作为分解的第二层,产品和项目可交付成果放在第三层
    @主要可交付成果作为分解的第二层
    @整合可能由项目团队以外的组织来实施的各种组件(例如,外包工作),然后作为
    处包工作的一部分,卖友需编制相应的合同WBS

  • WBS 不是某个项H 团队成员的责任,应该山全体项目团队成员、用户和项目干系人共同完成和一致确认
    WBS 表示形式主要有分级的树型结构( 组织结构图式) 和表格形式( 列表式)。树型结构图的WBS li!t ::目、直如性和结叶拐,但不容易修,对大、、^、珩目很难表示出项目的全貌(小项目) 。表格形式的直观性比较差,但能够反映出项目所有的工作要素

  • WBS 分解注意8 个方面
    @WBS 必须是面向可交付成果的:所有下一级的元素之和必须100%的代表上一级元素。
    @WBS 必须符合项目的范围。WBS 必须包括,也仅包括为了完成项目的可交付成果的活动
    @WBS 的底层应该支持计划和控制。WBS 是项目管理计划和项目范围之间的桥梁, WBS
    的底层不但要支持项H 管理计划,而且要让管理层能够监视和控制项目的进度和预算。
    @WBS 中的元素必须有人负责,而且只由一个人负责,尽管实际上可能盂要多个人参与。
    @WBS 的指导, WBS 应控制在旦必~ o 当然,大项目可以超过6 层。
    @WBS 应包括项目管理工作( 因为管理是项目具体工作的一部分) ,也要包括分包出去的工作。
    @WBS 的编制需要所有(主要)项目干系人的参与,盂要项目团队成员的参与。
    @WBS 并非是一成不变的。在完成了WBS 之后的工作中,仍然有可能需要对WBS 进行修改。

  • 当一个项目 的WBS 分解完成后,项目千系人对完成的WBS 应该给予确认,并对此达成共识。WBS 的目的和用途主要体现在以下8 个方面:
    (1) 明确和准确说明项目范围,项H 团队成员能够清楚地理解任务的性质和盂要努力的方向。
    ( 2 ) 清楚地定义项目的边界
    ( 3 ) 为各独立单元分派人员,规定这些人员的职责,可以确定完成项H 所需要的技术和人力资源。
    ( 4 ) 针对独立单元,进行时间、成本和资源需求量的估算,提高估算的准确性。
    ( 5 ) 为计划、预算、进度安排和费用控制奠定共同基础,确定项目进度和控制的基准。
    ( 6 ) 将项H 工作和项目的财务账目联系起来。
    ( 7 ) 确定工作内容和工作顺序,将项目分解成具体的工作任务,就可以按照工作任务的逻辑顺序来实施项H 。
    ( 8 ) 有助千防止需求蔓延。

2. 3 确认和控制范围(监控)

5、确认范围

  • l 、确认范围是正式验收项目已完成的可交付成果的过程。包括与客户或发起人一起审查可交付成果,确保可交付成果已圆满完成,并获得客户或发起人的正式验收。( 了解)

  • 2 、确认范围的主要工具与技术是检查和群体决策技术
    检查也称为审查、评审、审计、走查、巡检、测试等,是指开展测量、审查与确认等活动,来判断工作和可交付成果是否符合需求和产品验收标准。(掌握)

  • 3 、确认范围应该贯穿项目的始终。

  • 4 、确认范围的一般步骤: 叩确定需要进行范围确认的时间一@识别范围确认需要哪些投入一@确定范围正式被接受的标准和要素一@确定范围确认会议的组织步骤一@组织范围确认会议

  • 干系人关注点: (掌握)
    ( 1 ) 管理层:所关注的项目范围,是指范围对项目的进度、资金和资源的影响,这些因素是否超过了组织承受范围,是否在投入产出上具有合理性。(20 下31) ( 21 下31) l
    ( 2 ) 客户:关心的是产品的范围,关心项H 的可交付成果是否足够完成产品或服务。{2 1 上31)
    ( 3 ) 项目管理人员:关注可交付成果是否足够和必须完成,时间、资金和资源是否足够,主要的潜在风险和预备解决的方法。
    ( 4 ) 项目团队成员:关心项目范围中自己参与的元素和负责的元素,通过定义范围中的时间检查自己的工作时间是否足够,自己在项H 范围中是否有多项工作,而这些工作又有冲突的地方

  • 6 、在项目中,客户和项目团队成员往往有在当前版本中加入所有功能和特征的意愿,这对千项目来说是一种潜在的风险,会给组织和客户带来危害和损失。如果在确认范围工作中发现项目范围说明书、WBS 中有遗漏或者错误,盂要向项目团队明确指出错误的内容,并给出修正的意见。项目团队需要根据修改意见重新修改项目范围说明书和WBS 。在确认范围的工作过程中也可能会出现范围变更请求,如果这些范围变更请求得到了批准,那么也要重新修改项目范围说明书和WBS 。

  • 7 、核实产品是针对产品是否完成,在项目(或阶段)结束时由发起人或客户来验证,强调产品是否完整;确认范围是针对项目可交付成果,山客户或发起人在脏段苤确认验收的过程。

  • 确认范围与质量控制的不同之处在:
    ( 1 ) 确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性,并符合为其制定的具体质量要求( 质量标准)。
    ( 2 ) 质量控制一般在确认范围前进行,也可同时进行;确认范围一殷在阶段末尾进行,而质量控制并不一定在阶段未进行。
    ( 3 ) 质量控制属内部检查,山执行组织的相应质量部门实施;确认范围则是山外部干系人(客户或发起人)对项目可交付成果进行检查验收。

  • 确认范围与项目收尾的不同之处在:
    ( 1 ) 虽然确认范围与项目收尾工作都在阶段未进行,但确认范围强调的是核实与接受可
    交付成果,而项目收尾强调的是结束项目(或阶段)所要做的流程性工作。
    ( 2 ) 确认范围与项目收尾都有验收工作,确认范围强调验收项目可交付成果,项目收尾强调验收产品。

6、控制范围

  • 控制范围是监督项目和产品的范围状态、管理范围基准变更的过程,其主要作用是在整个项目期间保持对范围基准的维护。
    对项目范围进行控制,就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时,也要采用范围控制过程来管理这些变更。

  • 造成项目 范围变更的主要原因是项H 外部环境发生了变化,例如: (了解)
    ( 1 ) 政府政策的问题。
    ( 2 ) 项目范围的计划编制不周密详细,有一定的错误或遗漏。
    ( 3 ) 市场上出现了或是设计人员提出了新技术、新手段或新方案。
    ( 4 ) 项目执行组织本身发生变化。
    ( 5 ) 客户对项H 、项目产品或服务的要求发生变化

  • 未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)称为范围蔓延。[客户不断提出要求,不断去改,最终交付物不满足要求!
    镀金:项目实施人员往往愿意尝试新的技术或者为信息系统项目加上]变更是不可避免的,控制范围过程依赖于范围变更控制系统,范围变更控制是指对有关项目范围的变更实施控制,审批项目范围变更的一系列过程,包括书面文件、跟踪系统和授权变更所必须的批准级别

  • 范围变更控制的工作:
    ( 1 ) 影响导致范围变更的因素,并尽量使这些因素向有利的方面发展。
    ( 2 ) 判断范围变更是否已经发生。
    ( 3 ) 范围变更发生时管理实际的变更,确保所有被请求的变更按照项目整体变更控制过程处理

3、进度管理(时间管理)

进度管理是667-4343-644 的第7 个过程。这是制定管理进度的过程,包括规划、定义活动、排序、估资源、估持续时间、制定进度、控制进度。

3.1 规划进度管理(规划)

结合项目管理计划,看看掌程中的高层定的计划和审批要求规定项目时间管理的各个过程、规划进度的方法和工具,确定格式和准则。

3.2 定义活动(规划)

  • 范围基准上拆分活动和里程碑。就是定义具体要做什么
  • 先找到WBS, 在【范围基准) 里面,记住是要范围基准哦,光有范围说明书这么粗的东西是不行的,关键是要WBS, 然后找到具体做这个工作包的人把它拆分成一个个具体的活动( 活动清单】,要越具体越好,每个小活动不要太复杂,否则继续分下去,最后给每个活动加个描述( 活动属性】,再定出一个个检查点( 里程碑清单】,这下子要做的事情就很具体了。
  • 工具和技术:专家判断、备选方案分析、发布的估算数据、自下而上估算

3.3 排列活动顺序(规划)

  • 活动有优先级的,要分先后轻重的,就对刚才的【活动清单入【活动属性) 和【里程碑清单) 进行排列最简单了,因为不同的产品的特征不一样,考虑软逻辑和硬逻辑( 如盖房子必须先打地埜) ,所以再让他看看【范围说明书)
  • 看懂后开始排顺序了,怎么排呢,用( 进度网络图) 来排,画圈圈,填活动名称,用箭头连可以想象,活动多了,画出来就是一个蜘蛛网一样( 进度网络图】。
  • 工具和技术:紧前关系绘图法 (FS/FF/SS/SF)、确定依赖关系、提前量和滞后量

3.4 估算活动资源(规划)

  • 确定每个活动要用多少人、和物品( 均可以采购)。参考资源日历给活动标上资源。排列活动之间关系顺序是需要知道事情大概千什么,但是估计资源就不用,看着一个个具体事情本身【活动清单) 【活动属性) 就知道要分配谁了, 当然查【资源日历) 确认一下人家是否有时间嘛,没时间分了也臼搭,
  • 还得查查"估算成本”的输出【活动成本估算) ,然后在查查【风险登记册) ,最后汇总成一张清单,包括每个活动有谁来做,要用什么东西,这就是( 活动资源需求】,还要分配的资源类别( 资源分解结构RBS 】,这样很直观也好管理。
  • 工具和技术:专家判断、备选方案分析、发布的估算数据、自下而上估算

3.5 估算活动持续时间(规划)

  • 参考范围说明书和资源日历标上资源所需时间。确定每个活动花多久来做。
    还是一样,找出那个活动清单和属性表【活动清单入【活动属性) ,例如“登录网页设计”由张三负责设计,张三这人水平怎么样的,得去【资源日历) 里面看看,原来是初级工程师,应该会做得慢点,那就定的时间长点,但是从【范围说明书) 上注明了这个很重要,要得有点急,时间要往前推,最后在活动清单和属性表后面加了估算出来的时间就是( 活动持续时间估算】
  • 工具和技术:专家判断、类比估算、参数估算、三点估算、群体决策技术(包括一致同意(德尔菲技术)、大多数原则、相对多数原则、独裁)、储备分析

3.6 制定进度计划(规划)

  • 汇总之前所有文档定出进度计划。
    选择一种工具和进度模型( 如microsoft project 和甘特图) ,开始画进度了。
    把之前搞出来的东西都录入进去,包括【活动清单入【活动属性) ,【进度网络图入【活动资源需求入【资源分解结构入【资源日历入【活动持续时间估算入【项目人员分派入【风险登记册)、再检查检查【范围说明书) 是否有什么没有考虑到的,都录进去了就得到了( 进度计划】,从进度计划里面规范出一个考核文档就是( 进度埜准】,同时还形成了进度数据、项目日历。

  • 工具和技术:关键路径法、关键链法、资源优化技术:资源平衡和资源平滑、进度压缩:赶工和快速跟进

3.7 控制进度(监控)

  • 实时监控项目进度状态,判断状态,根据目前实际情况进行进度预测,看能否按照计划进行。
  • 这个和控制范围一样,拿每天收集的指导和实施工作情况产生的【工作绩效数据) 和【进度计划) 、"进度基准” 一比较就知道了,怎么看不到“进度基准“,原来藏在【项目管理计划) 里面,最后得到( 工作绩效信息】,发现问题就提出修改( 变更请求】
  • 工具和技术:绩效审查(趋势分析、关键路径法、关键链,挣值管理)、资源优化技术:资源平衡和资源平滑、提前量和滞后量、进度压缩:赶工和快速跟进

猜你喜欢

转载自blog.csdn.net/qq_33957603/article/details/130090643