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