项目管理

第一步(最重要):如何处理好与上级,下属,同事,客户的关系

做项目远离家人、朋友而且天天加班很辛苦，如果PM再无法让大家快乐起来，也是一件麻烦的事情。

上级

同事

下属

用户PM在项目的某个阶段发邪火，PM们都遇到过吧。这个问题就一句话：有什么事情你给我说就好了，项目组的兄弟们很辛苦了，再错都不要再骂他们，有火对我来。

客户

第二步:掌握软件开发中的格言,哲理,寓言故事,要记下来,充实自己的语言技巧,因为自己有时候总是表达不清楚自己心里的话的意思

1历史经验已经证明，任何系统的平均生命周期大约为16个月，因此为未来做好规划很有必要。当你充分了解你正在做的事情后，实施的效率会更高。

2一套有效率的技术性架构设计将零件拼接在一起，它应该就像一台容易操控、价格合理的机器一样。我已经发现，架构设计如果基于“奥卡姆剃刀原理”(OcCAM's Razor)，那么它往往是最棒的，奥卡姆剃刀原理这个词语源于拉丁语，意为“如无必要，勿增实体”(Entities should not be multiplied unnecessarily)，即简单就是最好的。当考虑设计之时，要记住每个组织都有一些独特的程序，大部分的组织性程序都相当的普通，它们能够用可配置的通用解决方案来解决问题。很多架构可以利用购买以及将一些很小数量的部件组合在一起的方式来完成，而不是要重新发明一种结构。通过这种方法，你能够在很短的时间内，利用更少的成本，为你的客户提供一种优质、容易操控的产品。同样理念还适用于个体应用与架构的设计与开发。

项目管理 基本

理论

项目管理是一个综合类的学科，涉及多种知识领域：

　　　项目范围管理
　　　项目时间管理
　　　项目成本管理
　　　项目质量管理
　　　项目人力资源管理
　　　项目沟通管理
　　　项目风险管理
　　　项目采购管理
　　　项目综合管理

项目管理软件

1基本功能

　　1．成本预算和控制

　　输入任务、工期，并把资源的使用成本、所用材料的造价、人员工资等一次性分配到各任务包，即可得到该项目的完整成本预算。在项目实施过程中，可随时对单个资源或整个项目的实际成本及预算成本进行分析、比较。

　　2．制定计划、资源管理及排定任务日程

　　用户对每项任务排定起始日期、预计工期、明确各任务的先后顺序以及可使用的资源。软件根据任务信息和资源信息排定项目日程，并随任务和资源的修改而调整日程。

　　3．监督和跟踪项目

　　大多数软件都可以跟踪多种活动，如任务的完成情况、费用、消耗的资源、工作分配等。通常的做法是用户定义一个基准计划，在实际执行过程中，根据输入当前资源的使用状况或工程的完成情况，自动产生多种报表和图表，如“资源使用状况”表、“任务分配状况”表、进度图表等。还可以对自定义时间段进行跟踪。

　　4．报表生成

　　与人工相比，项目管理软件的一个突出功能是能在许多数据资料的基础上，快速、简便地生成多种报表和图表，如甘特图、网络图、资源图表、日历等。

　　5．方便的资料交换手段

　　许多项目管理软件允许用户从其他应用程序中获取资料，这些应用程序包括Excel、Access、Lotus或各种 ODBC兼容数据库。一些项目管理软件还可以通过电子邮件发送项目信息，项目人员通过电子邮件获取信息，如最新的项目计划、当前任务完成情况以及各种工作报表。

　　6．处理多个项目和子项目

　　有些项目很大而且很复杂，将其作为一个大文件进行浏览和操作可能难度较大。而将其分解成子项目后，可以分别查看每个子项目，更便于管理。另外，有可能项目经理或成员同时参加多个项目的工作，需要在多个项目中分配工作时间。通常，项目管理软件将不同的项目存放在不同的文件中，这些文件相互连接。也可以用一个大文件存储多个项目，便于组织、查看和使用相关数据。

　　7．排序和筛选

　　大多数项目管理软件都提供排序和筛选功能。通过排序，用户可以按所需顺序浏览信息，如按字母顺序显示任务和资源信息。通过筛选，用户可以指定需要显示的信息，而将其他信息隐藏起来。

　　8．安全性

　　一些项目管理软件具有安全管理机制，可对项目管理文件以及文件中的基本信息设置密码，限制对项目文件或文件中某些数据项的访问，使得项目信息不被非法之徒盗取。

　　9．假设分析

　　“假设分析”是项目管理软件提供的一个非常实用的功能，用户可以利用该功能探讨各种情况的结果。例如，假设某任务延长一周，则系统就能计算出该延时对整个项目的影响。这样，项目经理可以根据各种情况的不同结果进行优化，更好地控制项目的发展。

别人经验—问题解决

随着项目的深入展开，PM们面对的最多的问题大致有以下几种：

　　　1、进度计划得不到执行，项目开始延期；
　　　2、用户理由很多，总是不配合工作；
　　　3、需求变更；
　　　4、资源不足，人手不够；
　　　5、长期出差，项目组成员开始烦躁；
　　　6、用户PM由于项目的种种问题，开始郁闷，将邪火发到项目组成员身上；
　　　7、PM身兼数职，无法全心进行项目管理，项目组成员开始各自为阵；

面对这些问题，PM们改怎么办呢？一个问题一问题处理吧，还能怎么办？

　　1、项目开始延期，这问题太普遍，普遍的大家都觉得正常。但是做为PM还是要分析，导致项目计划延期的原因，至少在你的项目月报中要说清楚你的项目为什么延期吧？上面总结的2、3、4基本上都是项目延期的普遍原因。对于项目计划延期问题，建议PM们和用户PM做好沟通工作，属于用户方的问题要给他说清楚，必要的可以形成书面的东西给他。

　　2、这个问题最头疼。人家每个人都貌似很忙，没空配合你的事情，你怎么办啊？常规方案，针对问题开项目协调会，通过会议解决这个问题。当然了，开会之前PM们需要做哪些事情，我在上一个帖子中对于开会有专门的说明，这里不再罗嗦。如果前期的吹牛工作做的比较好，那么这时候用户PM通过官方手段无法协调的事情，你可以去试试看直接和那些用户沟通下，说不定你就说服人家配合你了。第三个办法，直接找厂领导，摆事实讲道理，让他来协调（找的领导一定要是“自己人”，找错人了不要怪我出馊注意。）

　　3、需求变更，痛苦的事情。在这个帖子开头的时候提过需求调研的过程中建议大家一个问题多问几个人，就是为了防止大面积的需求变更。真的事情来了，也不要骂娘了，骂了也不能让用户不改啊。需求变更问题，是个很大的话题，也不好说清楚具体怎么操作，才能解决问题。说说我对于这个问题的几个观点吧。

　　　A、面对需求变更，不要在第一时间发表任何看法。先把问题听清楚，然后“站在用户的角度去考虑为什么用户要这样要求”。
　　　B、从用户角度考虑清楚为什么这么要求了，再回头看看原来的需求是怎么提的，偏差在哪里，是需要配工作流还是需要客户化程序还是技术上实现困难或者干脆就是不能实现。
　　　C、有一个观点大家可以试着理解（纯粹个人观点，不同意要么扔砖头要么笑笑算了）：管理都是有出发点、管理的手段以及管理的目地的。其实每个业务流程就是为了实现管理目地的一种管理手段，那么对于需要变更的需求，我们可以从管理的本质上来分析问题。如果说现有的东西和管理的目地不冲突只是在手段上有差异，那么我们可以和用户商量这个差异是否可以换第三种方案来实现，这样用户的需求能满足，我的程序修改内容最少。

　　需要说明的是，这样的处理方法一般都是在处理需要程序规模性的修改的时候采用的（咱当年是做国产自主开发产品实施的，这样的事情太多，于是就自己找了一个处理这个矛盾的套路。），而且，如果决定和用户去这样研究问题，那么一定要保证你首先是一个合格的顾问——你要把用户的需求、业务本质都吃透了，才能和用户去研究变通的方案。

　　　D、如果你站在用户的角度分析了，得出的结论是修改，那么就去改吧；如果仍然觉得不需要修改，那么现在可以和用去商量这个问题了。记住，你分析改不改的理由千万不要是：工作量、技术问题、人手不够、以后再说……一定要站在用户立场去分析问题，最后让他自己得出你要的结论，这是最理想的结果。

　　4、内部协调的问题终于出现了，目前电力市场火爆EAM同样火爆，基本每个公司都面临人少项目多的问题，那么内部进行资源（人力资源）的争夺不可避免。做为PM向上级领导争取资源的时候，我的建议是：分析事实、计划、进度、目标以及你争取的资源完对成这个计划实现你的目标的影响。

　　5、PM做为公司指定的“项目的总经理”以外，更是项目组的老大哥。在做好项目的同时，更要关心关心手下的兄弟们。我的观点是，做为PM不是技术牛比就是顾问牛比，在项目组收入也应该是在前面的，那么就大方点，公司不报销就自己请客吧（或者AA），没事大家出去活动活动，放松下心情。做项目远离家人、朋友而且天天加班很辛苦，如果PM再无法让大家快乐起来，也是一件麻烦的事情。

　　6、用户PM在项目的某个阶段发邪火，PM们都遇到过吧。这个问题就一句话：有什么事情你给我说就好了，项目组的兄弟们很辛苦了，再错都不要再骂他们，有火对我来。

　　7、这是技术当家的PM最容易遇到的问题，随着项目的深入，任务分配下去就开始各忙各的，做为PM也不过多去过问，最后问题发生了就迟了（想起来雪上情人的一个关于项目组人员辞职的问题，关于这个问题，他的失职再怎么说也不过分 ）。不能说告诫，只能说建议各位技术出事并且同时在项目中做技术活的PM们，至少每天回宿舍要抽半小时时间和每个人沟通下，如果形成每日的宿舍项目例会那是更好不过了。

如何释放’问题’,把问题分不到客户,架构,上级,甚至是第九方,不要一个人扛一切

　　做为PM最重要的一个能力就是去“释放”问题，否则，所有问题都压在你身上，你再牛×你也会被压垮。那么，在项目开始阶段就和用户明确项目例会制度吧，有事情在会议中说清楚。

计划-三级管理

　a、对于项目进度计划的三级管理

　　三级管理是这样一个模式：长期里程碑、重点工作计划＋中期工作内容计划＋短期具体操作计划。这样的计划是一级对一级的解释与细化，这样就可以将一个漫长的项目过程通过合理的切割与组织，变成可以操作与控制的过程。通过短期计划的滚动编排，可以很容易发现项目存在的重点问题与急需解决影响进度的问题。

　　通过这样一个由粗到细，再由细反馈到粗的项目计划管理过程，做为项目高层管理者可以很轻松的得到有关项目进度的真实情况和存在问题。

　　对于三级计划的周期个儿建议：项目整体、月、周。

　　Joe Torre被视为是一位非常优秀的经理。很难想像，如果他没有一套相当周全的比赛规划，这位纽约人能够在10次比赛中9次取得胜利，并且获得6个AL锦标赛以及4个世界性系列比赛的冠军。这种计划不是针对年度比赛的，而是每一场比赛。

　　无论你是一位经理或者是一位选手，一名超级明星或者是一位业余玩家，你都要为自己近期和远期的比赛制定规划。你如何为今天进行规划?为这周?为今年?你如何完成这些目标?你应该问自己很多“做什么”以及“如何做”的问题。如果你是一名开发人员或者是一名网络管理员，你现在就需要培养自己的规划能力。如果你无法管理自己，你当然就会在管理别人或者复杂项目之时捉襟见肘。
　

项目报告与项目例会制度

　b、项目报告与项目例会制度

　　EAM项目周期不算太短的，那么PM们不要指望靠脑袋将项目中所有的事情都记在脑袋里面。通过阶段的做为项目小组官方发布的文件，将项目中的进度、成果和问题进行记录、发布是很重要的。

　　做为PM最重要的一个能力就是去“释放”问题，否则，所有问题都压在你身上，你再牛×你也会被压垮。那么，在项目开始阶段就和用户明确项目例会制度吧，有事情在会议中说清楚。

　　建议：在正常情况下实施方项目组每周都有内部报告，发布对象就是双方项目组。整个项目官方的报告每月一个，对于特殊时期（上线过程，需求过程等）可以每周一个官方的报告。

　　例会可以跟着报告走。但是为了配合顺利，最好一周一次小规模的双方项目组例会，每月的例会需要邀请双方高层项目管理者（项目管理小组的领导）参加（现实的问题就是实施方的高层管理者会每月参加吗？）。

需求管理

　c、需求管理策略

　　谁也不希望需求变化，更不希望同样的一件事情，三个用户给了你三个“必需按我的要求来修改”的需求。对于这种你往左他往右的需求，可能是PM和顾问们最头疼的事情。很可能就是今天改过去明天该回来。

　　当项目确定了项目《需求报告》或者《项目解决方案》后，双方项目经理可以坐下来明确一个可控、可追溯的需求管理方案，保证所有的需求变更都是“有人承担责任的”。

　　没有规矩不成方圆，在项目开始阶段明确了计划管理、工作管理和需求管理的方法，我想PM后期需要去协调的工作会少很多的。

　　前面说了项目开始要注意的东西，协调过程中的一些事情，以及如何给项目一个合理、有效的轨道让用户能够配合实施方PM的工作，让项目在友好和合作的氛围中前进。随着时间的推移和实施的深入，项目自然会到了需要准备验收的时候。

验收时遇到问题及解决

　　今天就说说有关项目验收的问题吧。

　　项目何时验收、如何验收这可能是PM们被直接领导、老板们问的最多的问题，也是很多PM们很头疼的问题：用户平时配合的挺好，怎么一说准备验收了，什么都不好了，什么都要等等再说了……借口多的很，就是不配合你验收。诸如此类的事情，在项目验收过程都可能遇到。不验收用户不给钱，公司催死PM；要验收用户提了一堆问题，PM难死公司……面对验收工作，PM们该如何展开操作呢？

　　从个人一贯对于项目验收的理解来看，PM去操作项目验收工作是没有什么标准方法的。虽然项目验收的标准程序很多，很多地方都能看到：各类验收步骤、各类功能验证、各类文档、各类测试报告、各类手册、功能清单……别的地方都能看到的东西，所以这些不是我想说的。有标准的东西都是可循的、可以量化的，这些东西只要花点时间下去，都能准备完成。真正带给我们项目验收的压力的东西是那些非量化的东西：这个那个功能不符合要求、使用不方便；承诺的某某功能没有实现；与合同、投标文件对比还有×××功能没有实现（这些功能很可能是售前、销售为了拿单子不管死活的写上去的。）；系统才上线×个月问题还没有暴露，再等×个月验收也不迟……这些东西PM们该如何应对呢？

　　在继续开始之前，要说明一个问题。

　　关于项目，我们可以去追求完美，但是考虑到给我们发工资的老板的心情，所以，在研究项目验收这个问题的时候，让我们先把做个完美的项目这个念头扔到别的地方，重点去关心如何让一个项目在大家都能接受的底线之上去验收。

　　事实上，项目验收应该从PM接到项目的第一天，从看招标文件、投标文件、技术协议那天就开始准备。道理很简单：PM之后做的所有工作就是要完成这个项目，所以从这天开始PM就要为项目验收而准备。

　　看招标文件、投标文件、技术协议不是去弄明白要做什么事情，而是要“清楚的知道那些用户要求的东西、公司承诺的东西、合同里写清楚的东西，在事实上是无法实现或者在成本分析中实现这些东西是不划算的”。这些东西PM要明确的把他们从这三份合同相关的文件中识别出来，然后去和销售经理、售前顾问聊聊，看看这些东西都是怎么跑到合同或者标书里面去的，那些是可以去考虑回避的，那些是用户很关心，需要去考虑实现的。

　　行了，弄清楚这些事情之后，组织好你的小组成员和顾问，把这些东西说清楚，考虑好需求调研的时候对这些问题采用何种方式去调研之后，可以着手准备项目启动会（第一次设计联络会）了。

　　其实，做项目的过程，就是去将那三个文件（再罗嗦一次：招标文件、投标文件、技术协议）逐渐衰减的过程，当PM所担心的问题都“合理”的衰减了（合理是很重要的，有时候老板们会用一些“粗鲁”的方法解决问题，表面看暂时解决问题，事实上后遗症很厉害。），那么项目也可以验收了。但愿这个表述，大家能理解。
PM如果能抓清楚影响项目未来发展和验收的主要问题，那么就需要在前面讲的协调、沟通过程（就是我说的吹牛过程，鉴于大家的理解有误，我改正为协调、沟通）中一点一点去把握用户对这些问题的心态和想法，然后加以诱导和说服。感觉条件具备的时候去选择一个合理的方式去将这些心中的石头释放掉。

　　有那些合理的方式呢？

　　会议显然是首选了。需要考虑清楚的就是会议的主题是什么，不要傻傻的去开有关功能、需求变更为主题的会哦，这会吓到用户的。关于开会的问题前面也说了很多，就不多说了。需要注意的就是选好主题，然后把你想实现的事情合理的安排进去，并讨论通过。

　　第二选择就是个别沟通了。每个功能点总有核心用户部门的，那么就去和这些部门的领导去沟通、协调吧。

　　还有第三种好办法吗？那就是希望用户不要提这些问题了。但是谁能保证他现在不提，你准备验收的时候不提呢？装傻，不是好办法。还是主动去排雷比较好，免的炸的时候你很惨。

　　把那些麻烦的需求都合理的处理了，那么面对验收我们还要做什么？

　　分布验收，分模块验收是个比较好的策略。古话说一口吃不成胖子嘛，那就慢慢吃吧。分步、分模块验收从用户心理来说压力相对较小，就是一个模块，验收了你也跑不了，给你签字的可能性很大。当然了，事情都是两面的。分模块验收是容易，那么需要考虑以下问题：

　　a、模块验收了，用户来新的需求，做还是不做？

　　b、模块验收的功能显然不会是三个文件规定的全部东西，如何保证在总体验收的时候用户不和你回头算旧帐？

　　说个一家之言：做电力项目，只要钱没拿到手之前，所有的签字都是假的，千万不要以为签字了就万事大吉了。曾经有PM向我说：怎么能这样，原来都签字了，现在怎么又变了，怎么签了字都不算？我说：你怎么办？去他办公室哭能解决问题不？

　　c、签字验收的人，对于项目的最终验收是否具备绝对的发言权？人家弄个副主任给你签模块验收，等最后发飙的时候主任去，一句：模块验收的事情我不知道，我今天提的问题你们必需做到，要不我不签字验收，谁要验收谁去签字。能气的你想把你的IBM扔过去。

　　不管怎样，事情做的差不多了，项目也超期了，总是要验收的。

　　上面那个兄弟说了，提前吹风是很重要的。这小风慢慢的吹，一个人一个人的吹，争取在吹风的时候把问题都提前了解清楚，然后找合理的理由去说服吧。

　　现在能不能验收了？估计还是比较悬吧？总有不好摆平的用户的，跟你叫上劲了也不是什么奇怪的事情。那么就上下活动，团结可以团结的力量，判断清楚问题和形势后开个验收预备会吧。

　　你不给我验收，那么我要求开个预备会“诚恳”并且“认真”的听用户的意见和问题，并给出一个解决问题的时间表，在这个时间表内，谁不配合、谁不能完成任务都要有相应的处理办法。我曾经利用中午吃饭的时间和电厂一把手聊天，除了没说项目的事情，聊了很多话题，还记得有：应用数学是什么专业，能做什么；拉普拉斯方程；电网潮流计算；电厂主辅分离好不好；他们电厂有没有必要成立检修公司……。一直聊到下午上班，然后跟到办公室跟他谈预备会的事情，最后要了他一句话：开会的时候我肯定最后发言，你说什么我强调什么，怎样？

　　开会的时候，厂长还多说了一句话：“人家D经理在这边很久了，也很辛苦，我认为他们的工作很有成绩，今天人家也拿出最后的验收计划了，态度非常好。今天我还要说的就是，那个部门不配合××公司技术人员，导致计划不能完成，到了时间你们那个主任不签字，我来签字验收，验收完了我再找你算帐。”听了这话，心里那个爽啊。当天没有加班，晚上喊小组兄弟们出去喝酒。

　　个人认为，预备会是个比较好的处理方法。行了，预备会也开了，问题都说清楚了，能不能验收了？

　　答案是还有可能出什么鬼问题导致用户提出来不验收，对于老PM，遇到这样的问题不奇怪吧。怎么办呢？相信通过前期的沟通什么的，PM对用户的心里底线应该都能把握了，而且前面你也做了这么多工作了。就差最后一点了，不解决不急死人啊？
备忘吧！我都做了这么多事情了，最后这一点你还担心我不做？但是，说好的要验收啊！总要让我给公司一个交代啊？而且，没按时验收，你（用户PM）这不也算没完成工作啊？要不咱各退一步，你给我验收了，我验收报告后面给你附个备忘录，我答应你做的都写里面去。

　　事情做到这份了，PM们项目验收了没有？

总结

通过一个项目从头到尾整个过程的简单解释，希望新的PM及技术转型的PM们能够从中间得到点自己需要的东西。也算我没有白花这么多时间去打字。

　　写了不少，回头再来提炼下：

　　项目开始阶段，分析清楚合同相关文件很重要，从中间发现以后需要注意的“特殊”功能要求；
　　在项目开始阶段和用户明确项目的管理体系：报告、例会、需求变更等；
　　排一个比你觉得能实现的计划周期压缩20％的总体计划；
　　根据自己的能力和优势选择一个理想的介入项目的方法：或者高调（这个不是太好玩）、或者认真、或者技术很好、或者理解行业需求……
　　开始阶段，多和用户沟通，不一定要有问题才去找用户，电厂的主管们大多时间还是教多的，多接触接触是好事；
　　刚开始的项目报告一定要言之有物，能客观反应问题（是用户的就指出来，是自己的错误也老实写上去），让用户领导觉得可以通过这样的形式了解项目情况，并愿意参加例会；
　　滚动计划一定要准确，不要滚来滚去，事情总完成不了，会导致用户对于你计划能力和做事能力的怀疑；
　　排雷工作早点做，不要等验收前3个月才想起来；
　　PM就是PM，不要再去做技术高手，对小组兄弟多些指导，少做点具体事情，多花点时间去考虑项目整体的事情；
　　对于验收，不要一根筋的去考虑，做多种方案准备，然后考虑清楚后再和用户去谈；
　　最后，关心项目组兄弟们的生活，人性化点。

项目管理 五大过程

1.启动过程
启动过程最重要的两个输出就是项目章程和项目初步范围说明书.项目章程最重要的除了委任项目经理外,就是要表达清楚为何要做这个项目(市场需求,商业目的,技术领先),另外项目章程里面也会涉及到干系人,粗的成本估算和进度里程碑等信息.项目章程可以由项目管理团队拟制,但批准一定在高层管理批准,因此说如果项目章程变更已经不属于项目变更控制范围了.

初步范围说明书基本包含了范围说明书涉及到的所有内容同时还包含了初步的WBS分解,因此到了范围管理阶段后会根据初步范围说明书去制定范围说明书和 WBS.初步范围说明书不能够理解为仅仅包含范围,而是包含了假设约束,风险,干系人,范围,交付物,粗进度里程碑, 粗成本费用估算等诸多内容.另外范围说明书一个重要内容就是验收准则和项目边界,除了说清楚做什么还要说明清楚不做什么,防止后期项目验收的时候扯皮.对于为何要在启动过程中增加项目初步范围说明的一个重点个人认为初步范围说明在这里包含了一个可行性研究的内容,如果双方在启动过程都无法达成一致就不用在进入到计划过程中了.

2.计划过程
首先我们来看对于范围管理,质量管理,人力资源管理,沟通管理和风险管理都有对应的子计划.而对于成本管理和进度管理则没有对应的子计划,但实际上这部分计划内容是存在的只是合并到了项目管理计划中.因此应该把项目管理计划理解为一个整合的计划.

对于计划过程,除了输出计划本身以外最重要的输出就是基准.基准是后面跟踪和监控的基础.对于范围管理而言由范围管理计划,WBS和WBS字典共同构成范围基准.对于进度管理计划则只有在进度表制定完成后才能够形成进度基准,由于进度基准应该存放在项目管理计划中, 因此需要对项目管理计划进行更新.对于费用管理,则在费用预算完成后才能够形成费用基准,也需要对项目管理计划进行更新.对于质量管理需要在质量管理规划过程中输出质量管理计划和质量基准.而对于人力资源计划和沟通管理计划则没有专门的基准可言,对于风险管理过程来讲一个重要的输出是风险登记册,风险登记册虽然算不上基准但确实后续风险跟踪控制的重要依据.

在这里有重要的概念是绩效衡量基准(performance measurement baseline),绩效衡量基准是项目管理计划的一个重要内容,包括了进度,成本和质量的基准. 也可能包含技术和质量参数.在这里重点是理解基准和度量基准的差别,重点区别在于各自所起到的作用,基准更多是用来控制变更,并作为下游执行的依据.而度量基准是用来和项目实际执行实际数据作比较,看项目是否满足绩效.

在计划阶段范围管理和进度管理是紧密结合的,因此范围基准是进行活动定义的重要输入.对于活动持续时间估算而言除了要考虑使用什么资源外还需要考虑资源的费用,因此活动费用估算也是活动持续时间估算的一个重要输入.在这里对网络图不能简单理解为了活动排序完成就能够形成完整的网络图,完整的网络图包含了持续时间和关键路径的计算.这样在制定进度时候才能够进行网络分析和关键路径分析.另外网络图和关键路径还形成不了最终的进度表,我们还需要资源日历,进度的压缩和资源的平衡.只有充分考虑了这些因素后才可能形成合理的进度计划出来.

3.执行过程
执行的依据是什么呢?基准是执行的依据.而如何去执行则定义在项目管理计划或相关的子计划中.执行过程组一共只有7个过程,一个是整体管理中的指导和管理项目执行.另外是实施质量保证,项目团队组建,项目团队建设,信息发布,询价和卖方选择.
任何执行过程都存在两个方面的输入,一个是根据原来的基准来执行.另外一个就是要根据监控中发现的变更来执行,但主要变更必须要得到了整体变更控制批准后才能够执行.因此批准的纠正措施,预防措施,变更请求,缺陷补救等都是重要的执行输入.在这里要注意的是质量保证过程,质量保证中有质量审计,需要对依据实施的各种变更或纠正措施进行确认.因此质量保证的输入是已经实施的变更请求,纠正措施和预防措施而不是批准的.

4.监控过程
监控过程需要回答三个问题,我如何进行监控(计划来回答),根据什么来监控(基准来回答),实际信息如何获取(绩效来回答).通过这三个问题基本上就理解清楚了监控过程的输入.在这里需要搞清楚绩效报告和工作绩效的区别:工作绩效+基准 = 绩效报告.因此说工作绩效仅仅是简单的度量数据的收集,而绩效报告是需要和基准进行比较和分析,得出实际的进度和成本的领先或滞后情况(EV分析).现在还无法理解清楚的是为何进度控制输入只有绩效报告,而质量控制输入只有工作绩效.

整体变更控制是一个重要的过程,其输入和输出都很好理解,主要是对请求的变更,推荐的纠正或预防措施进行批准.因此该过程可以输出批准的变更请求和批准的纠正措施.但关键点在对于干系人管理过程,除了可以输出已解决的问题外,也可以输出批准了的变更请求和批准了的纠正措施,对于这种批准是否走了整体变更控制在这里暂时无法搞清楚.
对于缺陷的发现一般是属于质量管理的范畴,因此监控项目工作和实施质量控制才会输出推荐的缺陷补救措施.

5.收尾过程
收尾只包含项目收尾和合同收尾两个过程组.收尾包含了行政收尾和合同收尾,收尾首先要完成所有的相关活动,发布与收尾相关的报告.然后再收尾外部供应商的合同.更新组织过程资产并释放资源.