《工程管理相关中英文翻译(毕业设计专用).doc》由会员分享，可在线阅读，更多相关《工程管理相关中英文翻译(毕业设计专用).doc（26页珍藏版）》请在三一办公上搜索。
1、第 2 章 项目生命周期与组织项目与项目管理都是在比项目本身更大的环境中进行的。理解这个 大环境，有助于确保项目的执行符合企业目标，项目的管理符合组织既 有的实践方法论。本章将介绍项目的基本结构和其他重要的宏观事项，包括项目如何影响持续性的运营，直接项目团队以外的干系人如何影响 项目，以及组织结构如何影响项目的人员配备、管理和执行。本章包括 以下主要部分： 2.1 项目生命周期概述 2.2 项目与运营 2.3 项目干系人 2.4 组织对项目管理的影响 2.1 项目生命周期概述 项目生命周期是通常按顺序排列而有时又相互交叉的各项目阶段的集合。阶段名称和数量取决于参与项目的一个或多个组织的管理与控
2、制需要、项目本身的特征及其所在的应用领域。生命周期可以用某种方法加以确定和记录。可以根据所在组织或行业的特性，或者所用技术的特性，来确定或调整项目生命周期。虽然每个项目都有明确的起点和终点，但其具体的可交付成果以及项目期间的活动会因项目的不同而有很大差异。无论项目涉及什么具体工作，生命周期都能为管理项目提供基本框架。 2.1.1 项目生命周期的特征 项目的规模和复杂性各不相同，但不论其大小繁简，所有项目都呈现 下列生命周期结构（见图 2-1）： 图 2-1 项目生命周期中典型的成本与人力投入水平 通用的生命周期结构通常具有以下特征： 成本与人力投入在开始时较低，在工作执行期间达到最高，并 在项
3、目快要结束时迅速回落。这种典型的走势如图 2-1 中的虚线 所示。 干系人的影响力、项目的风险与不确定性在项目开始时最大，并 在项目的整个生命周期中随时间推移而递减（见图 2-2）。 在不显著影响成本的前提下，改变项目产品最终特性的能力在项目 开始时最大，并随项目进展而减弱。图 2-2 表明，变更和纠正错误 的代价在项目接近完成时通常会显著增高。 在通用生命周期结构的指导下，项目经理可以决定对某些可交付成果 施加更有力的控制。大型复杂项目尤其需要这种特别的控制。在这种情况 下，最好能把项目工作正式分解为若干阶段。 2.1.2 产品生命周期与项目生命周期的关系 产品生命周期包含通常顺序排列且不相
4、互交叉的一系列产品阶段。产 品阶段由组织的制造和控制要求决定。产品生命周期的最后阶段通常是产 品的退出。一般而言，项目生命周期包含在一个或多个产品生命周期中。 要注意区分项目生命周期与产品生命周期。任何项目都有自己的目的或目 标。如果项目的目标是创造一项服务或成果，则其生命周期应为服务或成 果的生命周期，而非产品生命周期。 如果项目产出的是一种产品，那产品与项目之间就有许多种可能的关系。例如，新产品的开发，其本身就可以是一个项目；或者，现有的产品可能得益于某个为之增添新功能或新特性的项目，或可以通过某个项目来开发产品的新型号。产品生命周期中的很多活动都可以作为项目来实施例如，进行可行性研究，开
5、展市场调研，开展广告宣传，安装产品，召集焦点小组会议，试销产品等。在这些例子中，项目生命周期都不同于产品生命周期。由于一个产品可能包含多个相关项目，所以可通过对这些项目的统一 管理，提高效率。例如，新车的开发可能涉及许多单独的项目。虽然每 个项目都是不同的，但最终都是为了将这款新车推向市场。由一位高级负 责人监管所有项目，能显著提高成功的可能性。 2.1.3 项目阶段 为有效完成某些重要的可交付成果，而在需要特别控制的位置将项目 分界，就形成项目阶段。项目阶段大多是按顺序完成的，但在某些情况下 也可重叠。项目阶段具有的这种宏观特性使之成为项目生命周期的组成部 分。项目阶段不同于项目管理过程组。
6、 采用项目阶段结构，把项目划分成合乎逻辑的子集，有助于项目的管 理、规划和控制。阶段划分的数量和必要性以及每个阶段所需的控制程度， 取决于项目的规模、复杂程度和潜在影响。但不论项目被划分成几个阶段， 所有的项目阶段都具有以下共同特征： 当各阶段为顺序排列时，阶段的结束就以作为阶段性可交付成果的工作产品的转移或移交为标志。阶段结束点是对项目进行重新评估，并在必要时变更或终止项目的一个当然时点。这些时点可称为阶段出口、里程碑、阶段关卡、决策关卡、时段关卡或关键决策点。各阶段的工作重点不同，通常涉及不同的组织，需要不同的技能。需要施加额外的控制，以成功实现各阶段的主要可交付成果或目标。重复实施全部
7、5 大过程组中的过程（如第 3 章所述），就能提供所需的额外控制，并定义各阶段的边界。尽管很多项目可能有相似的阶段名称和相似的可交付成果，但很少有 完全相同的阶段划分。有些项目仅有一个阶段，如图 2-3 所示。有些项目 则有多个阶段。图 2-4 是一个三阶段项目的例子。不同的阶段通常有不同 的持续时间或长度。 图 2-3 单阶段项目的例子 尚没有统一的方法来定义项目的最佳结构。尽管行业惯例常常引导项目优先采用某种结构，但同一个行业内甚至同一个组织中的项目仍然可能大不相同。有些组织已经为所有项目制定了标准化的结构，而有些组织则允许项目管理团队自行选择最适合其项目的结构。例如，某个组织可能将可行性
8、研究作为常规的项目前工作，某个组织将其作为项目的第一个阶段， 而另一个组织则可能视其为一个独立的项目。同样地，某个项目团队可能把一个项目划分成两个阶段，而另一个项目团队则可能把所有工作作为一 个阶段进行管理。这些都在很大程度上取决于具体项目的特性以及项目团 队或组织的风格。 1生命周期中的项目治理 项目治理为控制项目和确保项目成功提供全面、统一的方法。该方法应记录于项目管理计划中，而且必须适应项目集或项目发起组织的大环境。 项目经理和项目管理团队应在考虑上述制约因素和时间、预算等其他限制条件的基础上，确定最合适的项目实施方法。决策时必须考虑项目将涉及哪些人、需要哪些资源，以及完成工作的一般方法
9、。另一个需要考虑的重要问题是，是否要把项目划分成一个以上的阶段。如果是，则还应决定具体的阶段结构。阶段结构为项目控制提供了正式的基础。每个阶段都需正式启动，来指明该阶段准许什么、期望什么。经常需要由管理层来审查和决定能否开始某阶段的活动。尤其在前一阶段尚未完成（例如组织所采用的生命周期允许若干阶段并行）的情况下，这种审查就更为必要。每个阶段的起点也是一个重新验证先前的假设和评估风险的机会，并可借机进一步明确为实现阶段性可交付成果所需的过程。例如，如果某个阶段不需要采购任何新材料或新设备，那么该阶段就无须开展与采购有关的任何活动或过程。项目阶段终止或正式收尾时，通常要对可交付成果进行审查，以决定
10、 其完整性和可接受性。通过阶段末评审，可以获准结束当前阶段和开始下 一个阶段。阶段结束点是对项目进行重新评估，并在必要时变更或终止项 目的一个当然时点。同时对关键可交付成果和累计项目绩效进行评审，是 一种良好的做法，可据此：a）决定项目能否进入下一个阶段；b）经济有 效地发现和纠正错误。正式结束一个阶段时，并不一定要批准下一阶段。 例如，如果项目继续下去的风险太大，或项目目标已变得毫无意义，那么 就可以只结束当前阶段，而不启动任何其他阶段。 2阶段与阶段的关系 当项目被划分为多个阶段时，这些阶段通常按顺序排列，用来保证对 项目的适当控制，并产出所需的产品、服务或成果。然而在某些情况下， 项目也
11、能从交叠或并行的阶段中受益。 阶段与阶段的关系有 3 种基本类型： 顺序关系，即一个阶段只能在前一阶段完成后开始。图 2-4 就是一个所有阶段均按顺序排列的项目的例子。其按部就班的特点减少了项目的不确定性，但也排除了缩短进度的可能性。 交叠关系，即一个阶段在前一阶段完成前就开始（见图 2-5）。这有时可作为进度压缩的一种技术，被称为“快速跟进”。如果在获得来自前一阶段的准确信息之前，就开始后一阶段，那么阶段的交叠 就可能增加风险或导致返工。 迭代关系，即一次只规划一个阶段，且下一阶段的规划取决于当前阶段及其阶段成果的进展情况。迭代关系适合在很不明确、很不确定或快速变化的环境中使用，如科研项目；
12、但是不利于进行长期规划。在管理这类项目的范围时，必须通过不断实现产品增量以及排列需求优先级，来最小化项目的风险、最大化产品的商业价值。这种模式还要求所有项目团队成员（如设计者、开发者等）在整个项目生命周期或至少连续两个阶段中使用。对多阶段项目而言，整个项目生命周期中可能发生不止一种阶段与阶 段的关系。所需达到的控制水平和效果，以及所存在的不确定性程度，决 定着应该采用何种阶段与阶段的关系。基于这些因素，上述 3 种关系可能 在同一个项目的不同阶段间发生。 2.2 项目与运营 组织通过开展工作来实现各种目标。很多组织所开展的工作都可分成 “项目”和“运营”两大类。这两类工作具有以下共同特征：由人
13、来做；受制约因素（包括资源制约因素）的限制；需要规划、执行和监控；为了实现组织的目标或战略计划。项目与运营的主要区别在于，运营是持续性的，生产重复的产品、服 务或成果。项目（连同团队，也经常连同机会）是临时性的，有明确的终 点。反之，运营是持续性的，维持组织的长久运转。运营不会因当前目标 的实现而终止，而会根据新的指令继续支持组织的战略计划。运营为项目所处的业务环境提供支持，因此运营部门与项目团队之间通常都会发生大量互动，以便为实现项目目标而协同工作。例如，在重新设计某个产品的项目中，项目经理可能要与多名运营经理合作，共同研究消费者喜好、设计技术规格、制作与测试原型，并安排生产。项目团队需 要
14、与运营部门沟通，了解现有设备的生产能力，或确定新产品投放生产线的最佳时间。不同项目需要运营部门为之提供数量不等的资源。例如，运营部门可 向项目选派全职员工。他们将与项目团队其他成员一起工作，利用其运营 专业技能来协助完成项目可交付成果，并进而协助完成项目。 基于项目的性质，其可交付成果可能改变或影响既有的运营工作。运 营部门将把项目的可交付成果整合进未来的经营活动中。会改变或影响运 营工作的项目包括（但不限于）： 开发将投放于本组织生产线的新产品或服务； 安装需长期后续支持的产品或提供需长期后续支持的服务； 会对组织结构、人员配备水平或组织文化产生影响的内部项目；开发、采购或升级运营部门的信息
15、系统。 2.3 项目干系人 项目干系人是积极参与项目或其利益可能受项目实施或完成的积极 或消极影响的个人或组织（如客户、发起人、执行组织或公众）。干系人 也可能对项目及其可交付成果和项目团队成员施加影响。为了明确项目的要求和所有相关方的期望，项目管理团队必须识别所有的内部和外部干系人。此外，为了确保项目成功，项目经理必须针对项目要求来管理各种干 系人对项目的影响。图 2-6 显示了项目、项目团队和其他常见干系人之间的关系。不同干系人在项目中的责任和职权各不相同，并且可随项目生命周期的进展而变化。有些只偶尔参与项目调查或焦点小组的活动，有些则为项目提供全力支持，包括资金和行政支持。干系人也可能对
16、项目目标有负面影响。识别干系人是一个持续性的过程，可能有一定的难度。例如，某位装 配线工人的未来就业取决于一个新产品设计项目的结果，是否应将其视为 干系人，这就可能存在争议。识别干系人，并理解他们对项目的影响力， 这是至关重要的。如果这项工作没有做好，将可能导致项目工期延长或成 本显著提高。例如，没有及时将法律部门作为重要的干系人，就会导致因 重新考虑法律要求而造成工期延误或费用增加。 干系人既可能看到项目的积极结果，也可能看到项目的消极结果。有些干系人受益于一个成功的项目，而另一些干系人则看到项目成功给他们带来的负面影响。例如，某工业扩建项目将给某个社区带来积极的经济利益，那么该社区的商业领
17、导人就会看到该项目的积极结果。对项目抱有积极期望的干系人，可通过帮助项目取得成功，来最好地实现自己的利益； 而消极干系人则会通过阻碍项目的进展，来保护自己的利益。忽视消极干系人，会提高项目失败的可能性。项目经理的重要职责之一就是管理干系人的期望。但由于干系人的期望往往差别很大，甚至相互冲突，所以这项工作困难重重。项目经理的另一项职责就是平衡干系人的不同利益，并确保项目团队以专业和合作的方式与干系人打交道。以下是项目干系人的一 些例子。 用户是将使用项目产品、服务或成果的个人或组织，可能来自项目执行组织的内部或外部。客户也可能是多层次的。例如，某种新药的客户可以包括：开处方的医生、用药的病人 以
18、及为之付款的保险公司。在某些应用领域，客户与用户是同义词；而在另一些领域，客户是指购买项目产品的个人或组织，而用户则指直接使用项目产品的个人或组织。发起人 发起人是指以现金或其他形式，为项目提供财务资源的个人或团体。早在项目刚开始构思时，发起人即为项目提供支持，包括游说更高层的管理人员，以获得组织的支持，并宣传项目将给组 织带来的利益。在整个项目选择过程中，发起人始终领导着项目， 直到项目得到正式批准。发起人对制定项目初步范围与章程也起着 重要的作用。 对于那些超出项目经理控制范围的事项，将向上汇报给发起人。发起 人可能还参与其他重要事项，如范围变更审批、阶段末评审，以及当风险 很大时的继续不
19、继续决定。项目组合经理项目组合评审委员会。项目组合经理负责对一组项目或项目集进行宏观治理，这些项目或项目集可能相关或不相关。项目组合评审委员会通常由组织中负责项目选择的高层管理人员组成。他们对每个项目的投资回报、价值、风险和其他属性进行评审。项目集经理。项目集经理负责统筹管理一组相关的项目，从而取得对单个项目分别管理所无法实现的利益和控制。项目集经理通过与各项目经理的合作，为各项目提供支持和指导。项目管理办公室。项目管理办公室（PMO）是负责对所辖各项目进行集中协调管理的一个组织部门，其职责可以涵盖从提供项目管理支持到直接管理项目。如果 PMO 对项目结果负有直接或间接的 责任，那么它就是项目
20、的一个干系人。PMO 所提供的服务包括（但不限于）： 行政支持，如提供政策、方法和模板； 培训、辅导和指导项目经理； 关于如何管理项目和使用工具的支持、指导和培训；项目间的人员协调； 项目经理、项目发起人、职能经理和其他干系人之间的集中沟通。 项目经理。项目经理是执行组织委派其实现项目目标的个人。这是一个富有挑战且备受瞩目的角色，具有重要的职责和不同的权力。项目经理要有较强的适应能力、良好的判断能力、优秀的领导能力和谈判技能，并熟练掌握项目管理知识。项目经理必须能理解项目的细节，但又能从项目全局的角度进行管理。作为对项目成功负责的个人，项目经理掌管项目的所有方面，包括（但不限于）： 制定项目管
21、理计划和所有相关的子计划； 使项目始终符合进度和预算要求； 识别、监测和应对风险； 准确、及时地报告项目指标。 项目经理在与干系人的沟通中负主要责任，尤其是与项目发起人、项 目团队和其他关键干系人的沟通。项目经理对促进干系人与项目之间的互 动起核心作用。项目团队。项目团队由项目经理、项目管理团队和其他执行项目工作、但无须参与项目管理的团队成员组成。团队中的个人来自不同的团体，分别掌握某些具体的专业知识或技能，并执行项目工作。职能经理。职能经理是在企业的行政或职能领域（如人力资源、财务、会计或采购）承担管理角色的重要人物。他们配有固定员工，以开展持续性工作，并能全权管理所辖职能领域中的所有任务。
22、职 能经理可为项目提供相关领域的专业技术或服务。运营经理。运营经理是在核心业务领域（如研发、设计、制造、供应、测试或维护）承担管理角色的个人。不同于职能经理，运营经理直接管理供销售的产品或服务的生产和维护。基于项目的类型，在项目完成时，需要把项目的技术文件和其他永久性记录正式移交给相关的运营管理人员。然后，运营管理人员再把所移交的项目纳入日常运营中，并为之提供长期支持。卖方业务伙伴。卖方，又称为供应商、供方或承包方，是根据合同协议为项目提供组件或服务的外部公司。业务伙伴也是外部公司，但他们与本企业间存在特殊的关系。这种特殊关系可能是通过某个认证过程建立的。业务伙伴为项目提供专业技术，或提供安装
23、、定制、培训或支持等特定服务。 2.4 组织对项目管理的影响 组织文化、风格和结构会对项目实施产生影响。组织的项目管理成熟度及其项目管理系统也会影响项目。与外部企业合资或合伙的项目，会受到不止一家企业的影响。本节下文将介绍可能对项目产生影响的组织特征和结构。 2.4.1 组织文化与风格 文化与风格可能对项目实现目标的能力产生强烈影响。文化与风格通常被称为“文化规范”。这里的“规范”包括一些共同的认识。例如，如何完成工作、哪些工作方式是可接受的，以及谁能有力推动工作的完成。大多数组织都形成了自己独特的文化，其表现形式包括（但不限于）： 共同的愿景、价值观、行为规范、信念和期望；政策、方法和程序；
24、对职权的看法； 工作伦理和工作时间。 组织文化是一种事业环境因素。因此，项目经理应该了解 可能对项目造成影响的不同的组织风格和文化。例如，在某些情况下，位 于组织结构图顶层的那个人其实并不掌握实权。项目经理必须了解谁才是 组织真正的决策者，并通过与其合作来争取项目成功。 2.4.2 组织结构 组织结构是一种事业环境因素，它可能影响资源的可用性，并影响项目的管理模式。组织结 的各种矩阵型结构。表 2-1 列出了几种主要组织结构及其与项目有关的重 要特征。 如图 2-8 至图 2-10 所示，矩阵型组织兼具职能型组织和项目型组织的特征。弱矩阵型组织保留了职能型组织的大部分特征，其项目经理的角色更像
25、是协调员或联络员，而非真正的项目经理。强矩阵型组织则具有项目型组织的许多特征，拥有掌握较大职权的全职项目经理和全职的项目行政人员。平衡矩阵型组织虽然承认全职项目经理的必要性，但并未授权其全 权管理项目和项目资金。表 2-1 介绍了各种矩阵型组织结构的更多细节。与职能型组织相反的是项目型组织，如图 2-11 所示。在项目型组织中，团队成员通常集中办公，组织的大部分资源都用于项目工作，项目经理拥有很大的自主性和职权。项目型组织中也有被称为“部门”的组织单元，但这些部门或者直接向项目经理报告，或者为各个项目提供支持服务。 图 2-12 复合型组织 很多组织都会在不同层次用到上述所有结构，如图 2-1
26、2 所示。例如，即使那些典型的职能型组织，也有可能建立专门的项目团队，来实施重要的项目。该团队可能具备项目型组织中项目团队的许多特征。它可能拥有来自各职能部门的全职人员，可以制定自己的办事流程，甚至 可以不按标准或正式的汇报结构运作。 2.4.3 组织过程资产 组织过程资产包括任何或全部与过程相关的资产，可来自任一或所有参与项目的组织，用于帮助项目成功。这些过程资产包括正式和非正式的计划、政策、程序和指南。过程资产还包括组织的知识库，如经验教训和历史信息。组织过程资产可能包括完整的进度计划、风险数据和挣值数据。 项目团队成员通常有责任在项目全过程中对组织过程资产进行必要的更新 和补充。组织过程
27、资产可分成以下两大类。 1流程与程序 组织的工作流程与程序，包括（但不限于）： 组织的标准流程，例如，标准、政策（如安全与健康政策、伦理政策和项目管理政策）、标准的产品与项目生命周期，以及质量政策与程序（如过程审计、改进目标、核对表和组织所使用的标准化的流程定义）； 标准化的指南、工作指示、建议书评价准则和绩效测量准则；模板（如风险模板、工作分解结构模板、项目进度网络图模板以及合同模板）； 根据项目的具体需要，“剪裁”组织标准流程的指南与准则； 组织对沟通的规定（如具体可用的沟通技术、许可的沟通媒介、记录保存政策以及安全要求）； 项目收尾指南或要求（如项目终期审计、项目评价、产品确认以及验收标
28、准）； 财务控制程序（如定期报告、费用与支付审查、会计编码以及标准合同条款）； 问题与缺陷管理程序，包括对问题与缺陷的控制、识别与处理，以及对相关行动的跟踪； 变更控制程序，包括修改公司标准、政策、计划和程序（或任何项目文件）所需遵循的步骤，以及如何批准和确认变更。 风险控制程序，包括风险的类别、概率的定义和风险的后果，以及概率影响矩阵； 排序、批准与签发工作授权的程序。 2共享知识库 组织用来存取信息的共享知识库，包括（但不限于）： 过程测量数据库，用来收集与提供过程和产品的测量数据； 项目档案（如范围、成本、进度与质量基准，绩效测量基准，项目日历，项目进度网络图，风险登记册，风险应对计划和
29、风险影响评价）； 历史信息与经验教训知识库（如项目记录与文件、完整的项目收尾信息与文件、关于以往项目选择决策与绩效的信息，以及关于风险 管理工作的信息）； 问题与缺陷管理数据库，包括问题与缺陷的状态、控制情况、解决方案，以及相关行动的结果； 配置管理知识库，包括公司标准、政策、程序和项目文件的各种版本与基准； 财务数据库，包括工时、实际成本、预算和任何成本超支等信息。 Chapter 2 Project Life Cycle and Organization Projects and project management take place in an environment that is
30、 broader than that of the project itself. The project management team must understand this broader context to ensure work is carried out in alignment with the goals of the enterprise, and managed in accordance with the established practices of the organization. This chapter describes the basic struc
31、ture of a project as well as other important high-level considerations including how projects impact ongoing operational work, the influence of stakeholders beyond the immediate project team, and how organizational structure affects the way the project is staffed, managed, and executed. The followin
32、g major sections are discussed: 2.1 The Project Life Cycle - Overview 2.2 Projects vs. Operational Work 2.3 Stakeholders 2.4 Organizational Influences on Project Management 2.1 The Project Life Cycle - Overview A project life cycle is a collection of generally sequential project phases whose name an
33、d number are determined by the control needs of the organization or organizations involved in the project. A life cycle can be documented with a methodology. While every project has a definite start and a definite end, the specific deliverables and activities that take place in between will vary wid
34、ely from project to project. The life cycle provides the basic framework for managing the project, regardless of the specific work involved. 2.1.1 Characteristics of the Project Life Cycle Projects can vary in size and complexity from a simple project to a more elaborate and complex endeavor, such a
35、s designing and producing a new aircraft. No matter how large or small, simple or complex, all projects can be mapped to the following generic life cycle structure (see Figure 2-1): Starting the project, Organizing and preparing, Carrying out the project work, and Finishing the project. This generic
36、 life cycle structure is often referred to when communicating with upper management or other entities less familiar with the details of the project. This high-level view can provide a common frame of reference for comparing projects-even if they are dissimilar in nature. The generic life cycle struc
37、ture generally consists of the following characteristics: Cost and staffing levels are low at the start, peak as the work is carried out, and drop rapidly as the project draws to a close. The dashed line in Figure 2-1 illustrates this typical pattern. Figure 2-2 illustrates that the level of uncerta
38、inty and the risk of failing to achieve the project objectives are greatest at the start of the project. Uncertainty and overall project risk decrease over the life of the project. Ability to influence the final characteristics of the projects product, without significantly impacting cost, is highes
39、t at the start of the project and decreases as the project progresses towards completion. Figure 2-2 illustrates the idea that the cost of changes and correcting errors typically increases substantially as the project approaches completion. Figure 2-1. Typical Cost and Staffing Levels Across the Pro
40、ject Life Cycle Figure 2-2. Stakeholder Influence Over Time Within the context of the generic life cycle structure, a project manager may determine the need for more effective control over certain high-level work deliverables. Large and complex projects in particular may require this additional leve
41、l of control. In such instances, the work carried out to complete the projects objective may benefit from being divided into phases. 2.1.2 Relationship to a Products Life Cycle Product life cycle is a collection of generally sequential, non-overlapping product phases whose name and number are determ
42、ined by the manufacturing and control need of the organization. The last product life cycle phase for a product is generally the products retirement. Generally, a project life cycle is contained within one or more product life cycles. Care should be taken to distinguish the project life cycle from t
43、he product life cycle. All projects have a purpose or objective, but in those cases where the objective is a service or result, there may be no product life cycle involved. When the output of the project is related to a product, there are many possible relationships. For instance, the development of
44、 a new product could be a project on its own. Alternatively, an existing product might benefit from a project to add new functions or features, or a project might be created to develop a new model. Many facets of the product life cycle lend themselves to being run as small projects, for example: per
45、forming a feasibility study, conducting market research, running an advertising campaign, installing a product, holding focus groups, trialing a product in a test market, etc. In each of these examples the project life cycle would differ from the product life cycle. Since one product may have many p
46、rojects associated with it, additional efficiencies may be gained by managing all related projects collectively. For instance, a number of separate projects may be related to the development of a new automobile. Each project may be distinct, but still contributes a key deliverable necessary to bring
47、 the automobile to market. Oversight of all projects by a higher authority could significantly increase the likelihood of success. Managing a group of projects in a coordinated way, to obtain benefits not available from managing them separately, is within the scope of program management. 2.1.3 Project Phases Project phases are a collection of logically related project activities, usually
