第4章 项目管理一般知识


4.1.1 项目的定义
项目是为达到特定的目的,使用一定资源,在确定的期间内,为特定发起人提供独特的产品、服务或成果而进行的一系列相互关联的活动的集合。项目有完整的生命周期,有开始,有结束,具有 一次性、临时性的特点。
这里的资源指完成项目所需要的人、财、物等;期间指项目有明确的开始日期和结束日期。

4.1.2 项目目标

1、项目目标的概念(成果性目标、约束性目标,SMART原则)

项目目标包括成果性目标和约束性目标。项目的约束性目标也叫管理性目标,项目的成果性目标有时也简称为项目目标。项目成果性目标指通过项目开发出的满足客户要求的产品、系统、服务或成果。项目约束性目标是指完成项目成果性目标需要的时间、成本以及要求满足的质量。项目的目标要求遵守SMART原则,即项目的目标要求Specific(具体的)、Measurable(可测量的)、Attainable (可以达到的)、Relevant (有相关性的)、Time-bound (有明确时限的)

2、项目目标的特性(优先级、层次性)

(1)项目的目标有不同的优先级
项目是一个多目标的系统,不同目标可能在项目管理不同阶段根据不同需要,其重要性不一样。
(2)项目目标具有层次性
项目目标的层次性是指对项目目标的描述需要有一个从抽象到具体的层次结构。即,一个项目目标既要有最高层的战略目标,又要有较低层次的具体目标。通常是把明确定义的项目目标按其意义和内容表示为一个层次结构,而且层次越低的目标应该描述的越清晰、具体。
项目目标一般由项目的客户(或具体投资方)、用户或项目的发起人来确定,有时还需要潜在承包商来参与确定。客户是指提供资金、确定需求并拥有项目开发出的产品、服务或成果的组织(或个人);用户则是使用项目开发出的产品、服务或成果的组织(或个人)。
对信息系统项目而言,项目的成果性目标是指通过该项目开发出的信息系统。信息系统项目的客户的需求偏重于用这个信息系统支撑或者促进自身业务的发展。信息系统的用户也有需求,用户的需求偏重于要求该系统好用,能够减轻自己的劳动,提高自己的劳动效率。客户可以是用户,也可以不是。

4.1.3 项目的特点(临时性、独特性、渐进明细)

1、临时性
项目是指每一个项目都有一个明确的开始时间和结束时间,临时性也指项目是一次性的。
2、独特性
项目要提供某一独特产品,提供独特的服务或成果。 “没有完全一样的项目”
3、渐进明细
指项目的成果性目标逐步完成的。

4.1.4 信息系统集成项目的特点(7个)

信息系统集成,就是从客户和用户的需求出发,将硬件、系统软件、工具软件、网络、数据库、应用软件或者云计算提供的服务以及相关的支撑环境集成为实用的信息系统的过程。在这个过程中,应根据需求,开发相应的软件和硬件,并把它们集成为一个系统。
信息系统集成项目的产品是满足需求、支持用户业务的信息系统
信息系统集成项目建设的指导方法是“总体规划、分步实施”。

信息系统集成项目有以下几个显著特点。(1)信息系统集成项目要以满足客户和用户的需求为根本出发点。(2)客户和用户的需求常常不够明确、复杂多变,由此应加强需求变更管理以控制风险。(3)系统集成不是简单选择最好产品的行为,而是要选择(或开发)最适合用户的需求和投资规模的产品、技术和服务的活动的集合。(4)高技术与高技术的集成。系统集成也不是简单的设备供货,系统集成是高技术的集成,涉及到的工作更多的是设计、调试与开发,是高技术行为。高新技术的应用,一方面会带来成本的降低、质量的提高、工期的缩短,同时如没有掌握就应用新技术的话,也会带来相应的风险。(5)系统工程。系统集成包含技术,管理和商务等方面,是一项综合性的系统工程,需要相关的各方足够重视,必要时应“一把手”挂帅,并且多方要密切协作。(6)项目团队的成员年轻,流动率高。因此对企业的管理技术水平和项目经理的领导艺术水平要求较高。(7)强调沟通的重要性。信息系统开发需要成员间的协作,也可以说是沟通的产物。在开发信息系统的过程中沟通无处不在,从需求调研到方案设计、从设计到部署都涉及沟通问题。技术的集成需要以标准为基础,人与人、单位与单位之间的沟通需要以法律、法规、规章制度为基础,信息的产生、保存与传递需以安全为基础。总而言之,系统集成项目管理既是一种管理行为又是一种技术行为。

