MSF项目管理准则Word文档下载推荐.docx
《MSF项目管理准则Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《MSF项目管理准则Word文档下载推荐.docx（22页珍藏版）》请在冰豆网上搜索。
它的目的在于说明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。
图1：
MSF与项目管理准则的关系
查看完整的图像。
在这上面的图里，针对行业的领域是MSF过程的五个阶段。
针对行业的项目管理活动的一个例子是用于跟踪错误的推荐做法。
项目管理的一般知识领域在左边。
一个例子是用于管理合同或者跟踪预算的推荐做法。
交叉代表了特定的项目管理做法，后者是MSF的特征。
这些都会在后文进行描述。
MSF方法的这些与众不同的特征将在这里描述，并在后面进行更加详细的讨论：
项目经理角色的大多数职责都包含在MSF程序管理角色群里。
在需要MSF扩大小组的大型项目里，项目管理活动在多个层次发生。
某些大型的或者复杂的项目需要专门的项目经理或者项目管理小组。
项目管理角色包含在程序管理里
MSF程序管理角色群包括了下面所示的职能职责领域。
在小型项目里，所有的职能职责一般都是由一个程序经理来处理的。
随着项目规模和复杂性的提高，这一角色群分解成了两个专门的分支：
一个处理解决方案体系结构和规范，另一个处理项目管理。
程序管理如何与小组领导一起工作
要理解项目管理如何在MSF里工作，就有必要理解小组模型如何扩大规模、进行规划、通讯，以及决策。
关于这一点的更多信息，请参阅MSF小组模型白皮书。
如何去分布小组管理，在很大程度上要取决于项目的规模和复杂性。
MSF是一个高度可伸缩的框架，它能够被用在只需要两个或者三个人的小型项目里，也可以用在非常大型的项目里。
Microsoft内部的产品小组就涉及成百甚至上千个小组成员。
MSF已经把从Microsoft小组组织里学到知识进行了归纳，供更大范围的IT项目使用。
MSF的可伸缩性在很大程度上来自于小组模型。
小组模型可以以两种方式扩大规模：
1.
通过将小组角色抽象成为一套职能职责，而不是特定的职位描述。
通过这种方式，每个角色的职能就不会被限定到个人身上。
一个角色可以被扩展成为多个角色群，每个都专注于一系列目标更加明确的职责。
一个或者多个个人可以担当这些更加专业的角色。
2.
使用功能小组和职能小组的各种组合，以创建任意数量的可能的大型小组结构。
对功能小组和职能小组的描述见下面。
职能小组
职能小组是存在于一个角色内部的子小组，当一个角色里的任务达到要求使用专门资源的时候它才会被组建。
职能小组的一个关键方面并不简单的就是角色需要一个以上的人来担当，而是在其成员中有一个对任务的陈述。
图2是其中一个例子。
小组领导是大型小组其他成员的集成点。
小组领导在其子小组这一层次负有一些项目管理的职责。
图2：
负责用户体验的职能小组示例
功能小组
功能小组是跨学科的子小组，它们被安排在解决方案的特定功能周围。
功能小组由组成小组模型的六个角色构成。
图3显示了一个功能小组。
程序管理角色也是为大型小组提供集成点的小组领导。
功能小组的结构是远程或者“离岸”子小组（用于为解决方案构建相当分散的组件）的有力候选对象。
图3：
功能小组示例
扩大程序管理职能的规模
图4显示了如何在三个项目规模层次处理项目管理活动。
在项目A里，所有的角色都由大约六个或者更少的人来担当，所有的项目管理活动都由程序管理来处理。
这并不意味着其它的角色就不会为项目管理作出贡献。
事实上，这意味着他们在负责规划、时间估计和识别他们各自领域里的风险。
图4：
项目管理的可伸缩方法
在项目B里，大多数或者所有的角色都由子小组来担当，每个角色都有一个小组领导。
小组领导对其各自的子小组进行项目管理。
程序管理角色群拥有负责整个项目的项目管理活动。
要注意的是，功能小组没有在图上显示出来，但是它们也是子小组。
由于每个子小组都是跨学科的，所以每一个都有一个程序管理领导。
项目C和项目B类似，尽管它有与其规模或者复杂性相关的特殊风险。
复杂的项目，就像用在MSF里的一样，意味着项目具有与下列因素相关的高风险：
大规模或者高成本。
地理上分散的小组。
小组成员隶属于多个公司、组织或者分包商。
固定的或者高度受限的预算或者日程安排。
需要技能和时间来管理的合同或者法律问题。
为了降低这些风险，程序管理角色群有一个职能小组，它包括专门的项目经理和解决方案架构师。
要注意的是，风险的限度对于所有的组织和项目来说都是不同的。
对于某个组织来对成本非常高的东西对于其他组织来说可能未必。
这完全取决于项目早期进行的风险评估。
项目管理职责
上面一个章节讨论了如何把不同规模和复杂性层次的项目管理活动分布给各个小组成员。
本章就将描述这些活动。
图5描述了每个角色和程序管理的小组领导所具有的项目管理职责。
在复杂项目（例如图4里的项目C）里，专门的项目经理所关注里的领域与程序管理的相同，只不过是在一个独有的基础上。
要注意的是，相同的职责领域常常会由项目层和子小组层来负责。
图5：
小组领导的项目管理职责
小组领导
小组领导要为其子小组准备计划，以描述工作要如何完成，如何根据计划跟踪实际的工作，如何管理范围和变化，如何给子小组里的特定任务分配资源，以及如何协调子小组的内部沟通。
小组领导所进行这些活动都需要子小组各个成员的参与和输入。
在参与全部风险识别的时候，小组领导要专门负责识别其角色专长领域里的风险。
图5里有三个地方可以将小组领导的职责与其他成员的职责模式区分开来：
项目的成本管理一般都被作为程序管理职责集中到一起了。
把这些职能分布到领导身上将会分散大家的注意力，并可能引起混乱。
采购职责由程序和／或发布管理来处理，而不是由其他的小组领导来处理。
程序管理会处理项目以及多种采购服务的大多数合同事宜。
（把项目的一部分）分包一个Web设计公司，让其加入小组就是这样的一个例子。
发布管理作为小组IT操作的代表，会处理构建解决方案所需的以及小组开发和测试实验室环境所需的硬件、软件和设备等的采购工作。
3.
在整个项目层的沟通管理由程序管理和产品管理来共同承担。
产品管理会为客户、利益相关人，以及任何外部人员创建和交付沟通计划。
程序管理会规划和负责项目沟通，例如报告状态、主持小组会议，以及类似的事情。
沟通管理还包括小组以外的沟通规划、合同指定点的分配和过程的报告。
程序管理
除了负责高层的解决方案体系结构和编写职能规范（就如在小组模型里描述的那样），程序管理还拥有把项目作为一个整体的所有项目管理领域。
程序管理会把小组计划集成到主要计划里，同步日程安排，并管理跨小组的依赖性。
把解决方案设计的职责和职能规范放到同一个角色里作为日程安排和成本职责有一个巨大的好处：
它会打破相对于成本而言的设计过度的倾向与日程安排所暗示的之间的平衡。
大型、复杂项目里的项目管理
随着项目变得更大或者更复杂，它可能会取代管理职能规范、更新日程安排、发出小组沟通、报告过程和进行其他的项目管理活动。
要应付这个，把程序管理角色群的职责分割成解决方案体系结构和专门的项目管理角色常常是有道理的。
项目监督服务
在某些方面，一个大型的项目必须要做的事情和小型业务必须要做的相同：
跟踪财务、采购供给和服务、管理员工的业务、提供入门培训、安装小组工作设施等等。
在大型项目里，对状态、成本和日程安排的例行跟踪变得非常耗时。
为了让项目经理把精力放在最紧迫的问题上，更多日常的项目管理活动被委派给了项目监督（或者项目支持）角色。
项目监督服务还为小组领导提供了支持，帮助其维护小组日程安排和其他的管理活动。
客户的责任
客户常常想要一个实现整个项目成功的责任点。
有些组织希望项目经理来扮演这个角色。
有时候这在大型或者复杂的项目里会有保证，但是这种方法会使得小组角色责任失衡，从而导致项目表现不佳。
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里没有与之相对
升级会员 