Microsoft 解决方案框架 — MSF 项目管理准则 v. 1.1
Microsoft 解决方案框架
白皮书
摘要
Microsoft 解决方案框架 (MSF) 具有一种分布式的、能够提高责任性的项目管理小组方法，这个框架还具备很大范围的灵活性，既适用于小型项目，也适用于非常巨大和复杂的项目。本白皮书描述了这种分布式小组方法的原理，并解释了项目经理与 MSF 小组模型之间的关系。尽管项目管理对于小型项目也很重要，但是本白皮书把重点放在具有扩展小组的大型项目上。虽然本文没有涉及到项目管理领域的所有方面，但是给出了用于规划和评估的推荐做法。
本页内容
 |
框架概述 |
|
介绍 |
|
MSF 基础原理 |
|
关键概念 |
|
MSF 项目管理的特征 |
|
用于 MSF 小组的精选建议 |
|
计划安排建议 |
|
结论 |
|
尾注 |
框架概述
为了使信息技术 (IT) 项目的成功最大化，Microsoft 提供了一个打包的指南，用于有效地设计、开发、部署、操作和支持建立在 Microsoft 技术之上的解决方案。这一知识来自于 Microsoft 在大规模软件开发和服务操作项目上的经验，来自于 Microsoft 顾问在为企业客户实施项目时所获得的经验，以及来自于全球 IT 行业的最佳知识。本指南安排成相互补充、紧密集成在一起的两个知识体系，或者叫做框架。它们分别是 Microsoft 解决方案框架 (MSF) 和 Microsoft 操作框架 (MOF)。
在预算范围内按期创建一个业务解决方案需要一种经过检验的方法。MSF 为成功地规划、设计、开发和部署 IT 解决方案提供了经过检验的做法。与规定的方法相反，MSF 提供了一个可以伸缩的灵活框架，以满足任何规模的组织或者项目小组的需要。MSF 指南由原理、模型和用来管理人员、项目和技术元素的准则，以及它们的折衷（大多数项目都会碰到）组成。
Microsoft 操作框架 (MOF) 提供了技术指导，从而让组织能够在使用 Microsoft 产品和技术创建的 IT 解决方案上取得任务关键系统的可靠性、可用性、可支持性，以及可管理性。MOF 的指导致力于解决人员、过程、技术和管理等问题，这些问题都与操作复杂的、分布式的、差异巨大的 IT 环境有关。MOF 基于一套行业最佳做法，称为 IT 基础结构库 (ITIL)，由英国政府的政府商务办公室 (OGC) 颁布。
介绍
MSF 最引人注目的一个特性是其缺乏一个称为项目经理的角色或者职位头衔。这对于一个用来解决 IT 项目成功完成相关问题的框架来说是很令人意外的。但是 MSF 非常强调与项目管理有关的准则和能力。
本白皮书总结了项目管理准则的关键方面，并描述了 MSF 如何来处理它们。本文阐述了 MSF 的基础原则如何在实施项目管理中衍生一些与众不同的概念和做法。
本白皮书还描述了为了支持整个小组，MSF 程序管理角色如何提供专门的项目管理技能，并描述了典型的项目管理活动如何分布到 MSF 小组的各个领导身上。
本白皮书并非旨在提供项目管理的指南，它也不会试图解释有经验的项目经理所使用的很多技巧。它的目的在于说明 MSF 的原理如何产生出项目管理方法，其中
| • |
项目管理的职责被分布到了小组领导的身上。 |
| • |
项目管理的专家提供一种以促进和指导为基础的方法，而不是强行去控制小组里的其他成员。 |
在阅读本白皮书之前，请先阅读 MSF 小组模型白皮书。
MSF 基础原理
尽管没有在本文里讨论，但是 MSF 项目管理准则会以某种方式应用 MSF 所有的原理，这一准则与下面的几点直接相关。
清晰的责任共担职责
MSF 小组模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点，没有哪一个人能够成功地代表所有角色的所有质量目标。但是客户需要一个对项目状态、行动和当前问题等信息的权威来源。为了解决这一两难的境地，同级的小组必须把对客户的清晰责任与对整体成功的共同职责结合起来。
在小组内部，每个角色都对实现自己质量目标所需要的活动负有责任。
小组的每个成员都对项目的整体成功和解决方案的质量都负有职责，并希望根据他们自己的知识提供自己的想法和观察，即使是在那些他们并不负责的领域里。
具体来说，MSF 小组角色共同担当着项目管理很多方面的职责，例如风险管理、时间管理、质量管理、规划、日程安排、小组招聘，以及人力资源管理等。
被赋予权力的小组会更加有效
在一个高效的小组里，成员被赋予权力来交付他们自己的承诺，他们相信只要是他们所依赖的、由别人来承担的承诺，别人就能够交付承诺。类似的，客户有权认为，小组会兑现其承诺，并就此进行规划。任何延迟或者改变都应该被尽快报告。
MSF 小组向其成员赋予了完成他们的承诺所需要的权力。这对于项目管理这一角色监视过程的能力具有深远的影响。如果没有被赋予的权力和承诺，小组管理者就必须不断检查，看小组成员是否偏离了方向。一旦他们确信任何延迟都会在发现的时候被立即报告，小组领导就会变成一个具有更大促进作用的角色，帮助小组成员评估他们的真实位置，同时为他们提供指导和帮助。对过程的监视分布在小组的各处，并成为一个支持性的角色，而不是一个控制性的角色。
关键概念
要理解 MSF 的项目管理方法，理解 MSF 定义下列概念和术语的方法就显得尤为重要了：
MSF 中的准则
MSF 认为，多个非技术领域里的专长是 MSF 小组模型里所有角色需要具备的重要能力。这就叫做准则。要获得更多的信息，请参阅 MSF 小组模型白皮书。
当前，MSF 有三个准则，分别是风险管理、就绪管理和项目管理。
MSF 认为，这些准则已经发展出了建立在多个行业基础上的最佳做法，而不仅仅只在信息技术 (IT) 行业里。这些做法常常能够被应用到 IT 操作和其他业务过程以及 IT 项目里。MSF 没有重新发明这些做法，而是总结了项目小组需要知道的、关于这些准则的一些内容，并加入了 Microsoft 小组在过去几年里所领悟到的东西。
为了有效地实施这些准则，MSF 所有的小组角色都必须在每个领域里具有足够高的能力。
什么是项目管理？
在描述 IT 项目里的项目管理之前，不论什么类型的项目，首先理解项目管理的定义是很有好处的：
一个项目就是一次临时的投机，它具有确定的开始和结束，其目标是创造一项独特的产品或者服务。 项目管理是用来实现项目目标的一套知识、技能、工具和技术，而项目目标就是一致认同的质量、成本、日程安排和约束等的参数。(I)
在一些公司和国家里，程序这个术语用来描述被放在一起的项目组。为了与叫做程序管理的 MSF 小组角色群区分开来，一组项目被叫做项目组合。
MSF 对项目管理职责、技能和活动的领域进行了下列分类。(ii).
| 项目管理领域 | 描述 |
|
项目规划／跟踪／改变控制 |
集成和同步项目计划；设置用于管理和跟踪变化的步骤和系统 |
|
范围管理 |
定义、分解工作范围（项目范围）；管理项目折衷 |
|
日程安排管理 |
利用小组估计生成日程安排，任务排序、将资源与任务进行匹配、应用统计学的技术、日程安排维护 |
|
成本管理 |
根据小组时间估计来准备成本估计；过程报告和分析；成本风险和价值分析 |
|
人员资源管理 |
规划资源、构建小组、解决冲突、（为项目而）规划技能就绪 |
|
交流管理 |
交流规划（小组、客户／赞助商、用户、利益相关人），项目状态报告 |
|
风险管理 |
促进和推动小组风险管理过程；维护风险文档 |
|
采购 |
邀请承包商参与服务和／或硬件／软件的投标；准备要求建议 (RFP)，管理供应商或者分包商；合同和协议的管理和谈判；开放采购订单和批准发票 |
|
质量管理 |
质量规划，即确定要使用哪些标准，提供质量标准和质量测量过程的文档 |
尽管本白皮书无法给出关于上述领域的完整指导，但是本文档后面会提供经过挑选的 MSF 推荐做法。
项目管理不是由项目经理一个人完成的
在日常的言谈中，项目管理这个术语可以被用描述一个角色以及在某个领域里的技能和专长。例如，想想“项目管理层说他们现在应该已经完成了它”这样的说法，以及“太空机构一般都会有优秀的项目管理能力”这样的说法。
这种差别很重要，因为项目管理作为一种活动是由很多人（共同）完成的，而这些人并不都是项目经理。
在 MSF 里， 项目管理总是用来指上面所列领域里的特定知识和技能，而不是一个角色或者职位头衔。而项目经理这个术语将会被用来描述擅长进行项目管理的人。
项目管理和 IT 特定过程
总的来说，项目管理由一些知识和技术组成，这些知识和技术可以广泛应用到实施这些项目的任何行业领域里。每个行业领域（例如太空行业、建筑行业、IT 行业等等）都有最适合该行业的特定过程、阶段、角色和做法。为了成功地实施项目，这些针对行业的过程就必须与一般的项目管理做法形成互补。
MSF 为 IT 项目提供了过程和推荐的做法。它与项目管理准则的关系见图 1。
在这上面的图里，针对行业的领域是 MSF 过程的五个阶段。针对行业的项目管理活动的一个例子是用于跟踪错误的推荐做法。项目管理的一般知识领域在左边。一个例子是用于管理合同或者跟踪预算的推荐做法。交叉代表了特定的项目管理做法，后者是 MSF 的特征。这些都会在后文进行描述。
MSF 项目管理的特征
MSF 方法的这些与众不同的特征将在这里描述，并在后面进行更加详细的讨论：
| • |
项目经理角色的大多数职责都包含在 MSF 程序管理角色群里。 |
| • |
在需要 MSF 扩大小组的大型项目里，项目管理活动在多个层次发生。 |
| • |
某些大型的或者复杂的项目需要专门的项目经理或者项目管理小组。 |
项目管理角色包含在程序管理里
MSF 程序管理角色群包括了下面所示的职能职责领域。在小型项目里，所有的职能职责一般都是由一个程序经理来处理的。随着项目规模和复杂性的提高，这一角色群分解成了两个专门的分支：一个处理解决方案体系结构和规范，另一个处理项目管理。
程序管理如何与小组领导一起工作
要理解项目管理如何在 MSF 里工作，就有必要理解小组模型如何扩大规模、进行规划、通讯，以及决策。关于这一点的更多信息，请参阅 MSF 小组模型白皮书。
如何去分布小组管理，在很大程度上要取决于项目的规模和复杂性。
MSF 是一个高度可伸缩的框架，它能够被用在只需要两个或者三个人的小型项目里，也可以用在非常大型的项目里。Microsoft 内部的产品小组就涉及成百甚至上千个小组成员。MSF 已经把从 Microsoft 小组组织里学到知识进行了归纳，供更大范围的 IT 项目使用。
MSF 的可伸缩性在很大程度上来自于小组模型。小组模型可以以两种方式扩大规模：
|
1. |
通过将小组角色抽象成为一套职能职责，而不是特定的职位描述。通过这种方式，每个角色的职能就不会被限定到个人身上。一个角色可以被扩展成为多个角色群，每个都专注于一系列目标更加明确的职责。一个或者多个个人可以担当这些更加专业的角色。 |
|
2. |
使用功能小组和职能小组的各种组合，以创建任意数量的可能的大型小组结构。对功能小组和职能小组的描述见下面。 |
职能小组
职能小组是存在于一个角色内部的子小组，当一个角色里的任务达到要求使用专门资源的时候它才会被组建。职能小组的一个关键方面并不简单的就是角色需要一个以上的人来担当，而是在其成员中有一个对任务的陈述。图 2 是其中一个例子。
小组领导是大型小组其他成员的集成点。小组领导在其子小组这一层次负有一些项目管理的职责。
功能小组
功能小组是跨学科的子小组，它们被安排在解决方案的特定功能周围。功能小组由组成小组模型的六个角色构成。图 3 显示了一个功能小组。程序管理角色也是为大型小组提供集成点的小组领导。功能小组的结构是远程或者“离岸”子小组（用于为解决方案构建相当分散的组件）的有力候选对象。
扩大程序管理职能的规模
图 4 显示了如何在三个项目规模层次处理项目管理活动。在项目 A 里，所有的角色都由大约六个或者更少的人来担当，所有的项目管理活动都由程序管理来处理。这并不意味着其它的角色就不会为项目管理作出贡献。事实上，这意味着他们在负责规划、时间估计和识别他们各自领域里的风险。
在项目 B 里，大多数或者所有的角色都由子小组来担当，每个角色都有一个小组领导。小组领导对其各自的子小组进行项目管理。程序管理角色群拥有负责整个项目的项目管理活动。要注意的是，功能小组没有在图上显示出来，但是它们也是子小组。由于每个子小组都是跨学科的，所以每一个都有一个程序管理领导。
项目 C 和项目 B 类似，尽管它有与其规模或者复杂性相关的特殊风险。复杂的项目，就像用在 MSF 里的一样，意味着项目具有与下列因素相关的高风险：
| • |
大规模或者高成本。 |
| • |
地理上分散的小组。 |
| • |
小组成员隶属于多个公司、组织或者分包商。 |
| • |
固定的或者高度受限的预算或者日程安排。 |
| • |
需要技能和时间来管理的合同或者法律问题。 |
为了降低这些风险，程序管理角色群有一个职能小组，它包括专门的项目经理和解决方案架构师。要注意的是，风险的限度对于所有的组织和项目来说都是不同的。对于某个组织来对成本非常高的东西对于其他组织来说可能未必。这完全取决于项目早期进行的风险评估。
项目管理职责
上面一个章节讨论了如何把不同规模和复杂性层次的项目管理活动分布给各个小组成员。本章就将描述这些活动。
图 5 描述了每个角色和程序管理的小组领导所具有的项目管理职责。在复杂项目（例如图 4 里的 项目 C）里，专门的项目经理所关注里的领域与程序管理的相同，只不过是在一个独有的基础上。要注意的是，相同的职责领域常常会由项目层和子小组层来负责。
小组领导
小组领导要为其子小组准备计划，以描述工作要如何完成，如何根据计划跟踪实际的工作，如何管理范围和变化，如何给子小组里的特定任务分配资源，以及如何协调子小组的内部沟通。小组领导所进行这些活动都需要子小组各个成员的参与和输入。在参与全部风险识别的时候，小组领导要专门负责识别其角色专长领域里的风险。
图 5 里有三个地方可以将小组领导的职责与其他成员的职责模式区分开来：
|
1. |
项目的成本管理一般都被作为程序管理职责集中到一起了。把这些职能分布到领导身上将会分散大家的注意力，并可能引起混乱。 |
|
2. |
采购职责由程序和／或发布管理来处理，而不是由其他的小组领导来处理。程序管理会处理项目以及多种采购服务的大多数合同事宜。（把项目的一部分）分包一个 Web 设计公司，让其加入小组就是这样的一个例子。发布管理作为小组 IT 操作的代表，会处理构建解决方案所需的以及小组开发和测试实验室环境所需的硬件、软件和设备等的采购工作。 |
|
3. |
在整个项目层的沟通管理由程序管理和产品管理来共同承担。产品管理会为客户、利益相关人，以及任何外部人员创建和交付沟通计划。程序管理会规划和负责项目沟通，例如报告状态、主持小组会议，以及类似的事情。沟通管理还包括小组以外的沟通规划、合同指定点的分配和过程的报告。 |
程序管理
除了负责高层的解决方案体系结构和编写职能规范（就如在小组模型里描述的那样），程序管理还拥有把项目作为一个整体的所有项目管理领域。
程序管理会把小组计划集成到主要计划里，同步日程安排，并管理跨小组的依赖性。
把解决方案设计的职责和职能规范放到同一个角色里作为日程安排和成本职责有一个巨大的好处：它会打破相对于成本而言的设计过度的倾向与日程安排所暗示的之间的平衡。
大型、复杂项目里的项目管理
随着项目变得更大或者更复杂，它可能会取代管理职能规范、更新日程安排、发出小组沟通、报告过程和进行其他的项目管理活动。要应付这个，把程序管理角色群的职责分割成解决方案体系结构和专门的项目管理角色常常是有道理的。
项目监督服务
在某些方面，一个大型的项目必须要做的事情和小型业务必须要做的相同：跟踪财务、采购供给和服务、管理员工的业务、提供入门培训、安装小组工作设施等等。在大型项目里，对状态、成本和日程安排的例行跟踪变得非常耗时。为了让项目经理把精力放在最紧迫的问题上，更多日常的项目管理活动被委派给了项目监督（或者项目支持）角色。项目监督服务还为小组领导提供了支持，帮助其维护小组日程安排和其他的管理活动。
客户的责任
客户常常想要一个实现整个项目成功的责任点。有些组织希望项目经理来扮演这个角色。有时候这在大型或者复杂的项目里会有保证，但是这种方法会使得小组角色责任失衡，从而导致项目表现不佳。MSF 满足了客户为确保满意度而产生的对监督点的需要，同时在同级小组里保留职责。
在 MSF 同级小组里，小组的每个角色都在内部负责自己的活动。此外，担当每个角色的个人通常也都要在项目小组之外的一些管理结构里负责。由于 MSF 认为，并不是所有的小组成员都工作在同一个公司或者组织里，所以这些责任路径会通往这些个人所属的组织、团队或者部门。
这里的关键点是：
| • |
在这个主题上没有绝对的事。在直接的项目小组之外，组织的报告结构和服务关系之间存在很多可能的不同之处。 |
| • |
识别项目的责任路径。阐明在小组自身之外，谁要为项目的什么方面负责。 |
MSF 小组模型以下列方式提供了客户责任：
| • |
产品管理会维持与客户之间的关系，并扮演客户支持者的角色。这一角色的目标就是客户的满意度。 |
| • |
程序管理表现的目标是在项目约束内成功地交付项目。 |
| • |
产品和程序管理会共同工作以便在项目约束之内满足客户需要。这两者共同分担项目的整体成功，尽管它们的角色都在为不同的目标而努力。 |
| • |
如果发生了产品和程序管理都无法解决的问题，那么这些问题都会逐步升级成为整个项目的责任路径。 |
用于 MSF 小组的精选建议
下面推荐的项目管理做法是用于 MSF 小组领导和程序管理的。这些与出现在图 5 里的某些，但不是全部的项目管理职责相对应。
范围管理
范围管理的目的是确保项目能够识别完成解决方案所需要的所有工作，而不会在没有先期的调查和同意的情况下就偏离目标去进行范围以外的活动。
构想阶段的范围
在项目的早期阶段，项目的宽范围必须被识别和列入文档。
在 MSF 构想阶段，小组会为解决方案生成一个没有边界的前景。然后范围就会被识别，成为第一个版本。这在前景／范围文档里有描述，而且在项目继续之前经过了小组、客户和利益相关人的认可。在这个阶段过程中，范围只能在描述特性这一层次被广义地理解。
解决方案范围和项目范围
范围可以指解决方案范围和项目范围。解决方案范围是要被构建的特性和交付内容的总和。项目范围是交付解决方案所必须完成的所有工作的总和。
这个术语用 MSF 设计过程来定义解决方案范围。
范围定义
在规划阶段，整个项目范围必须被细分成为更小的、可管理性更强的部分。这个过程会阐明项目之外的特殊领域。通常，这些都是会产生误解的具有特殊风险的领域。
在定义范围的过程中，小组会识别构建每个特性和交付内容所需的任务和技能类型。这会被归档放到一个工作分解结构 (WBS) 里，本白皮书下文即将讨论这一结构。
范围改变控制
一旦定义了范围并为其制定了基准，小组就会将其置于改变控制之内。对范围的改变必须同时由小组和客户来检查及认可。
好的改变控制在一定程度上涉及好的折衷决策。MSF 折衷三角形和折衷矩阵是以可控方式推动改变的有用工具。
要获得更多信息，请参阅 MSF 过程模型白皮书。
准备计划
规划作为一项活动会发生在项目的始终。在构想阶段，小组会安排创建项目交付内容所需要的高层方法。
例如，测试方法会描述测试的类型、工具以及所需的技能。根据项目的规模不同，这可能只有一页或者两页纸，甚至只是一段文字。
尽管计划会在每个阶段改进和更新，但是大多数的规划工作都会在 MSF 规划阶段进行。
在这个阶段里规划过程的一般顺序是：
| • |
设计过程（你要构建什么？） |
| • |
规划过程（你要怎么来构建？） |
| • |
对开发进行日程安排（什么时候构建它？） |
这些可能会在某些方面相互重叠，但是在下一个过程能够取得丰硕的成果之前，必须为先前的过程制定一个基准。本章就将集中讨论规划过程。
重新使用文档
项目小组一直都会因为要把规划的时间和花费压到最小而倍感压力。在压缩规划花费的同时怎么才能够获得好的规划所带来的好处呢？
答案就是巧妙地搜集和重复使用项目计划文档。意识到项目计划文档是有价值的知识产权的组织会投资把它们组织和维护起来，放到一个能够轻易访问得到的储备库里。
在创建新的计划之前，小组应该总是搜寻任何已经被完成的东西。一旦一个项目完成了，项目文档就应该被归档，放到一个未来的小组能够重复使用的地点。
项目计划
在 MSF 里，项目计划指的是一套描述如何完成项目交付内容的文档。职能规范用来描述将要构建的内容。主项目计划是每个角色的小组计划的集成和累积。每个小组角色都拥有描述自己要如何完成交付内容的计划。
MSF 没有规定所有项目都必须具有一个适用于所有情况计划列表。下面的默认列表涵盖了软件开发和基础结构部署项目里常见的规划领域。在小型项目里，这些计划中的某一些可能会被组合在一起。有些项目可能需要额外的计划。
| 计划类型 | 驱动角色 |
|
沟通计划 |
产品管理 |
|
开发计划 |
开发 |
|
培训计划 |
用户体验 |
|
安全计划 |
开发、发布管理 |
|
测试计划 |
测试 |
|
预算计划 |
程序管理 |
|
用户教育计划 |
用户体验 |
|
部署计划 |
发布管理 |
|
采购和设备计划 |
发布管理、程序管理 |
|
试验计划 |
发布管理 |
工作分解结构
工作分解结构 (WBS) 是一个面向交付内容的、经过分组的项目工作元素，用来组织和定义项目的总范围 (iii)。它是要被完成的工作的大纲。没有纳入 WBS 结构里的工作就不在项目的范围之内。小组领导和项目管理将 WBS 用作项目管理工具，来构建计划和日程安排。
在 MSF 里，创建 WBS 是一项需要所有小组角色参与的集体工作。每个角色都主要负责定义其各自领域里的工作细节。在大型项目里，子小组（职能和／或功能小组）可能需要单独地集体讨论所需要进行的工作。小组领导会把集体讨论的结构归档，并把结果呈交给核心（领导）小组。项目管理然后就会把这些结果同步成为一个共同的 WBS。
优点
如果被当作一套数据而不是特定的文档的话，那么WBS 的价值会得到最全面的理解。这一数据在和其他项目数据结合到一起的时候，可以用来创建计划、日程安排、预算，以及其他项目交付内容。WBS 能够用缩进式列表或者块关系图来显示，并能够用各种工具来创建，比如电子数据表、文字处理程序，或者项目管理软件。
WBS 具有下列优点：
| • |
估计 。为要被估计的任务提供一个基准。所提供估计结果用来确定成本和日常安排。 |
| • |
提供资源。。通过明确要被完成的工作项目，员工和技能资源就会成为可知的。如果项目的利益相关人要询问理由，这还会有助于说明所需要的资源。 |
| • |
排序。提供一个能够用来分析依赖性和资源约束的任务基准列表，以便将其发展成为日程安排。 |
| • |
风险识别。帮助小组在识别风险的时候考虑每项任务。 |
| • |
职责。可以被用来生成职责矩阵。 |
WBS 和职能规范以及主项目计划之间的可跟踪性
职能规范、主项目计划和 WBS 之间存在一个可跟踪的关系。它反映了交付内容和构建交付内容所需任务之间的关系。
对于职能规范里的每个特性或者组件，WBS 列出了与完成该交付内容相关的任务。在职能规范里，特性或者组件被分组的方式同与它们相关的任务出现在 WBS 里的方式不同。
如果一个特性在 WBS 里没有与之相对应的任务项目，那么它可能会在后来的估计过程中“掉入裂缝”，而这可能会导致不切实际的日程安排或者预算。
主项目计划和 WBS 以一种互补的方式工作。WBS 会简要地列出每个任务。任务如何进行、质量标准和详细的子任务或者清单等的详细信息都被归档进了计划。
图 6 是 WBS 能够如何成为维护规范、计划和日程安排之间可跟踪性的强大工具。
构建工作分解结构
每个小组都会识别生产项目交付内容所需要的特定活动。活动的具体细节都由各种角色或者子小组以清单和项目的形式所有和跟踪。
在 MSF 里，层次最低的活动出现在主项目计划里，而不在 WBS 里。这些会合成为值得在整个项目层进行跟踪和报告的大型任务，这就是 WBS。
小组领导与其他角色小组碰面，以分解工作要求。通过与职能规范和其他交付内容的规范一起工作，所需要的工作就要被识别和分解成微小的活动和任务。这一过程就叫做工作分解。
MSF 风险管理过程的结果之一就是其它响应风险（有时候也叫做“威胁”）或者意外计划和活动的任务。这些任务必须像其他所有的任务一样被加到 WBS 里，被估计、规划和列入如日程安排。要考虑连续开设小组工作分解讲座和风险集体讨论讲座。
WBS 的第一层应该包括项目生命周期的一个阶段。MSF 过程模型在这一点上做得很好。MSF 所建议的中间里程碑与交付内容的完成以及基准的制定是密不可分的。中间里程碑还会构成一个自然的第二层。在这一层次之下，可以识别所有的交付内容并针对每一个都分解任务。这一过程也叫做工作分解或者任务分解。
任务分解指南
在进行任务分解的时候，建议采用下列指南：
| • |
能够被实际地估计。 |
| • |
被认为不会少于一天，不会多于 40 天（对于 IT 项目而言）。 |
| • |
有成果丰硕的结果和交付内容。 |
| • |
能够被完成，而不会有较大的中断。 |
| • |
可以被分配给一个人负责其完成。 |
| • |
要比其他的更能够分解为特定的层次。 |
| • |
能够把高风险的活动分解为其他低风险的活动。 |
| • |
除了最上面的一个或者两个层次，要使用一个动宾短语来描述任务。例如，使用“设计数据库架构”，而不是简单地用“数据库架构”。 |
| • |
以大纲的形式包括三到五个层次。 |
| • |
WBS 会在项目过程中反复发展，但是会在规划阶段中定型。 |
从下到上的估计
IT 项目的估计应该由那些日程安排里规定的人员来进行。从下到上的估计是对来自多个小组成员的估计进行开发和集成的过程。它带来了下列好处：
更高的准确性。 由那些专门人员作出的估计要更加准确，因为进行估计的人员具有从事类似工作的经验。
责任。 开发自己工作估计的人会感到他们对自己工作的责任更大。他们也会对成功达到自己作出的估计感到更大的责任。
赋予小组权力。 拥有由小组开发的日期而不是由管理指定的日期会赋予小组权力，因为日程安排建立在小组成员能够接受的实际估计之上。
集成小组估计
每个小组领导及其子小组，对准备完成其角色领域里的交付内容所需的时间估计负有职责。例如，开发领导会为开发人员准备估计；用户体验领导会利用来自小组的信息为用户体验 (UE) 交付内容准备估计等等。
程序管理角色会推动小组估计过程，并把所有的估计集成（“累积”）成为一个主日程安排和预算。
软件项目的估计
IT 项目的成本在很多程度上由劳动成本构成，所以对工作努力的估计是获得成本和日程安排估计所必需的数据输入信息。
设置正确的预期
估计会为未来的某种结果设置一些预期。由于这个原因，设定一些关于估计准确性的正确预期与生成预期所需要的技术一样重要。程序和产品管理角色群必须努力工作以确保下面这些内容的共同预期：
估计要依靠规范。 开发 IT 解决方案和自定义建造一个房屋很相象。在特性被仔细定义之前就了解其成本是很重要的。这不是说规范就是项目估计所需要的所有东西。其它的工作项目，例如客户沟通、项目会议、状态报告等，都需要花时间，而且必须在估计里予以考虑。
为折衷做好准备。 利用折衷矩阵来讨论折衷三角形和设置默认的优先权有助于小组和客户设置共同的预期。
某些不精确是无法避免的。 由于解决方案的开发是一个不断改进的过程，所以估计包含有一定的变动空间。
在每个里程碑处重新估计。小组应该随着项目的进展而提供一系列经过更多改进的估计。
不确定性和估计的准确性
软件估计是一个渐进的改进过程。图 7 说明了所谓的软件估计的“不确定性圆锥”（估计会聚）。在项目早期，对真正成本的估计的变动范围还非常广。这个范围会随着项目的推进而逐渐变小。
要注意的是，在前景／范围认可里程碑处，估计可以低两个数量级，或者高 0.5 个数量级。所显示的特定数据值取自于 20 世纪 90 年代中期的调查数据，它们不应该被过于生搬硬套地使用。重要的是理解在每个阶段数量级的变化。
这里所要学习到的知识是，在构想阶段，小组会制定出时间和成本的估计范围（有时候也叫做“球场估计”）。一定不要在这一阶段提供一个固定的成本估计或者固定的日程安排估计。需要弄清楚的是，这些估计在构想／范围认可里程碑处可能会因为某个重大的因素而发生变化。
来源： 摘自 Boehm 及其他作者的 "Cost Models for Future Lifecycle Processes: COCOMO 2.0"， 1995 (iv)。
位于任务分解最底层的估计
在任务层次准备工作估计的方式有多种。所有的方式都会从把 WBS 里的每个任务分解成为更小的活动开始。这在子小组层进行，并由每个小组领导来协调。
然后，会生成一个针对每个最底层活动的估计。这些估计会被集中到一起，在 WBS 里创建一个任务估计。
检查先前项目里的真实数据是为估计设定基准的最好方法之一。聪明的组织会收集和分析这些数据。很多项目活动都有行业标尺，能够提供好的衡量基准。
一项更加准确且值得推荐的技术是对每个低级别的活动都生成三点估计。三点估计包括对应于每个任务的一个乐观估计值、一个不利估计值和一个最有可能的估计值。应该有一个标准来明确这些值都意味着什么。不利估计值不应该意味着它是所有可能方案的最差的。乐观和不利估计应该要基于合理的和可能的风险。
一旦低层次的活动汇总成为了 WBE 层次的任务，每个任务就有了三个层次的估计值。小组领导会把这些信息转交给程序管理用于成本分析，然后使用估计数据来准备日程安排。
PERT 分析
一旦所有任务的估计被集中成为了 WBS，程序管理（或者专门的项目经理）会用统计分析来调整整个时间估计。完成这一个目标的技术有多种，但是最常用的一种是 PERT（程序评估检查技术）。PERT 会用到三点估计，并计算分布的平均值。这会被用来规划最有可能的结束日期，而不是最有可能的估计值。它还会根据关键路径上所有任务的变化提供多种估计结果。
对 PERT 的完整描述不在本文的讨论范围之内。但是项目管理工具，例如 Microsoft® Project®，提供了进行 PERT 分析的能力。
计划安排建议
计划安排管理包括确保项目按期完成所需的过程。
任务排序
一旦项目的任务和活动被归档进入了 WBS 并进行了估计，它们之间的依赖性就会被识别。例如，如果描述某个特性的职能规范没有完成，那么该特性的用户文档草案也无法完成。应该在任务的最小级别来识别依赖性。
时间搏击
使用内部时间限制来保持项目小组在指定特性和活动优先顺序上的压力 — 叫做“时间搏击”。这不应该被随意用来减少小组的时间估计。正确的“时间搏击”要从合理的时间估计和对某些特性可能需要被裁减掉以满足时间限制的理解开始。
任务驱动的日程安排
风险最大的高优先权特性或者组件应该被计划安排在项目的早期。这可以把响应问题的可用时间最大化。
管理缓冲时间
要增加缓冲（额外）时间来制定项目日程安排，从而允许小组能够应付无法预料的问题和变化。所要应用的缓冲时间量取决于风险的量。通过在项目早期进行风险评估，就可以估计最有可能发生的风险对日程安排的影响，并使用缓冲时间来补偿。
考虑缓冲时间的一种方式是将其作为对未知任务和事件的估计。无论小组的经验有多丰富，不是所有的项目任务都是可知的，都是可以事先进行估计的。但是，可以肯定的是，有些项目风险将会发生，并对项目产生影响，响应风险所需要的修正行动将需要额外的时间。
推荐对缓冲时间使用下面的指南。
| • |
不应该通过填充个人任务的估计来增加缓冲时间。由于工作会按照日程安排来扩展并填充完成它的时间（一种叫做帕金森氏法则的效应），缓冲会被计划内的任务所吸收，而不是计划外的任务。 |
| • |
缓冲时间也应该纳入日程安排，就像任何任务一样。一般来说，缓冲时间会在主要的里程碑，尤其是后来的一些里程碑之前立即就被分配。它总是应该被放在项目的关键路径上。关键路径是项目里相互依赖的任务的最长链，并直接决定着项目的持续时间。 |
| • |
随着缓冲时间在项目过程中不断扩展，剩下的时间量应该由程序管理仔细地跟踪和保存。由于缓冲是共享的，所以它只能够根据请求来分配。 |
| • |
如果加入了资源，或者从项目里取消了一些资源，不要用缓冲时间来补偿。如果这样做了，那么补偿风险的能力也会相应地降低。要使用折衷三角形来协调特性、资源和日程安排。 |
| • |
如果整个缓冲时间已经被使用了，那么就要确保整个小组都知道任何中断或者延迟都有可能带来”级联“效应，并危及结束日期。 |
结论
MSF 提供了一种可伸缩的方式，确保从非常小的项目到极其庞大和复杂项目中的项目管理职能都能够得到满足。这种方法避免了小型项目中过度的官僚作风，同时为大型的、更加复杂的项目提供了合适的管理结构。