4.1.5 项目管理的定义及其知识范围
4.1.6 项目管理需要的专业知识和技术
有效的项目管理要求项目管理团队至少能理解和使用以下6方面的专门知识。
(1)项目管理知识体系。
(2)项目应用领域的知识、标准和规定。
(3)项目环境知识
(4)通用的管理知识和技能
(5)软技能或人际关系技能
(6)经验、知识、工具和技术。

软技能主要涉及人际关系管理。

软技能包含(沟影领导激谈分解)

(1) 有效的沟通,即有效的交流信息。
(2) 对组织施加影响,即“让事情办成”的能力。
(3) 领导能力,即形成一个前景和战略并组织人员实现他的能力。
(4) 激励,就是激励相关人员达到高水平的生产率并克服变革的阻力。
(5) 谈判和冲突管理,就是与其他人谈判取得一致或达成协议。
(6) 分析和综合归纳能力。
(7) 解决问题,就是首先定义问题、明确问题,然后做出决策并解决问题。

4.1.7 项目管理学科的产生和发展 183

4.1.8 项目经理应该具备的技能和素质

一个合格的项目经理,至少应当具备如下的素质。(项目经理5大要求)
1、足够的知识
信息系统项目的项目经理所需要的知识包括4个部分。①项目管理:包括项目管理的理论、方法论和相关工具。②丰富的IT知识。③客户行业的业务知识。④其他必要的知识。
2、丰富的项目管理经验
3、良好的沟通协调能力
4、良好的职业道德
5、一定的领导和管理能力

怎样当好一个优秀的项目经理
(1) 真正理解项目经理的角色
(2) 领导并管理项目团队
(3) 依据项目进展的阶段,组织制定详细程度适宜的项目计划,监控计划的执行,并根据实际情况、客户要求或其他变更要求对计划的变更进行管理。
(4) 真正理解“一把手工程”
(5) 注重客户和用户参与

4.1.9 项目干系人
项目干系人是指那些积极参与项目,或是其利益会受到项目执行的影响,或是其利益会受到项目结果影响的个人和组织,他们也可能会对项目及其结果施加影响。项目干系人也叫“项目利益相关者”“项目利害关系者”,项目干系人是最常用的叫法。项目管理团队必须明确项目的干系人,确定其需求,然后对这些需求进行管理和施加影响,确保项目取得成功。

4.1.10 项目管理系统
项目管理系统是指用于管理项目的工具、技术、方法、资源和过程组之集合。项目管理计划说明这个系统如何使用,项目管理系统的内容随应用领域、组织影响、项目复杂性、现有系统的有效性等而变化。
项目管理系统(可以是正式的或非正式的),有助于项目经理有效地控制项目顺利完成。

4.1.11 事业环境因素

项目经理不可控、不能改变
在项目启动时,必须考虑涉及并影响项目成功的环境、组织的因素和系统。这些因素和系统可能促进项目也可能阻碍项目,包括下列这几项主要因素和系统:
(1) 实施单位的企业文化和组织结构
(2) 国家标准或行业标准
(3) 现有的投资和固定资产等
(4) 实施单位现有的人力资源、人员的专业和技能,人力资源管库政策,如招聘和解聘的指导方针、员工绩效评估和培训记录等
(5) 当时的市场状况
(6) 项目干系人对风险的承受力
(7) 行业数据库
(8) 项目管理信息系统(可能是工具,也可能是软件,总之能帮助人们管理项目)

4.1.12 组织过程资产

