小型项目的管理者并不需要过多的项目管理知识和项目管理技巧的训练。但是，一旦项目的规模变大了，这些正规的管理过程和技巧就是项目管理者必备的了。虽然不同的项目管理方法以不同的方式组织并且说明了这些项目管理过程，但是我们还是想强调其中最基本的10个过程：
1.定义项目范围
2.制定工作计划
3.管理工作计划
4.问题管理
5.范围管理
6.风险管理
7.沟通管理
8.文档管理
9.质量管理
10.度量管理
一般来说，如果你能掌握这10个领域的知识，你就能在大部分的项目管理中获得成功。对于小项目，你可能不需要为文档或是度量管理而担心，但是，你管理的项目越大，你就越需要重视这10个过程的管理。
你可能已经注意到我们列出的10个管理过程中没有包括分析、设计、测试或者部署。那些有些项目工作经验的人也许知道一个项目通常会包括分析和测试过程。然而，实际上这些过程有很大的差别。分析和测试过程是实际项目进程（也称为项目生命周期）的一部分。随着项目类型的变化，项目生命周期包含的阶段也不同。如果你的项目是一个具有完整的生命周期的项目，你也许就会执行从分析、设计、构建、测试到部署的全过程。而在其它类型的项目中，你可能只会涉及到其中某些阶段。例如，如果你的项目是一个调查研究项目，你就不会涉及到部署的问题。如果你在做一项研究，在做完分析阶段的任务后，这个项目可能就会结束了。
你看出来我们还遗漏了什么吗？
有两个管理过程有时也会做为基本的项目管理过程的一部分：人员管理、合同和采购管理。对于项目经理来说，人员管理是非常重要的技能，但是对于项目管理来说，它并不是必需的。毕竟，在任何对下级的管理中都需要涉及人员管理。这其中的区别就是，人员管理是一种项目“经理”需要具备的技能，而不是项目“管理”必需的技能。
在我们这10个项目管理过程列表中也没有包括合同和采购管理。在大多数组织中，项目经理需要了解对合同和供应商的管理情况，但是他们并不对此负责。法律部门和（或）采购部门通常负责合同和供应商的管理。
时间安排和过程的顺序
除第一类和第二类——定义项目范围和制定工作计划——之外，这10个主要的项目管理领域并不是一个顺序执行的过程。从过程3到过程10，你可以按任意顺序来执行。而且，实际上，它们在整个项目中都是并行的，并且是从项目开始到项目结束一直都在进行的。例如，如果项目出现了一个重要的问题，你就必须忽略掉问题出现之前、出现期间或是出现之后你使用的项目管理的其它过程，而马上使用问题管理过程。让我们来仔细看看每一个管理过程吧。
注意：可以从这里下载PDF文件 下载.
#1: 定义项目范围
做为一个项目经理，你必须在项目开始前确定项目的各项工作是容易被大家理解的，并且已经得到了项目发起人以及关键的项目利益相关者们的同意。你需要和发起人、项目利益相关人一起讨论这些工作，以确保项目团队和客户对于项目的交付物、项目完成的时间、项目的成本、项目执行团队、项目的完成方式以及最终获得的利益达成一致的认识。
从项目管理的高层看来，定义项目工作的目的包括：
--理解项目目标、可交付物、范围、风险、成本、方法并且达成一致。这是定义项目工作中最重要的部分，并且大部分的时间都会花在达成一致上。
--判断初始的业务案例是否仍然是正确的。例如，一个需要花费1万工时的项目可能具有商业意义。但是，如果定义工作的过程过于详细，就会导致超过2万小时的精确估算时间，这样这个项目可能就不再可行了。
--确保那些你需要的资源在你需要的时候是可用的。
--制定一个高层次的项目基线。依靠这个基线，项目相关人员可以比较各个过程的执行情况，也可以控制项目的范围。
--与客户在这个项目所使用的管理过程上达成一致。
需要花费在定义项目工作上的精力取决于需要让项目相关人员理解和文档化的信息量的多少。需要花费在定义项目工作上的时间取决于了解和文档化这些信息所必需的时间长短，也取决于需要花费在获得客户的同意和认可上的时间长短。
对于大型复杂的项目来说，准确的定义出最终的可交付物可能是非常困难的；估计出项目总成本和最终的交付日期也是很困难的。如果你管理的是大型复杂的项目，你可以把整个项目分成几个小型项目。在这些小项目中，需要先做的小项目应该更容易定义出它们的各项工作。那些在未来需要完成的小项目可以在快执行的时候再详细定义出各项工作。
在定义项目范围结束的时候，你应该制定出一份《项目定义》。这份文档从项目的目标、可交付物、范围、风险、交付日期和项目人员角色等各方面定义了项目的所有期望。这份文档应该在项目团队开始执行项目之前获得项目发起人和其他关键的项目干系人的正式批准。
#2:制定工作计划
在你定义项目的时候，你要确保和项目发起人在项目应该完成的所有工作内容上达成一致意见。在制定工作计划这一阶段，你将确定完成这些工作的方式。这就需要制定《项目计划》。根据项目的规模，你要采取不同的方法。例如，制定小型项目的工作计划可以使用像Microsoft Project这样的项目管理工具包、电子制表软件，甚至一张纸。
如果在你开始做计划的时候，你还没有可用的工作计划模板，你可以使用工作分解结构（WBS）。WBS是一种技术，它从项目的高层次将工作分解成越来越小的部分，直到项目管理者获得项目工作的完整视图。整个项目团队在此基础上一起工作。我建议将工作分解到较低级别，分解到完成每个不再分解的活动所需的时间不多于80小时，并且完成这个活动所需要的资源也是十分清晰的。
一旦你把所有的工作都分解成活动，你就可以将这些活动排个顺序并且确定它们之间的依赖关系。这时，WBS就转变为网络图（Network Diagram）。
然后，你需要给每个活动添加资源（即工作人员）。如果你知道某些资源的确切的名字，你可以以名字添加他们。如果你不知道，你可以使用通用名来占位。接着，你需要为每个活动添加工时及开始、结束日期。
现在，你的工作计划已经准备好了。你可以清楚地了解到你要完成的工作内容（《项目定义》）以及你要如何完成这些工作（《项目计划》）。
项目定义和项目计划之间的关系
你会发现，如果你不开始安排整个《项目计划》，你就不能完整的定义出《项目定义》。在许多情况中，你需要同步处理这两个可交付物。在你收集有关范围和可交付物的信息时，你需要制定一张时间表以便获得预估的工时和期限。当你把可交付物、范围、假设以及方法定义清楚时，你就会获得足够的信息以便制定《项目计划》来预估预算、工时和期限。然后，你可以用它们来完成《项目定义》。
#3: 管理计划
这时，你已经完成了项目定义和项目计划。主要的可交付物《项目定义》、《项目计划》已经准备就绪了。有些项目经理认为，完成了项目定义和项目计划意味着项目管理中最艰难的部分就完成了。实际上情况显然不是这样。
如果你不能持续更新项目计划，你永远也不会成为一个成功的项目经理。记住，项目计划只是一个可交付物。项目计划描述了需要完成的工作、各项工作的顺序、需要的工时数以及负责人，但是项目计划仅仅是你对于如何完成项目的某个特定时点剩余工作的最佳预测。
你的项目越复杂，随着时间的流逝，项目计划需要更新的地方就越多。做为一个项目经理，你必须要在一个不断变化的基础上（也许是每周一次）评估项目计划，判定项目的当前状况。
在每周一次的回顾中，你要在项目计划中更新已经完成以及正在进行的工作的当前状态。你要评估那些剩余的工作，看看项目是否可以按照初始计划中估算的工时、成本以及期限完成。如果评估的结果是，项目可以按照初始计划完成，那么你的项目目前状态良好。反之，你就必须实施纠正措施。
在所有管理项目的技能中，管理工作计划也许是最基本的一个。根据项目的实际情况，你可能要一直使用你的经验和创造力才能使得项目按预期完成。这个星期，你的项目可能还在按计划进行。下个星期，你可能就会遇到任务延期和其它问题。
如果处在关键路径上的某个活动延期了一周，你可不能傻坐着眼看整个项目延期一周。相反，你必须评估可用资源以及可能的选择，让项目回归正轨。如果你擅长管理工作计划，那么它将是项目管理中最具挑战和回报性的工作之一。如果你不喜欢做这些必需的细致工作，那么你会发现想要获得成功就太难了。
#4: 问题管理
当某个麻烦阻碍了项目的执行，“问题”就出现了。没有外界的帮助，项目经理和项目团队无法解决“问题”。如果出现的是个严重的问题，你除了解决它别无选择。唯一的问题是你是否能够积极主动的使用问题管理，战胜犹豫不决以及无法确定如何解决这个问题的困难。
问题管理由两个重要的部分组成。首先要经历一个调查问题、确定问题对项目影响、考虑可选的解决方案以及带领团队在这种情况下做出最佳决策的过程。所有这些项目管理步骤都应该提前定义并且获得一致同意。这些步骤确保问题可以有组织地、尽可能快地被解决。
问题管理的第二个部分是使用特定的问题解决技巧。这包括一些我们熟悉的技巧，比如鱼骨图（Fishbone diagrams）、直方图（Pareto charts）和根本原因分析。你可能熟悉其中的一个或多个技巧，它们可以让你和你的团队理解问题的本质和原因、有哪些可行的解决办法以及哪一个解决办法是最佳的选择。
所有的项目经理都认识到的、一个非常重要的事实就是，解决问题需要有个过程，但这并不意味着你会成功地解决每个问题。有时，解决问题有很多方法，你的工作就是帮助找出哪一个是最好的。有时，一个重大的问题却没有好的解决方案，这时，你最好的选择就是要挑出一个方案，这个方案产生的危害最小或者这个方案在其它更差的方案中是最好的。虽然如此，问题解决过程和问题解决技巧会使你确定哪些选择是可用的，以便让你至少了解到后果是什么。
#5: 范围管理
《项目范围》描述了项目的边界，定义了项目交付的内容、需要的数据以及受影响的组织。给定一组资源和时间，就可以交付无限的东西。
范围变化管理开始于范围变化定义。如果项目经理没有做好范围定义，那么在项目执行期间进行范围管理将非常困难。范围变化管理的目的就是要保护当前已获得批准的《项目定义》的可行性。一旦定义了项目，某种对于项目的期望就被设定了，随之会产生出相应的成本和时间表。在《项目定义》被提交和批准时，你和项目发起人就把会这些期望记在心中。
在项目执行期间，可能会出现一些与初始的《项目定义》不同或者未包含在其中的需求。这种情况是能够预见的。如果真的发生了，客户不应该期望这些需求在之前认可的资源和时间限制下也可以交付。如果需要把新需求包含进《项目定义》，那么项目团队要分析这些新需求，判断它们对项目的影响。然后，这些信息要得到项目发起人的批准。
记住，项目发起人是那个批准项目启动资金的人。因此，他或她应该也是那个批准任何项目定义变更的人。如果变更的商业价值足够高，那么发起人应该批准将这些新需求加入项目，同时要增加完成工作所需的预算和时间。然后，每个相关的人都要同意并且重新设定项目期望。
当然，有时情况并不会如此顺利。一般会出现下列问题：
--超出范围： 大规模的范围变更是很容易看出来的。然而，当变更很小时，有时你会发现你还没弄明白这些变更就把它们包含进项目了。“超出范围”的意思是你接受了小变更，结果逐渐累积的小变更最后给项目造成了显著的影响。你和你的整个团队必须小心地对待项目范围变更，无论变更是大是小。
--最终用户对范围的认可: 项目发起人是为项目付钱的人。然而，一旦项目开始，项目团队会花费更多的时间在基层客户和最终用户上。有些项目团队成员认为，最终用户批准了范围变更就可以了。事实并非如此。除非发起人已经明确地将批准权授予了最终用户，否则他们无权批准范围变更。他们可以提出范围变更的请求，但是只有具有资金权限的发起人才能批准增加的工作。
--团队成员不明白自己的职责: 导致没能按期完成项目的一个普遍的原因是项目团队成员最终做了比实际所需工作更多的工作。例如，某个团队成员被要求去完成一份报告。在他或她正在撰写报告时，客户又要求了新的内容。这个团队成员试图满足客户，于是工作最终就延期了。这种情况一般发生在团队成员认为只有项目经理才需要担心范围变更。团队成员必须明白控制范围变更是每个人的责任。
对许多不成功项目之所以不成功的根本原因分析的结果是它们的范围变更控制都比较糟糕。有效地定义、管理范围将增加你的项目符合期望的机会。
#6: 风险管理
风险是指那些不在项目团队控制之下或是如果它们出现会给项目带来不利影响的未来的情况或环境。换句话说，问题是当前必须处理的麻烦，而风险一种潜在的麻烦。被动的项目经理在问题出现时解决问题。主动地项目经理在问题出现前，努力识别、解决潜在的问题。风险管理既是科学，也是艺术。
由于小型项目通常周期较短，出现问题的可能性就比较少。大型项目通常有隐藏的风险。风险管理包括识别出所有项目潜在的风险、确定它们发生的可能性，并且清楚地了解如果它们出现的话，对项目造成的影响。
依据这些信息，项目团队能够确定需要主动管理哪些风险。例如，一定要主动管理那些出现概率高且对项目影响大的风险，而可以忽略那些出现概率高但对项目影响小的风险。
一旦你识别出了需要主动管理的风险，你就可以使用下面这五个通常的做法：
--别管它。 如果你认为某种风险即使出现对你的项目影响也不大，或者没什么办法可以消除某种风险，再或者你愿意冒险赌某种风险不会出现，那么你就别管它了。
--监控风险。 在这种情况下，你无需主动降低风险，但是你要监控它，看随着时间的推移它发生的可能性增加还是减少。如果后来某种风险出现的可能性增加了，那么这时候团队就必须要想办法消除它了。
--避免风险。 避免风险意味着消除那些会引发麻烦的条件。例如，与某个特定供应商相关的风险可能在选择了其它供应商后，就可以避免了。
--转移风险。 在某些情况下，管理风险的责任可能会从项目组转移给其它实体或第三方机构。
--降低风险。 在大多数情况下，都应该这么做。如果已经识别出某个风险或是正担心某个风险，那么你应该制定一个主动处理的计划以确保它不会发生。
正如范围变更一样，一个项目不可能没有风险。客户也不会期望一个项目没有风险。问题是项目管理对风险的反应。如果进行了风险识别并且主动管理风险，项目就更可能会获得成功。如果忽略可能出现的风险，在风险转变成问题时，项目只能被动的受到影响。这时，可能只有很少的解决方法能避免项目受到影响了。
#7:沟通管理
在项目中，适当的沟通对于管理客户和利益相关人是至关重要的。如果客户和利益相关人们没能及时了解到项目的进展情况，那么由于他们对项目具有的不同期望值，可能会增加项目出现问题和困难的可能。实际上，在许多情况中，出现冲突并不是因为实际的问题，而是因为客户和管理者事先不知情。
项目中的沟通有两个层次。第一，所有的项目都应该沟通。第二，如果你的项目更大更复杂、或者与政治有关，那么你所要进行的沟通通常更加高级和复杂，因此你需要制定一个《沟通计划》。
项目状态会议和项目状态报告
所有的项目都需要有效地沟通，无论是从项目团队到项目经理，还是从项目经理到其他的利益相关人。项目状态报告和项目状态会议不仅仅是用来报告项目正常进展的，还有其他的事情要做。从项目状态报告和项目状态会议你可以了解到所有你需要知道的和项目有关的一切。你要沟通坚守项目预算及时间表的理念，要沟通在最近一次报告期内完成的工作，要沟通下一个报告期内计划完成的工作、新风险、当前的问题，以及当前的范围变更请求。
传递信息和讲话都必须考虑到你的观众。因此，你最好和你的项目团队每周召开一次项目状态会议，会议上应该包括一些非常细节的讨论。你发送给发起人和管理类利益相关人的状态报告一定要简短且高度概括。
沟通计划
重大决定，尤其是那种要求组织变革的决定必须包含一个全面的沟通计划，这份沟通计划将采取多种沟通方式。制定沟通计划的过程包括确认所有的利益相关人、确定他们需要获得的项目信息、集思广益分发信息的方式以及在充分利用资源的情况下与尽可能多的项目利益相关者进行沟通。
根据听众的情况，交流一般采取下面三种方式中的一种：
--强制性的：包括项目状态报告、项目预算报告以及已批准的需求。
--参考性的： 给相关人员提供进一步的信息。比如，文档库、常见问题列表以及包含相关项目信息的项目站点。
--营销性的： 这种类型的交流是为了增强大家对项目的热情。比如，出版项目成功经验、树立正面形象、分发管理推荐信以及使用项目标识。
项目经理必须主动掌控交流活动，必须有意识的计划并且执行交流活动。如果你的交流行为既有效又主动，那么你会发现整个项目运作将更平稳，并且遇到的冲突及障碍会更少一些。
#8: 文档管理
许多项目经理认为只有当项目中有几百份文档时才需要进行文档管理。实际上，更好的方法是预先估计一下你认为项目本身以及项目管理可能产生的文档资料的数量，建立一套适当的过程和规则来组织文档，并且在项目进行期间进行文档管理以确保文档不会失去控制。
小型项目的项目经理不需要太多考虑文档管理的问题。随着项目的规模逐渐变大，项目经理就必须要主动管理项目中的文档资料了。管理文档时可能遇到的最普遍的问题就是文档丢失了或难以找到，以至于在项目结束时要重新书写。最坏的一种情况是文档的版本失去了控制，文档的更新日期过期了、丢失了、混乱了或是无法确定了。
文档管理是项目管理的一个方面，可以使用像文档库这样的工具。然而，如果存储文档时没有使用适当的技术，以至于不能方便地存取文档，那么使用工具只能让问题更复杂。
文档管理既简单又复杂。简单的任务比如说文档命名约定。如果你的团队中有10个人，每个人每周提交一份状态报告，那么很快你就会有成百份的文档资料了。如果每个人都使用通用的命名规范，就很容易组织文档。那么，文档的名称应该以每个人的名字开头吗？如果这么做，每个人的历史状态报告会排在一起，很容易找到。
可能你想找到某个特定时点的状态报告。这时，状态报告就应该以时间开头。这样所有的状态报告就按报告周期排在一起。
文档管理的另一个方面是规定项目使用的文档管理工具。比如，你可能将Microsoft Word作为标准的文档编辑器。如果你的项目团队是跨职能的，包括客户、厂商、供应商，那么文档管理规则就更重要了。
要想使文档管理取得成功，有些其它的因素也必须考虑。比如，文档存储的位置、文档的组织方法、访问及安全规则、关键词或索引、命名标准、版本控制、完成状态、保留或销毁状态、备份以及标准模板。
#9: 质量管理
项目及可交付物符合客户需求和期望的程度体现了质量的好坏。换句话说，质量的好坏最终要由客户来评判。
项目组应该努力满足甚至超过客户的需求和期望。有时候，大家可能会认为高质量就意味着最好的材料和设备，并且零缺陷。然而，大多数情况下，客户不会期望而且也负担不起这样的完美解决方案。如果项目只是有一些缺陷的话，客户还是会认为交付的项目是具有高质量的。
换句话说，一个解决方案设计完美、毫无缺陷，但是并不符合客户的需要，那么这个方案也不是高质量的方案。从质量的观点看来，质量管理的目的首先是理解客户的期望。然后，制定计划及管理过程用以满足甚至超出客户的期望。
由于质量的高低是由客户来判定的，因此判定的标准看起来是相当的主观的。然而，对质量的评判也可以很客观。我们首先需要把“质量”这个一般术语分解成一些可定义质量特征。
比如，你可能认为计算机软件的质量应该按照响应时间、用户体验、易用性、帮助文档以及缺陷的多少来衡量。你一旦定义了可以量化的质量特征，你就可以判断它们是否可以客观的衡量质量。
质量管理不是一个单一事件：它是一个过程，一种思维模式。一贯高质量的产品不可能出自有缺陷的过程。你需要建立一个先衡量质量，而后改进过程的可重复的循环。
想要使质量管理过程正常工作，收集度量非常重要。因此，项目管理第九和第十个方面，也就是质量管理和度量管理联系非常紧密。如果你想做好质量管理工作，你就必须度量。
一旦项目完成了最初的定义，项目团队必须要按质量要求理解客户的期望，并且制定相应的《质量计划》来满足这些期望。《质量计划》要包含完整和正确的关键域，以便让项目团队了解客户对质量的期望。
《质量计划》也会包含两种通常的质量管理过程：质量控制和质量保证。质量控制活动确保项目提交的可交付物符合客户的期望。例如，检查那些用于完成最终可交付物的每个组件。质量保证活动确保用来创建可交付物的过程是高质量的。例如，在最终提交可交付物前，使用检查表检查必须完成的每个步骤是否都完成了。
质量管理的目的之一是可以尽早发现项目中的错误或缺陷。因此，好的质量管理过程最终会使得项目花费更多的工时和成本。然而，在项目早期就关注质量的话，会给项目带来巨大的回报。例如，在项目的分析阶段发现与业务需求有关的问题比在项目测试时发现遗漏了需求而返工效率高得多。再比如，在制造电脑芯片时发现芯片的问题比客户购买后带着电脑来更换芯片，制造商的成本要少得多。
#10: 度量管理
收集度量是最复杂的项目管理过程，可能也是最艰难的。因为度量既难定义也难收集，所以通常被人们忽略或处理得很拙略。所有的项目都应该收集一些基本的度量信息，比如成本、工时以及周期。然而，你也必须收集那些可以判断可交付物是否满足了客户的期望的度量，以及那些可以判断项目内部运作过程是否正常运转的度量。一旦决定了你需要哪种度量，你就可以开始相应的行动或过程改进行为了，这样可以使收集的过程更加高效。
度量管理和质量管理是有关联的。如果不收集这些度量，那么你很难提高交付物或执行过程的质量。度量通常被用来标示质量开始的状态以及质量是提高了还是下降了。
许多度量能够在项目中收集。项目团队应该定义并且组织一个能够提供最大价值的平衡集合。为了决定哪些度量适合你的项目，你可以：
--依据项目的可交付物和项目执行的情况识别出那些评判项目是否成功的标准。也就是说，确定出项目成功完成时，你的可交付物应该看起来像什么样。你还要确定出项目成功必须要考虑的一些东西，比如预算和交付日期。
--组织团队进行头脑风暴来收集每一个能表示项目成功的度量。
--寻找一个能够按照成本、交付情况、质量和客户满意度评判项目成功的度量集合。
--将那些以最经济的方式提供最大价值的潜在度量排在优先位置。
--设定能够使你成功的目标。度量很少单独产生价值。它的价值在于它能够衡量你是否偏离了目标。
--在工作计划中增加收集活动以确保有人负责度量的收集和分析。
一般说来，度量管理对于小型项目的价值不大，原因在于小型项目通常没有足够的时间来捕捉这些数据、分析结果以及做出适当的改进。持续时间较长的项目给了你使用反馈环的时间。如果将度量用于改进提升一个组织，那么使用度量就获得了最大的价值。
