项目管理基础知识-ams

项目管理基础知识-ams内容摘要：

” 为基本运作单位的 IT 服务公司来说，目标是 “ 客户满意、公司获利 ” ，而项目管理是达成这个目标的重要因素。 项目成功应该在开始前 “ 了解什么是客户的成功 ” ；执行中 “ 担负客户成功的责任 ” ，结束后 “ 帮助客户实现价值 ”。 项目执行中的管理要素包括工作范围、时间、质量、成本，这四者相互制约，我们只能作出权衡。 项目成功的另一个重要要素是 “人 ”。 在 IT 服务项目中，人力成本的控制 决定公司赢利能力。 很少有项目是由于技术上的原因失败，而是由于 “人 ”未能确定正确目标，未对目标达成一致；项目 “承担者 ”需要必要的能力获得组织的支持，推动项目的进程；团队建设对项目意义重大，需要专家之间良好协作项目才能成功。 项目管理概述 概述 课程将从 6 个部分进行讨论。  结合 IT 项目的基本特点，谈谈项目 管理的重要意义（ Why）。  成功的项目在实施过程中要重点控制哪些要素（ What）；  如何从目标、过程和人员三个层面对项目进行管理（ Where）；  通过剖析一个典型系统集成项目的生命周期，说明应该在什么时候对项目进行什么样的控制（ When）；  项目的组织结构，包括项目中的角色和职责、项目的组织方式、项目经理和团队等内容（ Who）；  从一个项目的立项到结束的全过程中对各种管理要素进行控制的具体过程，包括计划和预算、变更和风险控制、 TQC（进度、质量、成本）控制等内容，并会 介绍一些实用的方法和工具（ How）。 这是本文的重点内容。 IT 项目特点及其指导意义 什么是项目。 对项目比较具体一些的解释是 “ 用有限的资源、有限的时间为特定客户完成特定目标的阶段性工作 ”。 这里的资源指完成项目所需要的人、财、物；时间指项目有明确的开始和结束时间；客户指提供资金、确定需求并拥有项目成果的组织或个人；目标则是满足要求的产品和服务，并且有时它们是不可见的。 一般 IT 服务厂商所说的项目是指承接的外部客户的项目，例如系统集成厂商为客户定制解决方案，负责硬件安装、应用开发、维护服务等。 但目前越来越多 的企业将内部的组织调整、流程变革也作为项目的来运作，不过这类项目不在我们的讨论范畴之内。 与公司的运作（ Operation ）的不同，项目具有非常明显的特点：独特性、阶段性和不确定性。 下面分别讨论一下这些特点含义和对实际工作的指导意义。 独特性 “ 没有完全一样的项目 ”。 项目的独特性在 IT服务领域表现得非常突出，厂商不仅向客户提供产品，更重要是根据其要求提供不同的解决方案。 即使有现成的解决方案，也需要根据客户的特殊要求进行一定的客户化工作，因此可以说每个项目都有区别。 项目的这种独特性对实际管理项目有非常 重要的指导意义： 签定明确的合同 “ 没有完全一样的项目 ” ，所以预期的 “ 产品或服务 ” 在项目完成之前是不可见的，这与普通的商品买卖非常不同。 为了解决这个问题，必须在项目开始前通过合同（或等同文件）明确地描述或定义最终的产品是什么。 如果刚开始要提供什么没能定义清楚，或未达成一致，则最终交付产品或服务时将很容易发生纠纷，造成不必要的商务和名誉损失。 因此某种程度上说，在签合同时已经决定了项目成败。 控制项目的变更 因为项目的产品或服务事先不可见，在项目前期只能粗略进行项目定义，随着项目的进行才能逐渐完善和精确，这 也称为项目的渐进性。 在这个逐渐明晰的过程中一定会进行很多修改，产生很多变更。 因此，在项目执行过程中要注意对变更的控制，特别是要确保在细化过程中尽量不要改变工作范围，否则项目可能改来改去，永远做不完。 阶段性 项目的阶段性决定了项目的历时有限，具有明确的起点或终点，当实现了目标或被迫终止时项目即结束。 有的项目时间甚至是决定性因素，例如解决 “ 千年虫 ” 的项目。 项目的阶段性对实际的指导意义是： 强调时间观念 在开始一个项目前，就必须明白项目的时间约束；具体到每个人、执行项目中的每一个任务都必须明确时间要求。 可 能项目中最常听到的一句话是 “ 要什么时候完成。 ” 团队建设意义重大 项目阶段性使得项目团队都是临时的组织，一般在项目开始时组成跨专业项目小组，结束后小组即解散，在项目执行的过程中成员还可能会发生变化。 因此如何将成员快速组成一个有效的团队对项目的成败意义重大，特别使一些项目周期较短项目，如果团队成员短期内不能融洽合作，甚至内部分裂，则可能直接造成项目的失败。 可以毫不夸张地说：优秀的团队效益显著，而团队分裂是项目巨大的风险。 不确定性 是指项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。 这是因为 ，项目计划和预算本质上是基于对未来的 “ 估计 ” 和 “ 假设 ” 进行的预测，在执行过程中与实际情况难免有差异；另外，在执行过程中还会遇到各种始料未及的 “ 风险 ” 和 “ 意外 ” ，使得项目不能按计划运行。 因此，在项目管理中还要注意： 制定切实的计划 在实际工作中发现，制定计划有两种倾向，一种是不计划，一些项目经理认为反正 “ 计划跟不上变化，索性不要计划 ”。 另一种倾向则是过度计划，必须将项目中非常微小的事情都考虑清楚才动手，但如此 “ 详细的计划 ” 其实是在试图精确地预测未来，也是不切实际的，在执行中会发现难以与实际一致，而不得不频 繁地进行调整。 这两种倾向都导致了制定的计划不切实。 具体问题具体分析 尽管有项目计划，执行过程中仍会碰到各种各样意想不到的问题，且往往没有现成的处理方法，这就要求项目经理必须掌握必要的工具方法，抓住整体过程和控制要素，在一些基本原则的指导下对问题进行具体分析，根据实际情况灵活应对。 因此，项目管理不应照搬照套固定流程或模式。 综上所述，项目就是要完成的一些 “时间有限 ”、又 “没有经验 ”“没有把握 ” 的事。 项目管理没有公式化的操作流程，其重点是共性的管理框架和一般原则，以及一些具体的方法和工具。 项目管理 过程 项目由多个过程构成，一般认为过程是 “ 产生结果的一系列行为 ” （参见 PMBOK2020— PMI）。 过程基本可以分成两类：一类是项目管理过程，描述了如何组织、规划和完成项目的各项工作；如果抛开 “ 工作 ” 之间的具体差异，将工作作为 “ 任务 ” 看待，则项目管理过程可以适用于各种领域和各种类型的项目。 另一类是产品过程，描述了如何获得或创造项目的产品，产品过程与项目的行业、类型和方法论有密切的关系。 本文主要讨论项目管理过程。 按 PMI 的定义，项目管理过程分成启动、计划、执行、控制和结束 5个过程组： ★ 启动：确 认和批准一个项目（或项目的一个阶段）的执行； ★ 计划：界定项目目标，确定实现目标的工作方案； ★ 执行：组织人力、协调其他资源以执行计划； ★ 控制：监控项目的实际进展与计划的偏差，并采取必要的纠正措施以确保目标的实现； ★ 结束：整理和移交项目成果，确保项目有序结束。 上述的 5个过程组中，每个又可以分成一个或多个管理过程。 从本期开始，我们将结合 IT 项目的实践讨论项目管理的一些重要的管理过程。 启动和目标定义 项目的启动是指承担项目的组织或个人承诺开始一个项目。 从商务角度来看，最典 型的承诺方式就是《合同》。 《合同》明确承诺项目要达到的目标，也就是项目的预期结果或最终产品。 一般来说，项目目标至少包括以下几个要素： ★ 工作范围：要做哪些事。 ★ 进度计划：多长时间完成。 ★ 预算成本：需要多少成本。 ★ 质量标准：达到什么要求。 这里要强调的是：目标一定要明确具体（ SMART 原则），不能与方针或策略混为一谈。 例如 “ 我们要到一个美丽的海岛去旅游。 ” 就只是一种方略，而不能作为一个目标。 因为 “ 美丽 ” 无法度量，什么时间去也没有说清楚。 如果作为目标定义你可以说： “ 我们要在 2020 年 8月前到海南岛玩 10天，每人最多花 5000 元。 当然前提是发 1万元年终奖 ”。 这个目标就非常明确、具体、可操作、可测量。 值得注意的是其中还定义了项目的终止条件，实际上这也是在很多合同中可能提及的内容。 理想情况是项目开始时就应该有一个明确的目标，但现实工作中，特别是 IT行业中则难以做到。 一种情况是项目开始往往不十分清楚需要什么，在项目中才逐渐明确；第二种情况是项目过程中目标常常会发生改动，不得不经常进行变更甚至返工。 为此，项目在启动前中要注意把握以下几个原则： 与其事后花时间打官司，不如签合同前费点功夫讲清楚 ； 宁可事前消除客户不切实际的 “ 期望 ” ，也不要事后让客户 “ 希望破灭 ” ； 不光要承诺完成什么工作任务，还要讲明约束条件和验收标准； 项目中的过程文档要完整保留；与约定不同的所有变更都要经双方确认并详细记录。 由于 “ 项目 ” 的产品提前不可见，因此项目的商务过程比普通商品买卖要复杂一些。 因此，项目合同也要复杂一些，还可能需要其他文档进行额外的说明。 这里简单介绍一下软件开发项目所使用的一种说明性文档 — 《工作说明书》。 《工作说明书》中详细定义项目的工作范围、交付产品、前提条件、验收标准和流程、进度计划、组织结构 、双方职责、变更流程等多种条款，下面一一进行说明： 前言。 介绍编写《工作说明书》的主要内容、编写目的、适用范围和效力、生效和终止的条件和日期等内容。 项目概述。 说明项目要实现的主要业务功能；项目与现行系统和其他系统的关系；目标系统的硬件和软件结构。 工作范围。 包括项目需要完成的工作、项目不包含的工作，还可能界定项目与外部的接口关系和接口方式。 主要交付物。 定义各项工作产出交付物的名称、介质形式和产出时点；同时描述交付物应该满足的格式和内容的质量要求。 前提条件。 定义项目工作所必须依赖但承约方无法控 制或不承担责任的工作。 比如客户自己采购设备，则设备按期到货是项目能按期完成的一个前提条件。 验收标准和流程。 定义交付物的验收条件、流程以及双方在验收过程中的职责；可以明确规定按要求提交交付物后多少工作日内客户应该验收。 实施进度。 项目大的阶段点和各阶段内细化的工作；工作的完成要以交付物或其他容易测量的标志作为界定依据。 组织结构。 定义项目的组织结构以及各个角色的责任，还可以明确说明项目中的沟通和决策机制。 双方职责。 对与双方需要配合完成的工作（如需求分析），要明确说明双方各自承担的工作内容和担负的责 任。 变更流程。 明确规定项目发生变更时的处理流程，并对照组织结构声明最高的决策机构；最好在项目开始前对客户进行必要的培训。 版权及保密。 声明最终产品的版权，资料的保密级别、保密期限等事项。 《工作说明书》可以作为合同的一个附件使用，具有同等的法律效力。 配合《工作说明书》中里程碑的定义，也可以在合同中规定各个里程碑的收款比例，避免项目最后发生重大变化而 “ 血本无归 ”。 实际上，与客户讨论和确认《工作说明书》确实比较费时间；但实际经验表明，早期的这项投入是非常值得的，特别是在与客户发生了分歧时更显重要。 综上所 述，项目启动前一定要有明确的承诺； IT 服务项目可以用《工作说明书》定义工作的内容和要求，这对避免事后纠纷有重要的作用。 项目管理过程 (续 ) 项目计划和预算（一） 上期我们讨论了如何定义清楚项目的目标，这期开始讨论目标确定后如何制定计划和预算。 因为项目具有唯一性，决定了项目中必然有我们从未做过的事情，所以项目的首要任务就是 “ 计划、计划、计划 ”。 强调计划的重要性并非说明项目管理的主要任务就是编制计划，而是指计划是一项贯穿于整个项目生命周期的持续不断的过程，实际工作中恰恰要注意计划的详细程度与 项目的实际规模匹配。 项目计划包括主计划和辅助计划。 主计划的编制有清晰的步骤，大多数项目都可以按相同的顺序进行，一般包括范围定义、活动定义、活动估算、活动排序（网络分析）、进度计划、资源计划、成本估算和成本预算等步骤。 辅计划的编制则可以陆续或单独进行，与具体项目的特点也有比较密切的联系。 辅助计划包括质量计划、组织计划、沟通计划、风险管理计划、变更控制计划等。 本期讨论主计划的范围和活动定义部分，后面将陆续介绍活动估算和网络分析以及进度 /资源计划、项目预算等内容。 讨论的重点不是具体的过程，而是一些实用的工 具和方法，通过介绍工具的使用方法贯穿制定计划的过程。 范围和活动定义 项目计划的第一步是项目范围定义，进而定义项目需要进行的活动、角色、责任以及项目组的结构。 范围定义一般使用 WBS（ Work Breakdown Structure）。 WBS 将项目的 “ 交付物 ” 自顶向下逐层分解成易于管理的若干元素（这些元素组成一个树型图），因此结构化地组织和定义了项目的工作范围。 WBS 每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最低层的工作细目（树型图的叶节点）叫工作包。 为了方便分层统计 和识别， WBS 中的每个元素都被指定一个唯一的标识符，并分层表示。 WBS 是项目管理的起点，但 WBS 没有固定的分解方法，也没有唯一正确的答案，甚至需要分解到什么层次也没有统一的规定。 这里根据笔者的经验提供 IT 领域 WBS 分解的几个参考原则： ★ 可以将项目生命周期的各个阶段做为第一层，将每个阶段的交付物作为第二层；如果有的交付物组成复杂，则将交付。