项目经理可控、可以参照改变
组织过程资产包含:项目实施组织的企业计划、政策方针、规程、指南和管理系统,实施项目组织的知识和经验教训。在制定项目章程和后续的项目文档时,可以从组织得到用以促进项目成功的全部的组织过程资产。组织过程资产依据行业的类型、组织和应用领域等几个方面的结合可以有不同的组成形式,例如组织过程资产可以分成以下两类:
1、组织中指导工作的过程和程序
组织的标准过程,例如标准、政策如项目管理政策、公司规定的产品和项目生命周期、质量政策和规定。标准指导方针、模板、工作指南、建议评估标准、风险模板和性能测量准则。用于满足项目特定需要的标准过程的修正指南。为满足项目的特定需求,对组织标准过程集进行剪裁的准则和指南。组织的沟通要求、汇报制度。项目收尾指南或要求,例如结项审计、项目评估、产品确认和验收标准指南。财务控制程序,如汇报周期、必要开支、支出评审、会计编码和标准合同条款。问题和缺陷管理程序、问题和缺陷的识别和解决、问题追踪。变更控制流程,包括修改公司正式的标准、方针、计划和程序及任何项目文件,以及批准和确认变更的步骤。风险控制程序,包括风险的分类、概率和影响定义、概率和影响矩阵。批准与发布工作授权的程序。
2、组织的全部知识
项目档案(完整记录以往每个项目的文件、记录、文档、收尾信息和文档,包括基准文件)。过程测量数据库,用于收集和提供过程和产品的实测数据。经验学习系统,包括以前项目的选择决策、以往的项目绩效信息和风险管理经验教训。问题和缺陷管理数据库,包括问题和缺陷的状态、控制、解决方案和行动项结果。配置管理知识库,包括所有的正式的公司标准、政策、程序和项目文档的各种版本和基线。财务数据库,包括劳动时间、产生的费用、预算和项目超支费用等信息。
在这里插入图片描述

4.2 项目的组织方式

4.2.1 组织体系 193
4.2.2 组织的文化、风格与沟通 193

4.2.3 组织结构(职能型、矩阵型、项目型、复合型 组织)

在这里插入图片描述

1、职能型组织

优点:
(1) 强大的技术支持,便于知识、技能和经验的交流
(2) 清晰的职业生涯晋升路线
(3) 直线沟通、交流简单、责任和权限很清晰
(4) 有利于重复性工作为主的过程管理
缺点:
(1) 职能利益优先于项目,具有狭隘性
(2) 组织横向之间的联系薄弱、部门间沟通、协调难度大
(3) 项目经理极少或缺少权利、权威
(4) 项目管理发展方向不明,缺少项目基准等
在这里插入图片描述

2、项目型组织

优点:
(1) 结构单一,责任分明,利于统一指挥
(2) 目标明确单一
(3) 沟通简洁、方便
(4) 决策快
缺点:
(1) 管理成本过高,如项目的工作量不足则资源配置效率低
(2) 项目环境比较封闭,不利于沟通、技术知识等共享
(3) 员工缺乏事业上的连续型和保障
在这里插入图片描述

3、矩阵型组织

优点:
(1) 项目经理负责制、有明确的项目目标
(2) 改善了项目经理对整体资源的控制
(3) 及时响应
(4) 获得职能组织更多的支持
(5) 最大限度地利用公司的稀缺资源
(6) 降低了跨职能部门间的协调合作难度
(7) 使质量、成本、时间等制约因素得到更好的平衡
(8) 团队成员有归属感,士气高,问题少
(9) 出现的冲突较少,且易处理解决
缺点:
(1) 管理成本增加
(2) 多头领导
(3) 难以监测和控制
(4) 资源分配与项目优先的问题产生冲突
(5) 权利难以保持平衡等
在这里插入图片描述
在这里插入图片描述

4、复合型组织

基于项目的组织(Project-based Oragenizations,PBO)是指建立临时机构来开展工作的各种组织形式。在各种不同的组织结构中如职能型、矩阵型或项目型,都可以建立PBO。采用PBO可以减轻组织中的层级主义和官僚主义,因为在PBO中,智能考核工作成败的依据是最终结果,与职位或政治因素无关。
在 PBO 中,大部分工作都被当作项目来做,可以按项目方式而非职能方式进行管理。可以在整个公司层面采用PBO,如在电信、油气、建筑、咨询和专业服务等行业中;也可以在多公司财团或网络组织中采用 PBO;也可以仅在组织的某个部门或分支机构内部采用 PBO。一些大型的 PBO 可能需要职能部门的支持。
在这里插入图片描述

4.2.4 PMO在组织结构中的作用

