导读：文中介绍对于项目管理的一些技能改进之处，可以提高管理的效率巧妙之处，并详细的列举出管理中的十个过程。

　　小型项目的管理者并不需要过多的项目管理知识和项目管理技巧的训练。但是，一旦项目的规模变大了，这些正规的管理过程和技巧就是

　　项目管理者必备的了。虽然不同的项目管理方法以不同的方式组织并且说明了这些项目管理过程，但是我们还是想强调其中最基本的10个过程：

　　1. 定义项目范围

　　2. 制定工作计划

　　3. 管理工作计划

　　4. 问题管理

　　5. 范围管理

　　6. 风险管理

　　7. 沟通管理

　　8. 文档管理

　　9. 质量管理

　　10. 度量管理

　　一般来说，如果你能掌握这10个领域的知识，你就能在大部分的项目管理中获得成功。对于小项目，你可能不需要为文档或是度量管理而担心。但是，你管理的项目越大，你就越需要重视这10个过程的管理。

　　你可能已经注意到我们列出的10个管理过程中没有包括分析、设计、测试或者部署。那些有些项目工作经验的人也许知道一个项目通常会包括分析和测试过程。然而，实际上这些过程有很大的差别。分析和测试过程是实际项目进程(也称为项目生命周期)的一部分。随着项目类型的变化，项目生命周期包含的阶段也不同。如果你的项目是一个具有完整的生命周期的项目，你也许就会执行从分析、设计、构建、测试到部署的全过程。而在其它类型的项目中，你可能只会涉及到其中某些阶 段。例如，如果你的项目是一个调查研究项目，你就不会涉及到部署的问题。如果你在做一项研究，在做完分析阶段的任务后，这个项目可能就会结束了。

　　我们还遗漏了什么?

　　两个管理过程有时也会做为基本的项目管理过程的一部分：人员管理、合同和采购管理。对于项目经理来说，人员管理是非常重要的技能，但是对于项目管理来说，它并不是必需的。毕竟，在任何对下级的管理中都需要涉及人员管理。这其中的区别就是，人员管理是一种项目“经理”需要具备的技能，而不是项目“管理”必需 的技能。

　　在我们这10个项目管理过程列表中也没有包括合同和采购管理。在大多数组织中，项目经理需要了解对合同和供应商的管理情况，但是他们并不对此负责。法律部门和(或)采购部门通常负责合同和供应商的管理。

　　时间安排和过程的顺序

　　除第一类和第二类——定义项目范围和制定工作计划——之外，这10个主要的项目管理领域并不是一个顺序执行的过程。从过程3到过程10，你可以按任意顺序来 执行。而且，实际上，它们在整个项目中都是并行的，并且是从项目开始到项目结束一直都在进行的。例如，如果项目出现了一个重要的问题，你就必须忽略掉问题出现之前、出现期间或是出现之后你使用的项目管理的其它过程，而马上使用问题管理过程。让我们来仔细看看每一个管理过程吧。

　　1. 定义项目范围

　　做 为一个项目经理，你必须在项目开始前确定项目的各项工作是容易被大家理解的，并且已经得到了项目发起人以及关键的项目利益相关者们的同意。你需要和发起人、项目利益相关人一起讨论这些工作，以确保项目团队和客户对于项目的交付物、项目完成的时间、项目的成本、项目执行团队、项目的完成方式以及最终获得的 利益达成一致的认识。

　　从项目管理的高层看来，定义项目工作的目的包括：

　　——理解项目目标、可交付物、范围、风险、成本、方法并且达成一致。这是定义项目工作中最重要的部分，并且大部分的时间都会花在达成一致上。

　　——判断初始的业务案例是否仍然是正确的。例如，一个需要花费1万工时的项目可能具有商业意义。但是，如果定义工作的过程过于详细，就会导致超过2万小时的精确估算时间，这样这个项目可能就不再可行了。

　　——确保那些你需要的资源在你需要的时候是可用的。

　　——制定一个高层次的项目基线。依靠这个基线，项目相关人员可以比较各个过程的执行情况，也可以控制项目的范围。

　　——与客户在这个项目所使用的管理过程上达成一致。

　　需要花费在定义项目工作上的精力取决于需要让项目相关人员理解和文档化的信息量的多少。需要花费在定义项目工作上的时间取决于了解和文档化这些信息所必需的时间长短，也取决于需要花费在获得客户的同意和认可上的时间长短。

