项目管理知识体系中的九大知识领域.doc

项目管理知识体系中的九大知识领域九大知识领域，是项目管理知识体系的重要内容，涉及内容非常广泛，在这里将会把各个知识领域中的重要管理内容和关键点作一介绍，如需了解更为具体的内容，请参考PMBOK以及相关的专业论著。1.4.1集成管理集成管理是项目管理九大知识领域中的第一个领域，与其它八个知识领域相比，这个领域的内容比较特殊，它并没有提供具体的知识点和具体的操作方法，而是反复强调围绕项目的全局观，在项目内部各个部分之间、在项目内部与外部之间，对各种内容进行集成，使各个相关方面形成有机的整体，保持管理上的一致性。这个知识领域的内容对于项目经理们来说也许感觉比较空泛，但对于公司级项目管理体系建设来说，则是非常具有指导意义的。下面是项目管理中几个常见的集成方面的问题：1、将项目计划中各个管理领域的子计划综合而成整体的项目计划。例如在整体项目计划中，要涉及范围管理计划、时间管理计划、成本管理计划、质量管理计划、人力资源计划、沟通计划、风险管理计划、采购计划等，将这些不同的管理计划有机的结合起来，使整体项目计划可以有效涵盖项目管理的各个领域的管理内容并保持一致.2、将项目的各个过程有机的集成起来。在后面我们会提到项目的五大过程启动、计划、执行、控制、收尾。这些过程在整个项目当中，在项目的各个阶段当中，都可以根据管理的需要灵活运用，但是各个过程之间的关系仍然要符合基本的关系规定，这五大过程之间的关系会在后面的章节中进行介绍。3、项目管理与公司平常运营管理的集成。不管公司是以项目方式从事主营业务，还是运用项目从事改革、创新，都存在着项目与公司平常运营之间的关系。在项目过程中通常会占用公司资源，也会对公司的平常工作产生一定的影响，如何协调资源、配合工作，同时满足两方面的需要，这就是经常碰到的一种集成管理的规定。例如在创新活动中，项目会产出成果，也许形成面向内部用户或外部客户的产品，公司就要考虑围绕这些产品的销售、支持服务等一系列的公司运营中的问题，因此，公司往往在项目初期定义项目成果时，就规定考虑项目成果在以后的公司运营中的管理问题。4、项目生命周期与产品生命周期的集成。公司管理的核心内容都是围绕产品的（涉及服务型产品），公司一定会对产品的生命周期进行管理，在产品的整个生命周期当中，产品的每一次进步，都是以项目的方式来实现的，从市场调研、可行性分析、产品设计、产品生产、市场促销、产品改善等各个不同的阶段，都可以单独成为项目。这时的项目的生命周期包含在产品的生命周期当中，项目的成果成为产品发展的阶段成果。因此，在项目管理中，还要同时兼顾产品长远发展的需要。5、项目范围与产品范围的集成。当一个产品由不同的部分组成时，每个部分都可以单独生产时，就一定存在着项目范围与产品范围集成的规定。例如在汽车装配厂，需要从许多不同的加工厂采购不同的零部件来进行装配，对于零部件加工厂来说，设计、改善零部件的创新项目，不能孤立的对待，而是要考虑该零部件与其它相关部分的配合关系，考虑对整车的影响。假如把整车涉及的所有零部件看作是产品范围，针对某个零部件的改善就是单个项目的项目范围，那么项目范围就应当与产品范围进行有效的集成。6、不同部门的成果的集成。当一个项目涉及公司内外多个部门和单位时，特别是当项目在公司中处在职能式或弱矩阵式组织结构时，通常会出现各个部门分头完毕自己所分管部分的任务，将各自的成果提交给项目，那么在项目中就必须将这些成果集成在一起，形成项目的整体成果。7、项目中不同约束条件的集成。不同的利益干系人也许会对项目提出不同规定，各种各样的外部因素会对项目形成不同的约束条件，例如外部法规的强制性规定、公司内部的管理规定、不同领导和部门的限制性规定、内部资源自身的特殊规定、项目发起者对项目自身的相关规定等，为项目管理勾画出了项目的边界，这个边界就直接反映出各个方面的约束条件的集成结果。尚有许多其它方面的集成问题，这里不能一一列举。由此可以看出，项目并不是孤立存在的，它受到来自项目内部和外部的多方面的影响，要管理好项目，就必须有很强的全局观。因此，在公司级项目管理体系建设中，就要尽也许将这些问题，通过公司级的项目管理制度加以明确并使之相对稳定，加强对各个具体项目的指导和监督。1.4.2 范围管理项目的范围管理，是针对项目交付成果的，通过对项目交付成果的计划、跟踪、控制和获取，保证项目中的所有活动始终是围绕所规定的项目成果开展的，并且保证所有的应交付成果都已完毕。可以说，范围管理是具体描述项目目的的。在范围管理中最重要的一项内容，就是范围定义，就是对所规定的项目成果进行分解、细化，这样做的目地有三方面：1，提高估算时间、资源、成本的准确限度。2，定义衡量和控制项目绩效的基线。3，明确职责分派。将所规定的项目成果一层一层的细分，就形成了工作分解结构，简称WBS(Work Breakdown Structure)，它是范围定义的重要输出结果。“工作分解结构”包含了三个含义：工作：是针对成果的，而不是面向过程的；分解：对成果进行细分，直到可以满足管理的规定为止；结构：成果被分解以后，每一小块内容并非是孤立的，而是有着内在的关联关系，这种互相之间的关系，是结构化的。WBS中所分解出来的各个组成部分，就形成了项目的子成果，以后所有的项目活动都应当是针对如何实现这些子成果的，而不应当存在与项目目的无关的项目活动。同时，所有的子成果都被完毕，是项目整体成果被完毕的必要条件。也就是说，通过细化分析项目成果所包含的各个组成部分，使项目的各项行动都有了具体的目的。正是由于项目范围是针对项目成果的，项目的成果就是产品或服务，所以项目范围往往与产品工艺特性（把服务视为无形产品）有着紧密的关系，需要有丰富的专业领域知识才可以做好。明确项目目的所规定的交付成果，需要辨析有形产品和无形产品的区别，这一点非常重要的。WBS是面向交付成果的。在制定WBS时，当交付成果是有形产品时，比较容易辨认交付物，由于交付物的确都可以是可见的、可验证的，并且交付物都可以表达成为名词的形式。但是当交付成果是无形产品时，往往会带来混乱。无形产品的制造和交付过程是同时的，甚至有些成果与制造过程的行动是一一相应的，所以在表达交付成果时，就难以与制造过程彻底划清界线，经常会用无形产品的制造过程的行动动词来表达交付成果，结果将交付成果与项目活动混在一起，例如在WBS中不是用“歌曲1”、“歌曲2”这样的名词来表达范围的内容，而是用“演唱歌曲1”、“演唱歌曲2”这样的动词来表达，虽然这样写大家也都能理解，但是却混淆了WBS的标准，也许会导致将项目行动也写入WBS，作为项目范围进行管理，结果给项目管理带来麻烦。项目范围和项目活动之间的差别应当是大家早已熟知的，这里不再赘述。因此，对于项目交付成果，无论是产品还是服务，在WBS中都应当使用名词，而不要使用动词，即使像做广播体操这样一个强调过程体验的“项目”，在WBS中也应当使用各个动作的名称，而不是使用做这些动作的动词。另一方面，有些项目经理是用“可见的、可验证的”作为辨认交付成果的依据，对于这一点也不能过于机械，特别是当项目的交付成果是无形产品时，这种判断标准有时就会产生误导。一方面，由于无形产品随着过程结束也会消失，所以其可验证的标准经常会不能满足。有人说，可以形成文档记录或者录像，这不就是可验证的了吗？这种做法固然满足了可验证的规定，但是假如简朴的把文档记录作为交付成果，就也许从主线上偏离了项目目的，由于大家来听音乐会，希望得到的是音乐家的高超技艺给听众带来的享受，而主线不关心什么文档记录，项目是否成功，大家对成果的满意度不是来自苍白的文档，而是来自生动的过程，即使将文档记录作为必须的验证证据列入交付物，也不能代替主线的交付成果。在另一方面，项目中可见、可验证的东西不一定都是项目所需要的交付成果，例如，当我们要乘火车去某地的时候，其目的是人要到达目的地，而非提交一张“可见、可验证”的火车票。因此，对于交付成果的“可见、可验证”的特性，需要针对具体项目目的的规定，根据项目交付成果是属于有形产品还是无形产品来区别对待，即使在交付无形产品时使用一些辅助手段来满足大家早已习惯的“可见、可验证”的标准，也一定不要忘掉项目的主线目的是什么，最重要的交付成果是什么。运用所形成的WBS，在项目接近完毕时，就可以执行项目范围确认的工作，以保证项目成果至少在内容、数量上满足了当初的范围规定，然后才是对每个具体内容的质量的检查。下面的例子是一个组装个人计算机的工作分解结构的示例，它只需要说明一台台式计算机需要由哪些部分组成，但并不需要说明它是如何组装起来的。组装者只要按规定将上述部件都组装好，就可以认为是完毕了工作。当用户在验收时，只要按照这个WBS来逐个核对，就可以比较容易的对计算配置的完整性作出确认。WBS分解到多细、分解出多少层，这方面没有固定的标准。在上面这个例子中，假如组装者希望自己分别选择不同的机箱和电源，而不是选择已经组装好的，那么这个WBS中就还要将“机箱和电源”这一个节点继续向下分解出“机箱”、“电源”两个节点。需要反复强调的是，范围管理是针对成果的，而不是面向过程的，只是说明项目要实现的成果是如何组成的，而不说明如何实现的过程。因此，WBS中所包含的内容，都是项目成果的组成部分，反映着项目目的的规定，而项目目的不是项目内部自己给自己定义的，是从项目外部设定的，所以WBS中的内容，对于项目来说，是必须完毕的来自外部的规定，不可以在项目内部随意更改。假如项目范围需要进行调整，一定需要外部的项目目的提出者进行确认。同时，项目的成果并非单纯指项目的客户所规定的成果，同时还应涉及各种项目干系人所规定的项目管理的成果，例如一些公司内部有相应的项目跟踪机制，规定项目在规定的时间提交相应的报告，项目过程中形成的各种项目管理文档，也必须被视为项目的交付成果，列入WBS当中，并在项目计划中为此安排任务资源及成本。上面的组装计算机的例子是一个比较简朴的项目，没有很苛刻的项目管理成果规定，但在很多规范的项目中，都会在WBS中单独列出一个项目管理分支，将所规定的管理工作放在其中，例如项目周报、评审报告、里程碑报告等。项目范围是对项目目的的具体细化，是项目中各项活动存在的前提条件，是项目资源需求和成本预算的依据，是整个项目管理的基础。所以说，对的的范围定义是项目成功的基础。假如项目范围发生变更了，必然要导致项目计划中的进度、资源、成本的全面调整，对项目的影响是非常大的。在后面具体介绍项目计划过程时，我们可以更加清楚的看到项目范围对其它各方面因素的重要影响。因此，所有项目，都会将项目范围控制作为一项非常重要的项目管理工作内容，对于项目范围变更是非常谨慎的。例如，在软件开发项目中，我们可以将需求分析的工作视作项目范围定义的工作，通过需求分析，对于所要开发的软件的结构、功能进行分解，形成了一个个具体的功能需求，所有这些功能需求共同组成了整体软件的功能，当所有这些功能都被一一实现了，也就意味着软件的整体功能也被实现了。但是假如软件需求发生变更了，那么后续所有的设计、编码工作都也许要随之调整，甚至也许导致结构的调整，直接影响到了项目的各方面工作。同样的项目范围，在项目的不同阶段，出于不同目地，对项目范围的描述也可以是不同的。例如搞居室装修，在设计阶段，设计人员会一方面按照居室、客厅、厨房和卫生间的方式来划分，然后对每一部份描述其墙面、地板、门窗的装修方式，这样比较利于理解装修效果，而在施工阶段，施工人员会一方面按照墙面、地面、门窗等划分工作内容，然后再对每一部份描述不同房间的特别规定，这样比较适合施工的思绪，容易理解施工的工序，铺地板的会一次把各个房间的地板都铺好，装灯具的通常会在最后一次性把各处的所有灯具都安装到位。因此，项目范围虽然反映的是目的，不是过程，但是其不同的分解方式，将会对后续的过程产生影响。所以项目范围的划分也应基于对项目工艺过程的基本理解。在公司级项目管理体系中，公司就需要认真研究各种项目的重要交付物，结合自身的生产工艺特点，对交付物进行仔细的定义，直接指导和规范各个项目的范围管理，做好项目范围变更控制，提高各项目经理的管理水平，提高项目管理的质量。1.4.3 时间管理为了可以完毕和交付WBS中所规定的各个项目成果，在项目中必须要采用相应的行动。因此，WBS帮助项目活动定义了具体的目的，而项目活动则是实现这些具体目的的行动过程。项目活动与WBS的这种相应关系，保证了所有的项目活动都具有针对性，都是为了项目目的服务的，从而避免项目活动的盲目性产生的资源浪费。另一方面，WBS中所有的项目成果都应当有相应的项目活动来支持，以保证项目范围不被漏掉。假如将所有的项目活动与WBS中的具体成果连接起来，就会看出项目活动是对WBS的进一步扩展，将WBS这样一个树形分解结构扩展到了相应的项目活动。但是项目活动与项目范围有着本质的区别，一定不能混同起来。前面已经反复强调，项目范围是对项目目的的细化，是来自项目外部的规定，而项目活动则是根据项目内外的各种条件，由项目经理及其项目成员所决定的。对于同一范围规定，完全可以选择不同的实行过程，允许通过不同的项目活动来实现。范围是目的，活动是手段。在这个问题上经常容易出现的错误，就是将活动也当作了范围，把手段错当成了目的，使得项目经理在面对复杂多变的项目环境时，不能及时、灵活的采用不同的项目活动、运用不同的手段来完毕项目目的。同时，另一方面的错误有时也会存在，就是有时会模糊了项目范围的边界和内容，过于随意的单方面更改项目范围，这种情况相对较少，但是一旦发生，就会给项目带来非常严重的后果。项目的时间管理，直接关系到项目的进度、资源的时间安排等最基本的管理内容。项目的时间管理是围绕项目活动的，项目活动的时间规定，决定了项目整体的时间进度安排，项目活动是时间管理的基础内容。在此基础上，在项目计划过程中要形成时间进度表，在项目执行和控制过程当中，要对时间进度进行跟踪和控制。对时间进度表的管理，是时间管理的集中表现。我们下面重要来说明一下时间进度表的相关因素：1，根据WBS，列出所需的项目活动列表，要保证WBS中所有内容最终都有相应的项目活动，同时不应存在多余的活动。2，为这些活动建立依赖关系。依赖关系的产生，一方面是由产品特性决定的，例如在房屋建设中，一方面要打地基，然后才干是地上建筑，另一方面是公司管理和项目管理的需要，例如项目方案必须通过专家评审通过后，才干进行下一步的工作。这种具有强制性的依赖关系，被称为项目活动之间的硬逻辑。而对于其它的项目活动，就可以根据一般的工作习惯来安排先后顺序。项目活动之间一般存在四种依赖关系：前一任务结束、后一任务才干开始（FS），这是最常见的顺序执行的关系；前一任务结束、后一任务才干结束（FF）；前一任务开始、后一任务才干开始（SS）；前一任务开始，后一任务才干结束（SF）；运用上述这四种关系，在所有的项目任务中建立依赖关系，形成所谓的项目活动网络图。建立依赖关系后，就会发现此时的项目活动的分组并非保持着本来按照WBS的成果的分组。例如在项目中几个部分中都需要到异地出差现场解决问题的活动，那么就可以将这些活动组织在一起，到达异地现场时一并解决各个部分的问题。在实际当中，甚至还经常出现出差一次为不同项目提供支持的情况。这也再次反映出项目活动与项目范围的重要差异，项目活动的安排是具有很大的灵活性的。3， 活动时间间隔在拟定了项目活动之间的依赖关系后，还需要了解各个项目活动之间也许存在的间隔。这种间隔是由于一些客观因素而必须流逝掉的时间，这段时间不需要相应项目活动。例如家具刷好油漆后需要晾干的时间，领导或相关机构对一些重要事项的审批过程所需要的等待时间，这些时间不是项目组成员所能决定的，假如这些时间间隔有规律可循，例如通过技术特性指标、服务承诺、工作规范等，使得这种时间间隔相对拟定，那么项目时间进度安排也容易贯彻，否则项目进度方面就存在不可控因素，应列入项目风险进行管理。调整了活动时间间隔后，项目活动网络图就得到了更新。4， 拟定项目活动的工期。项目活动的工期决定了项目活动的时间长度，可以是天、小时，也可以是周、月，时间表中项目活动工期的单位，取决于项目管理的规定。项目活动的工期是受资源影响的，对于同一项目活动来说，在通常情况下，提供的资源越多，所需工期越短，资源的工作效率越高，所需工期越短，但也有很多情况，资源分派过多反而会效率减少、工期延长。资源管理不是时间管理这一领域的内容，我们会在后面的章节中介绍。资源与时间的关系，在后面的项目管理三角形部分还会具体说明。拟定项目中各个活动的工期后，由于各项活动之间存在的依赖关系，项目活动网络图就具有了时间长度，可以初步反映出项目的总工期。5， 日历项目管理中所说的日历重要涉及这样一些信息：日期、工作日/非工作日、每日可工作时间。在项目管理中，涉及到的日历涉及公司基准日历、项目日历和项目资源日历。在项目中一般大家都可以将普通公历日历作为基础日历，结合政府发布的法定节假日和公司特定的工作日规定，对基础日历中的工作日和非工作日进行调整，再根据公司特定的工作时间规定，具体定义日历中每个工作日和工作时间，形成了所谓的公司基准日历，所反映的是公司的基本工作时间规定。项目日历，则是在公司日历的基础上，根据项目特定的规定，为项目制定的日历，其工作日/非工作日的安排，每日工作时间，都必须根据项目的特殊规定来安排。有些项目可以按照正常的公司日历进行，但是有些则不能，例如有些项目必须在政府的法定节假日中进行，有的项目只能在夜间进行，很多项目为了赶工期，需要加班加点工作，这些都导致项目必须采用与常规的基准日历不同的特定项目专用的日历，这种专为项目定制的日历，就是项目日历，每个项目都可以有自己的项目日历。项目资源日历是针对项目中的资源的。项目当中必然需要资源，对于公司内部的人力资源来说，通常可以按照项目日历来安排，也就是把项目日历作为这些资源的资源日历，但在某些情况下则会存在特殊情况。对于从公司外部获得的人力资源来说，特别是一些专家级的稀缺资源，只能依赖于这些资源的时间表，来安排与其有关的项目活动，资源可认为项目提供服务的时间安排，就是该资源在此项目中的工作时间，其它时间不能为项目提供服务，就都被视为非工作时间。对于机械设备这类资源，在可用的时间段内，天天24小时均可作为工作时间，这是与人力资源的一个很大的差别。可见，项目资源日历关心的是各种资源可认为本项目提供服务的时间范围。从资源角度来说，一个资源可认为多个不同项目或其它任务提供服务的时间安排，就称为该资源的资源日历。根据这些日历的规定，将带有工期的项目活动网络图映射到具体时间上，就拟定了各个项目活动的起止时间，形成了初步的项目时间表。6， 限制条件项目各个方面的干系人，在项目时间方面也许会提出一些限制性条件，例如规定了项目的启动时间或结束时间，规定了项目中一些里程碑的具体时间点，前面所说的项目日历、项目资源日历也对项目提出了时间方面的限制条件。根据这些限制条件，调整初步的项目时间表。7， 辨认关键途径在初步形成的项目时间表中，存在着所谓的关键途径（Critical Path）。这条关键途径由一系列的项目活动组成，关键途径上的项目活动假如有任何的延迟，都会导致整个项目的延期。因此，一般在制定出项目时间表以后，都要辨认出其中的关键途径，对时间表的优化，以及在项目执行过程中对进度的控制，重要都是围绕关键途径的。通过综合以上各个环节，形成了初步的项目时间表，但这个时间表未必可以完全满足所有限制条件的规定，也未必就是最佳的，也许尚有进一步优化的也许。具体优化的方法我们就不在这里具体介绍了，有爱好的读者可以参考有关的专业书籍。在公司级项目管理体系当中，特别需要关注多项目之间的时间表匹配问题。一种情况是多个项目共同完毕一项工程，不同项目之间在时间上需要互相配合，此时这些项目其实可以看作是一个更大项目当中的子项目。尚有一种情况就是公司资源在不同项目之间的调度问题，资源往往是公司的固定成本，公司总是希望尽也许的提高资源使用效率，资源日历其实对于公司内的资源管理是非常重要的。1.4.4 成本管理项目成本管理，是项目管理中非常核心的管理内容之一，直接影响到项目的成败，假如项目中出现资金链断裂导致项目的钞票流出现问题，就会出现“烂尾楼”的现象。同时，公司通过项目获得收益，项目的成本管理就直接关系到公司的盈亏。因此，项目成本管理是项目、公司共同关注的内容。另一方面，项目的成本管理指标，也是项目管理的重要指标，它同时还可以反映项目进展情况，从一个侧面反映项目的进度情况，并可以根据当前项目成本、进度的偏差，对项目后期的情况进行预测。成本是资源的花费，项目产生成本的基础就是由于项目花费了资源，因此，项目资源的管理，也是项目成本管理这一领域中的重要内容。在项目的成本管理中，一方面要根据项目范围和活动的需要，拟定项目资源的需求，然后根据项目资源的价格水平，计算出项目资源的成本，从而得到项目的总成本，形成项目预算，随后就要对项目成本进行控制，力求项目的实际成本可以控制在项目的预算之内。成本指标可以综合反映项目任务的工作量、复杂度、资源能力、风险等各种因素，在实际的项目中，有的项目前紧后松，有的项目前松后紧，有的项目前期任务难度高、工作量大，有的项目则是后期难度高、工作量集中，单凭时间是看不出项目任务的实际完毕情况，而通过成本指标，运用“挣值”方法，可以更加实际的综合反映出项目任务的完毕情况。对于项目如何进行成本管理，也是公司级项目管理体系中的重要议题。项目经理为了可以保证项目任务的完毕，总是希望争取更多的项目预算，从而得到更多的资源，但是公司总是希望项目组在完毕项目任务的同时，尽也许少的花费公司的资源，减少公司的成本。在项目的成本管理中，公司管理者和项目经理的立场有时是冲突的。所以公司非常需要建立一种合理的绩效体系，既要保证项目所必需的资源，保证项目经理们的工作积极性，又要避免不必要的资源浪费。1.4.5 质量管理在项目的质量管理领域中，同时包含着产品质量和项目质量两个方面的内容。产品质量是指通过项目所发明出的产品或服务自身的质量，通常情况下产品的质量在业界是有标准可循的，例如通过一个工程项目完毕一幢大楼的建设，大楼自身的工程质量是有明确而具体的标准的，无论是工程承建单位，还是工程发包单位，都可以依据同样的标准来检查项目的成果。而项目质量则是指项目管理的质量，同样是完毕了所规定的项目成果，但是在所花费的时间周期、资源成本、各方面的满意度等许多管理方面，不同项目之间还是存在着差别，这种差别就是项目管理质量的差别。在质量管理这一领域中，包含着质量计划、质量保证和质量控制三方面的内容。质量计划重要就是指项目过程中的质量管理工作的计划，质量保证则是关注在项目的过程当中如何努力保证质量，质量控制则是关注在事后对质量的检查。因此，质量管理领域中的这三项内容，分别是从事前、事中和事后三个不同的阶段来强调质量管理。在实际的项目管理当中，质量控制往往以内部和外部验收的方式出现，在产品形成后，项目内部一方面会对其质量进行检查，然后提交给客户，由客户做验收。在检查过程中假如发现问题，一般都是通过再加工的方法解决，假如问题严重的话，就也许需要部分甚至所有的返工，结果必然导致项目在时间、成本方面的大量追加。因此，对于项目管理者来说，都不乐意看到在事后的质量控制环节中出现问题，而是更希望在项目过程当中及时发现和解决问题，甚至尽量避免问题的产生，这样所导致的成本浪费比以后返工要低得多。因而很多公司和项目，都对过程当中的质量保证工作给予了高度的重视，设立专门的质量保证员（通常称为QA），来帮助项目组在过程当中保证质量，避免问题到了后期的质量控制当中才暴露出来。在质量管理问题中，有这样一个说法，叫做“1：10：100”。当一个问题刚刚出现的时候，纠正该问题的成本假如是1，那么这个问题假如由于没有得到及时解决而被带入到下一个阶段中才解决，其成本将是10，假如要继续等到再下一个阶段去解决，其成本将是100。初期的问题假如得不到及时的纠正，在项目过程中会被迅速放大，解决的成本就会急剧膨胀，这正是所谓的“差之毫厘，谬以千里”。例如在一个软件项目中，初期的需求分析中假如出现偏差，对其纠正时也许只需要几人天（甚至几人时）就可以解决，但是假如到了编程阶段才发现问题去解决，也许就需要花费几十人天的工作来解决，假如该软件已经被投入实际应用后才发现需求中有问题，那么也许要花费更大的成本去更新。假如是为客户开发的软件产品，那么也许就从主线上面临着不被客户接受的风险，损失也许更是无法估量的。质量标准需要一个相对合理的标准，不能盲目追求高质量。一方面，产品自身就已经划分了不同的等级，不同等级的产品有着不同的价格水平，生产二等品的项目就不应当规定达成一等品的质量。另一方面，质量也是有成本的，涉及防止成本、鉴定成本和失败成本。越是质量规定高的产品，在质量管理方面的投入也就越大，因此，在质量管理中需要预先拟定一个适当的质量标准，在质量水平和成本方面取得平衡。可以看出，质量管理反映了公司对其核心能力的关注，质量管理的效果直接关系到客户满意度，关系到公司的赢利能力，因此，许多公司都建立了诸如ISO9000、CMM这样的质量管理体系，试图对公司的各种质量标准和行为标准建立规范，使公司在长期实践中不断优化和提高其提供产品和服务的能力，这已经不单是某个项目经理考虑的问题，而是公司管理者所关注的公司级的问题，是公司级项目管理体系当中的重要内容。1.4.6 人力资源管理“事在人为”。人力资源管理其实是项目管理中非常重要的内容，找到合适的人，作适当的事，这是公司管理者和项目经理们都非常重视的问题。在项目中会碰到各种各样的工作需要解决，有组织协调的工作，有专业技术的工作，有复杂决策的工作，也有简朴反复的操作工作，在一个项目团队中，需要不同角色的成员来分担不同性质的工作，因此就需要考虑到项目成员特点的组合。在整个项目过程中，项目经理必须重视项目团队建设的工作，以保证整个项目团队可以齐心合力完毕项目任务。在PMBOK中对于团队建设的规定，就是要同时提高项目团队的整体能力和项目成员的个人能力。这是符合现代公司管理中股东、公司、员工三者共同发展的理念，只有这样才干充足调动项目成员的积极性，使他们发挥出主观能动性，共同把项目做好。在强调个人职业发展的今天，以往的那种掠夺式的用人方式，已经不能适应现代的管理规定了。项目的团队建设并不容易。项目自身具有临时性，项目相关的成员也是按照项目的需要临时组织在一起的，到项目结束时项目组也就不存在了。特别是在职能式组织结构和矩阵式组织结构中，项目组成员还也许需要同时面对项目和本部门两条报告路线，从长期来看，项目成员最终还是要由职能部门来管理的，这就给项目团队建设的工作增长了难度。这是项目经理所必须面临的考验。在具体项目中，必须要一方面明确项目中的组织结构和责任分工，保证项目成员都清楚自己的职责，我们通常用责任矩阵（RAM，Responsibility Assignment Matrix）来表达项目内部的分工配合关系，具体RAM的使用方法可以参考PMBOK或有关的资料。那么对于公司来说，如何为这些临时性的项目储备资源、提供资源，当发生资源冲突时可以有效的调度资源，以保证公司的人力资源可以发挥最大的效益，这也是摆在公司管理者面前的现实问题。特别是在人力成本很高的智力密集型的行业中，这一问题尤为突出。在公司级项目管理体系中，人力资源的管理是非常重要的一个方面。同时，由于许多现任的项目经理，大多数都没有通过人力资源管理方面的培训，所以公司级项目管理体系中，还要通过制度规定，对项目组内部的人力资源管理做出指导。1.4.7 沟通管理作为一个典型的项目经理，通常有7590的时间要用于沟通，沟通是项目经理最重要的工作职责。我们前面提到，项目内外有许多的项目干系人，他们都对项目起着或多或少的影响，特别是对于那些能直接影响项目的干系人，例如客户、项目决策者、项目投资人、项目成员、项目中的合作伙伴等，这些干系人处在不同的角度，对项目有着不同的盼望。如何将这些不同的干系人的不同盼望，统一到项目的目的上来，使他们都可以对项目采用积极支持的态度，给项目增长动力而不是阻力，这其实是项目经理最重要的任务。这种协调工作的最基本的方法，就是沟通。退而言之，即使项目的干系人对项目的盼望都是一致的，完全持积极支持的态度，也还是需要通过沟通来安排各方面的工作秩序，使各个方面的配合工作可以有条不紊、密切配合。再退一步说，即使项目中所有干系人都可以按照计划开展工作，由于在项目过程当中随时也许会碰到各种各样的问题，项目中的很多因素存在着不拟定性，也需要项目经理对项目的进展情况进行跟踪，了解项目的实际情况，对于出现的偏差进行调整，这个跟踪、控制的过程中也需要大量的沟通。因此，假如没有很好的沟通，就难以达成一致的目的，难以有效的组织项目，也难以很好的对项目进行控制。因此，在项目的沟通管理中，一方面要分析清楚项目中的干系人，以及他们对项目沟通的需求，涉及需要沟通的信息内容和沟通的时间周期。例如高层决策者重要关心项目里程碑，所以只要在项目里程碑处向决策者提供项目报告即可，而对于项目的监督者，例如PMO，则需要经常性的向它报告项目的进展情况，一般每周或每月都要提交项目报告，对于财务部门，则需要定期或在项目里程碑处沟通项目成本情况，以便做好项目的成本控制。根据这些分析，一方面要制定好项目沟通计划，以便及时发布项目信息，使项目干系人可以及时得到所需的项目信息，配合做好项目的工作，并及时发现项目中存在的风险和问题。在所有的沟通管理中，都会注意到沟通方式的选择，目前我们可用于沟通的方式非常丰富，可以采用面谈、会议、电话沟通、电子邮件沟通、公文沟通等多种形式，这些沟通的方式各有特点，合用于不同的沟通目的，也就会产生不同的沟通效果。因此，在沟通管理中，项目内一定要有明确的沟通机制和沟通的手段，公司环境中现成的沟通渠道，例如公文运转、电子邮件等，都可以被用在项目当中，甚至项目内部可以根据自己的特殊需要建立自己的信息沟通系统。无论采用什么样的沟通手段，都需要一方面把内容沟通清楚。在正式的项目沟通内容中，最常见的就是项目绩效报告，无论是周报、月报、里程碑报告、阶段报告或结项报告，都属于项目绩效报告。项目绩效报告中一般都需要说明这样几方面的内容：1，从项目开始或上一次报告之后，到本次报告的这一时期中项目的进展情况，涉及计划情况、实际完毕情况、差异情况，前面在成本管理中提及的有关财务指标，在这里通常会被使用；2，项目当前的状态，其间应当完毕的工作是否已经完毕；3，项目下一时期的调整计划，以及根据前期的差异对以后的预测，一些财务预测指标也经常会被用到，如EAC根据当前偏差对项目竣工时的实际成本进行预测。4，项目风险跟踪、项目问题跟踪等。公司要管理和监控项目，就需要保证项目与公司管理者之间的密切沟通，但这不能只是依赖于项目经理的积极性，而是需要公司制定出相应的规定，这种规定带有强制性，项目经理必须按照统一的规定与公司的管理层进行沟通，并可以从管理层得到反馈。同时，为了提高各个项目中相关各方的密切沟通，提高客户满意度，公司也会不断积累经验，对项目中所必需的沟通形成制度，提高项目管理的水平。沟通是公司级项目管理体系中的关键机制和基本手段。1.4.8 风险管理假如项目中所有的资源都能按计划到位并进行工作，假如所有的外部条件都可以按照预期设想的那样稳定，那么项目的进程将会非常顺利的。但是在实际中，在项目的内部和外部，都大量存在着不拟定因素，被承诺的项目资源不一定都能按规定就绪，项目中的资源未必能按照预期的工作效率完毕任务，项目中的技术问题不一定能完全顺利解决，客户的需求也许会不断调整，外部的市场环境很也许会发生变化，相关的法律也许会进行调整。只要项目中存在尚未完毕的任务，就存在着对未来的预测和假设，就存在着未知因素，就一定存在着不拟定性，所以就有了这种说法，“变化是永远不变的主题”。项目管理的最核心的内容，其实就是对风险的管理。因此，项目自身就有“逐步完善”的特点。在项目初期，所有计划的内容都是基于一定的假设前提而对未来作出的一种预测，但是在项目的实际过程中，往往会存在现实与假设的差异，所以就需要根据现实情况调整项目计划，对项目的未来重新进行预测，只有到整个项目完全完毕后，整个项目最终才是拟定的。由此可以看出，越是在项目前期，项目的不拟定性越大，而越是到项目后期，项目中的不拟定性就越小。项目的风险管理是自始至终贯穿在整个项目过程中的。这种不拟定性（Uncertainty），会产生两个方向的变化有利的和不利的，我们通常将有利的变化称为机会（Opportunity），将不利的变化称为威胁（Threat）。在项目风险管理中，重要就是针对这种不拟定性进行管理，使这种不拟定性尽也许演变为机会，尽量避免演变成为威胁。例如在软件项目中，需求变更往往是很也许发生的，并且一旦发生需求变更，对项目的进度、资源、成本等，都会产生直接的影响。这时，假如项目管理者可以有效引导，在发生需求变更时，减少了项目范围，那么就也许减轻了项目的压力，而假如通过需求变更大大增长了项目范围，将会给项目带来很多新的问题。在实践当中，在项目风险管理过程中，大家更重视威胁，而对于也许的机会，却很少考虑，其实威胁和机会往往是随着在一起的。在一个风险管理计划中，应涉及以下这些内容：风险事件（导致风险的直接因素和现象）及也许的影响范围，风险发生的也许性，风险实际发生后导致的后果严重性，风险缓解计划，风险应对计划。通过有效的风险辨认来列出风险事件及其也许带来的影响，这需要组织的知识积累和项目经理的经验积累，对于风险发生的也许性和后果严重性，可以先进行风险定性分析，列出高、中、低不同等级，再根据项目的实际需要，对高、中档级的风险进行定量分析，预测风险发生的概率和也许导致的损失，从而计算出风险的价值：Risk=Probability_ * Magnitude。将此公式缩写就成为 Risk=P* M。对于项目中辨认出来的风险，应当有相应的风险缓解计划，考虑如何引导风险使之不要演变为威胁。根据计算出来的风险价值，可以在风险应对计划执行中提出风险的对策，通常涉及：回避、转移、减少、接受四种。通过改变技术方案、更换项目资源等方式回避风险，通过外包、投保等方式转移风险，通过相应的技术、管理措施来减少风险，对于影响不大、完全可以承受的风险，可以直接接受而不采用任何措施。下图中的曲线，反映了随着项目时间的推移，项目风险发生的也许性与项目风险也许导致的影响限度的变化规律与风险密切相关的，就是问题管理。当风险转变为实际发生的问题后，就进入问题管理。问题管理的计划，就应当是风险应对计划。对于问题的描述，应涉及现象、后果、因素、解决方案、采用的行动及当前解决状态。在项目的计划过程中是不应当存在问题的，只能存在风险。公司级项目管理体系，要对项目的风险管理给与指导和督促，并将公司级资源作为协助项目组管理高等级风险和问题的资源。1.4.10项目管理三角 至此，我们将项目管理的九大知识领域内容一一做了简朴介绍。在这九个知识领域中，项目管理最核心的内容，就是项目的范围、时间、成本和质量这四个领域。项目管理三角形，正是阐明这四个因素之间的互相影响关系的。;项目作为一个整体，要使各方面的资源可以协调一致，在现实条件和目的之间取得权衡，就要特别熟悉项目管理三角形的概念。项目管理三角形中的范围，除了要考虑对项目直接成果的规定，还要考虑与之相关的在人力资源管理、质量管理、沟通管理、风险管理等方面的工作规定。项目管理三角形中的时间，强调的是对项目时间进