项目管理办公室(PMO,Project Management Office)是在所辖范围内集中、协调地管理项目的组织内的机构。PMO也被称为“项目办公室”“大型项目管理办公室”或“大型项目办公室”。根据需要,可以为一个项目设立一个PMO,可以为一个部门设立一个PMO,也可以为一个企业设立一个PMO,这三级PMO可以在一个组织内可以同时存在。

PMO的关键特征
(1) 在所有PMO管理的项目之间共享和协调资源
(2) 明确和制定项目管理方法、最佳实践和标准
(3) 负责制订项目方针、流程、模板和其他共享资料
(4) 为所有项目进行集中的配置管理
(5) 对所有项目的集中的共同风险和独特风险存储库加以管理
(6) 项目工具(如企业级项目管理软件)的实施和管理中心
(7) 项目之间的沟通管理协调中心
(8) 对项目经理进行指导的平台
(9) 通常对所有PMO管理的项目的时间基线和预算进行集中监控
(10) 在项目经理和任何内部或外部的质量人员或标准化组织之间协调整体项目的质量标准

PMO类型(支持型、控制型、指令型)

(1)支持型。支持型 PMO 担当顾问的角色,向项目提供模板、最佳实践、培训,以及来自其他项目的信息和经验教训。这种类型的 PMO其实就是一个项目资源库,对项目的控制程度很低。
(2)控制型。控制型PMO不仅给项目提供支持,而且通过各种手段要求项目服从PMO的管理策略,例如要求采用项目管理框架或方法论,使用特定的模板、格式和工具,或者要求项目经理服从组织对项目的治理。这种类型的PMO对项目的控制程度属于中等。
(3)指令型。指令型PMO直接管理和控制项目。这种类型的PMO 对项目的控制程度很高。

项目经理 和 项目管理办公室(PMO)的区别

(1)项目经理和PMO追求不同的目标,同样,受不同的需求所驱使。所有工作都必须在组织战略要求下进行调整。
(2)项目经理负责在项目约束条件下完成特定的项目成果性目标,而PMO是具有特殊授权的组织机构,其工作目标包含组织级的观点
(3)项目经理关注于特定的项目目标,而PMO管理重要的大型项目范围的变化,以更好地达到经营目标
(4)项目经理控制赋予项目的资源以最好地实现项目目标,而PMO对所有项目之间的共享组织资源进行优化使用。
(5)项目经理管理中间产品的范围、进度、费用和质量,而PMO管理整体的风险、整体的机会和所有的项目依赖关系。

4.3 项目生命周期

4.3.1 项目生命周期的特征
按管理活动出现的先后,把项目的生命周期划分为启动、计划、执行和收尾等 4 个典型的阶段。
信息系统项目的生命周期,如果详细划分,一般可划分为可行性分析、业务流程优化或变革、信息系统规划、系统需求分析、系统设计、系统实现、系统测试、系统实施、系统试运行、验收等阶段。而开发完成的信息系统的生命周期,除包含前期的项目生命周期外,还包括验收后的协调运营与维护、系统退役等阶段。根据行业特点、企事业单位的规模、项目特点等对这些阶段可以有不同程度的增删和裁剪。

4.3.2 项目阶段的特征
每个项目阶段都以一个或一个以上的可交付物的完成为标志,这种可交付物是一种可度量、可验证的工作成果,如一份规格说明书、可行性研究报告、详细设计文档、产品模块或工作样品。
项目阶段的结束前,一般要对完成的工作和可交付物进行技术或设计评审,根据评审结果,以决定是否接受,是否还要做额外的工作或是要结束这个阶段。
阶段的正式完成不包括对后续阶段的批准。为了有效地控制,每个阶段都要明确该阶段的任务作为正式启动。如图 4-11 所示。在获得授权的情况下,阶段末的评审可以结束当前阶段并启动后续阶段。有些时候一次评审就可以取得这两项授权。这样的阶段末评审通常被称为阶段出口阶段验收终止点
在这里插入图片描述
4.3.3 项目生命周期与产品生命周期的关系
一个项目要交付特定的产品、成果和完成特定的服务。项目生命周期定义项目的开始与结束。假如一个项目交付特定的产品,那么该产品的生命期比项目生命周期更长,从该产品的研发(此时是项目的任务),到该产品投入使用(或运营),直到该产品的消广就构成了该产品的生命周期。许多项目与组织发展战略或正在进行的工作有关。在一些组织中,一个项目只有在完成了可行性研究、初步计划或者其他等同形式的分析之后才能正式批准。在这些案例中,初步规划或分析可以采用独立项目的形式。例如,在确定开发最终产品之前,可以将原型的开发和测试作为单独的项目。
在这里插入图片描述