　　对于大型复杂的项目来说，准确的定义出最终的可交付物可能是非常困难的;估计出项目总成本和最终的交付日期也是很困难的。如果你管理的是大型复杂的项目，你可以把整个项目分成几个小型项目。在这些小项目中，需要先做的小项目应该更容易定义出它们的各项工作。那些在未来需要完成的小项目可以在快执行的时候再详 细定义出各项工作。

　　在定义项目范围结束的时候，你应该制定出一份《项目定义》。这份文档从项目的目标、可交付物、范围、风险、交付日期和项目人员角色等各方面定义了项目的所有期望。这份文档应该在项目团队开始执行项目之前获得项目发起人和其他关键的项目干系人的正式批准。

　　2. 制定工作计划

　　在你定义项目的时候，你要确保和项目发起人在项目应该完成的所有工作内容上达成一致意见。在制定工作计划这一阶段，你将确定完成这些工作的方式。这就需要制定《项目计划》。根据项目的规模，你要采取不同的方法。例如，制定小型项目的工作计划可以使用像Microsoft Project这样的项目管理工具包、电子制表软件，甚至一张纸。

　　如果在你开始做计划的时候，你还没有可用的工作计划模板，你可以使用工作分解结构(WBS)。WBS是一种技术，它从项目的高层次将工作分解成越来越小的部分，直到项目管理者获得项目工作的完整视图。整个项目团队在此基础上一起工作。我建议将工作分解到较低级别，分解到完成每个不再分解的活动所需的时间不多于80小时，并且完成这个活动所需要的资源也是十分清晰的。

　　一旦你把所有的工作都分解成活动，你就可以将这些活动排个顺序并且确定它们之间的依赖关系。这时，WBS就转变为网络图(Network Diagram)。

　　然后，你需要给每个活动添加资源(即工作人员)。如果你知道某些资源的确切的名字，你可以以名字添加他们。如果你不知道，你可以使用通用名来占位。接着，你需要为每个活动添加工时及开始、结束日期。

　　现在，你的工作计划已经准备好了。你可以清楚地了解到你要完成的工作内容(《项目定义》)以及你要如何完成这些工作(《项目计划》)。

　　项目定义和项目计划之间的关系

　　你会发现，如果你不开始安排整个《项目计划》，你就不能完整的定义出《项目定义》。在许多情况中，你需要同步处理这两个可交付物。在你收集有关范围和可交付物的信息时，你需要制定一张时间表以便获得预估的工时和期限。当你把可交付物、范围、假设以及方法定义清楚时，你就会获得足够的信息以便制定《项目计划》 来预估预算、工时和期限。然后，你可以用它们来完成《项目定义》。

　　3. 管理计划

　　这时，你已经完成了项目定义和项目计划。主要的可交付物《项目定义》、《项目计划》已经准备就绪了。有些项目经理认为，完成了项目定义和项目计划意味着项目管理中最艰难的部分就完成了。实际上情况显然不是这样。

　　如果你不能持续更新项目计划，你永远也不会成为一个成功的项目经理。记住，项目计划只是一个可交付物。项目计划描述了需要完成的工作、各项工作的顺序、需要的工时数以及负责人，但是项目计划仅仅是你对于如何完成项目的某个特定时点剩余工作的最佳预测。

　　你的项目越复杂，随着时间的流逝，项目计划需要更新的地方就越多。做为一个项目经理，你必须要在一个不断变化的基础上(也许是每周一次)评估项目计划，判定项目的当前状况。

　　在每周一次的回顾中，你要在项目计划中更新已经完成以及正在进行的工作的当前状态。你要评估那些剩余的工作，看看项目是否可以按照初始计划中估算的工时、成本以及期限完成。如果评估的结果是，项目可以按照初始计划完成，那么你的项目目前状态良好。反之，你就必须实施纠正措施。

　　在所有管理项目的技能中，管理工作计划也许是最基本的一个。根据项目的实际情况，你可能要一直使用你的经验和创造力才能使得项目按预期完成。这个星期，你的项目可能还在按计划进行。下个星期，你可能就会遇到任务延期和其它问题。

　　如果处在关键路径上的某个活动延期了一周，你可不能傻坐着眼看整个项目延期一周。相反，你必须评估可用资源以及可能的选择，让项目回归正轨。如果你擅长管理工作计划，那么它将是项目管理中最具挑战和回报性的工作之一。如果你不喜欢做这些必需的细致工作，那么你会发现想要获得成功就太难了。