4.4 典型的信息系统项目的 生命周期模型

瀑布模型(侧重 开发)

瀑布模型是一个经典的软件生命周期模型,也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里,在项目生命周期的尽早时间,要确定项目范围及交付此范围所需的时间和成本。在这个模型里,项目启动时,项目团队专注于定义产品和项目的总体范围,然后制定产品(及相关可交付成果)交付计划,接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增范围,则需要重新计划和正式确认。
以下情况优先选择这种生命周期:项目需求明确、充分了解拟交付的产品、有厚实的行业实践基础、或者整批一次性交付产品有利于干系人
适用于:需求明确或很少变更的项目。如二次开发或升级型的项目,有利于大型软件开发人员的组织与管理;开发团队比较弱或缺乏经验。
例如开发一个软件项目时,如果采用这个模型的话,一般将软件开发分为可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段,如图4-13所示。
在这里插入图片描述
瀑布模型中每项开发活动具有以下特点。(1)从上一项开发活动接受其成果作为本次活动的输入。(2)利用这一输入,实施本次活动应完成的工作内容。(3)给出本次活动的工作成果,作为输出传给下一项开发活动。(4)对本次活动的实施工作成果进行评审。若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。

迭代模型(RUP,软件统一过程)

需求不明时用
在迭代模型中,每个阶段都执行一次传统的、完整的串行过程串,执行一次过程串就是一次迭代。每次迭代的过程都包括不同比例的所有活动
RUP (Rational Unified Process)软件统一过程是一种“过程方法”,它就是迭代模型的一种。RUP可以用二维坐标来描述。横轴表示时间,是项目的生命周期,体现开发过程的动态结构,主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴表示自然的逻辑活动,体现开发过程的静态结构,主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow),如图4-14所示。
在这里插入图片描述
RUP 中的软件生命周期在时间上被分解为 4 个顺序的阶段,分别是:初始阶段(Inception)、细化阶段(Elaboration)、构建阶段(Construction)和交付阶段(Transition)。这4个阶段的顺序执行就形成了一个周期。
每个阶段结束于一个主要的里程碑(Major Milestone)。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。
每个阶段,从上到下迭代,亦即从核心过程工作流“商业建模”“需求调研” “分析与设计”……执行到“部署”,再从核心支持工作流“配置与变更管理”“项目管理”执行到“环境”完成一次迭代。根据需要,在一个阶段内部,可以完成一次到多次的迭代。各阶段的主要任务如下。
(1)初始阶段:系统地阐述项目的范围、确定项目的边界,选择可行的系统构架,计划和准备商业文件。商业文件包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。
(2)细化阶段:分析问题领域,建立健全体系结构并选择构件,编制项目计划,淘汰项目中最高风险的元素。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。
(3)构建阶段:完成构件的开发并进行测试,把完成的构件集成为产品,测试产品所有的功能。构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量
(4)交付阶段:交付阶段的目的是将软件产品交付给用户群体。当本次开发的产品成熟得足够发布到最终用户时,就进入了交付阶段。交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。软件产品交付给用户使用一段时间后,如有新的需求则该开始另一个开发周期,就开始下一个的“初始、细化、构建和交付”周期。

以下情况优先选择迭代和增量型生命周期:组织需要管理不断变化的目标和范围,组织需要降低项目的复杂性,或者,产品的部分交付有利于一个或多个干系人,且不会影响最终或整批可交付成果的交付。
大型复杂项目通常采用迭代方式来实施,这使项目团队可以在迭代过程中综合考虑反馈意见和经验教训,从而降低项目风险。

敏捷方法(以人为核心、迭代、循序渐进、“客户在现场”)

敏捷方法是一种以人为核心、迭代、循序渐进的开发方法,适用于一开始并没有或不能 完整地 确定出 需求 和 范围 的项目,或者需要应对快速变化的环境,或者需求和范围 难以事先确定,或者能够以有利于干系人的方式定义较小的增量改进
敏捷方法,也叫适应型生命周期、或者变更驱动方法
在软件项目的敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
敏捷方法的目的在于应对大量变更,获取干系人的持续参与。敏捷方法里迭代很快(通常2~4周迭代1次),而且所需时间和资源是固定的。虽然早期的迭代更多地聚焦于计划活动,但通常在每次迭代中都会执行多个过程。

V模型(侧重 测试)

在这里插入图片描述
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
(1)单元测试的主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误
(2)集成测试主要目的是针对详细设计中可能存在的问题,尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。(吉祥)
(3)系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行,例如在产品设置中是否能达到预期的高性能。(膝盖)
(4)验收测试通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。
在不同的开发阶段,会出现不同类型的缺陷和错误,所以需要不同的测试技术和方法来发现这些缺陷。
V模型用于需求明确和需求变更不频繁的情形。

原型化模型

原型化模型是为弥补瀑布模型的不足而产生的。原型化模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,经过和用户针对原型的讨论和交流,弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后,再在原型基础上开发出用户满意的产品。在实际中原型化经常在需求分析定义的过程进行。原型化模型减少了瀑布模型中因为软件需求不明确而给开发工作带来的风险,因为在原型基础上的沟通更为直观,也为需求分析和定义,提供了新的方法。原型化模型的应用意义很广,瀑布和V模型将原型化模型的思想用于需求分析环节,来解决因为需求不明确而导致产品出现严重后果的缺陷。对于复杂的大型软件,开发一个原型往往达不到要求,为减少开发风险,在瀑布模型和原型化模型的基础上的演进,出现了螺旋模型以及大量使用的RUP。
动态响应、逐步纳入、反复修改、逐步完善
可分为:抛弃型模型和进化型模型

螺旋模型(制定计划、风险分析、实施工程、客户评估)

螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中,软件开发是一系列的增量发布。在早期的迭代中,发布的增量可能是一个纸上的模型或原型;在以后的迭代中,被开发系统的更加完善的版本逐步产生。螺旋模型的整个开发过程如图4-16所示。图4-16中的螺旋线代表随着时间推进的工作进展;开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4个阶段:制定计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。
在这里插入图片描述

4.5 单个项目的管理过程(4种过程:技术、管理、支持、改进)

一般说来,要把一个项目管好,至少需要 4 种过程。
(1)技术类过程(或称工程类过程)。技术过程要解决“研制特定产品、完成特定成果或提交特定服务的具体技术过程”,要回答怎么在技术上完成?怎么把产品制造出来?要回答“技术上怎么做?”。技术过程跟项目所在的行业有关,例如信息系统项目的技术过程有“需求分析”“总体设计”“编码”“测试”“布线”“组网”等。
(2)管理类过程。大多数行业的项目都有共同的管理过程。按出现的时间先后划分,管理过程可以被分为启动、计划、执行、监控和收尾过程组。
(3)支持类过程。例如配置管理过程就属于支持类过程。
(4)改进类过程。例如总结经验教训、部署改进等过程。

4.5.1 项目过程(PDCA)

在这里插入图片描述
在这里插入图片描述

4.5.2 项目管理过程组(五大过程组:启动、计划、执行、监控、收尾)

(1)启动过程组:定义并批准项目或阶段。
(2)计划编制过程组:定义和细化目标,规划最佳的技术方案和管理计划,以实现项目或阶段所承担的目标和范围。(计划)
(3)执行过程组:整合人员和其他资源,在项目的生命期或某个阶段执行项目管理计划,并得到输出与成果。(执行)
(4)监督与控制过程组(监控过程组):要求定期测量和监控进展、识别实际绩效与项目管理计划的偏差、必要时采取纠正措施,或管理变更以确保项目或阶段目标达成。(检查、行动)
(5)收尾过程组:正式接受产品、服务或工作成果,有序地结束项目或阶段。
在这里插入图片描述

4.5.3 项目管理过程图示(十大管理,47个过程域)

除整体、人力、采购、干系人外,均:计划为首,控制为尾
章程、计划、组织、事业是规划阶段的万能输入。
在这里插入图片描述
在这里插入图片描述

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值