　　4. 问题管理

　　当某个麻烦阻碍了项目的执行，“问题”就出现了。没有外界的帮助，项目经理和项目团队无法解决“问题”。如果出现的是个严重的问题，你除了解决它别无选择。唯一的问题是你是否能够积极主动的使用问题管理，战胜犹豫不决以及无法确定如何解决这个问题的困难。

　　问题管理由两个重要的部分组成。首先要经历一个调查问题、确定问题对项目影响、考虑可选的解决方案以及带领团队在这种情况下做出最佳决策的过程。所有这些项目管理步骤都应该提前定义并且获得一致同意。这些步骤确保问题可以有组织地、尽可能快地被解决。

　　问题管理的第二个部分是使用特定的问题解决技巧。这包括一些我们熟悉的技巧，比如鱼骨图(Fishbone diagrams)、直方图(Pareto charts)和根本原因分析。你可能熟悉其中的一个或多个技巧，它们可以让你和你的团队理解问题的本质和原因、有哪些可行的解决办法以及哪一个解决办法是最佳的选择。

　　所有的项目经理都认识到的、一个非常重要的事实就是，解决问题需要有个过程，但这并不意味着你会成功地解决每个问题。有时，解决问题有很多方法，你的工作就是帮助找出哪一个是最好的。有时，一个重大的问题却没有好的解决方案，这时，你最好的选择就是要挑出一个方案，这个方案产生的危害最小或者这个方案在其它更差的方案中是最好的。虽然如此，问题解决过程和问题解决技巧会使你确定哪些选择是可用的，以便让你至少了解到后果是什么。

　　5. 范围管理

　　《项目范围》描述了项目的边界，定义了项目交付的内容、需要的数据以及受影响的组织。给定一组资源和时间，就可以交付无限的东西。

　　范围变化管理开始于范围变化定义。如果项目经理没有做好范围定义，那么在项目执行期间进行范围管理将非常困难。范围变化管理的目的就是要保护当前已获得批准的《项目定义》的可行性。一旦定义了项目，某种对于项目的期望就被设定了，随之会产生出相应的成本和时间表。在《项目定义》被提交和批准时，你和项目发起 人就把会这些期望记在心中。

　　在项目执行期间，可能会出现一些与初始的《项目定义》不同或者未包含在其中的需求。这种情况是能够预见的。如 果真的发生了，客户不应该期望这些需求在之前认可的资源和时间限制下也可以交付。如果需要把新需求包含进《项目定义》，那么项目团队要分析这些新需求，判断它们对项目的影响。然后，这些信息要得到项目发起人的批准。

　　记住，项目发起人是那个批准项目启动资金的人。因此，他或她应该也是那个批准任何项目定义变更的人。如果变更的商业价值足够高，那么发起人应该批准将这些新需求加入项目，同时要增加完成工作所需的预算和时间。然后，每个相关的人都要同意并且重新设定项目期望。

　　当然，有时情况并不会如此顺利。一般会出现下列问题：

　　超出范围：大规模的范围变更是很容易看出来的。然而，当变更很小时，有时你会发现你还没弄明白这些变更就把它们包含进项目了。“

　　超出范围”的意思是你接受了小变更，结果逐渐累积的小变更最后给项目造成了显著的影响。你和你的整个团队必须小心地对待项目范围变更，无论变更是大是小。

　　最终用户对范围的认可： 项目发起人是为项目付钱的人。然而，一旦项目开始，项目团队会花费更多的时间在基层客户和最终用户上。

　　有些项目团队成员认为，最终用户批准了范围变更就可 以了。事实并非如此。除非发起人已经明确地将批准权授予了最终用户，否则他们无权批准范围变更。他们可以提出范围变更的请求，但是只有具有资金权限的发起人才能批准增加的工作。

　　团队成员不明白自己的职责： 导致没能按期完成项目的一个普遍的原因是项目团队成员最终做了比实际所需工作更多的工作。例如，某个团队成员被要求去完成一份报告。在他或她正在撰写报告时，客户又要求了新的内容。这个团队成员试图满足客户，于是工作最终就延期了。这种情况一般发生在团队成员认为只有项目经理才需要担心范围变更。团队成员 必须明白控制范围变更是每个人的责任。

　　对许多不成功项目之所以不成功的根本原因分析的结果是它们的范围变更控制都比较糟糕。有效地定义、管理范围将增加你的项目符合期望的机会。