项目管理知识点学习总结

简介: 项目管理知识点学习总结

未经允许不得转载:

8-31:

今天讲解的内容是项目的特性。什么是项目呢?项目是为创造独特的产品,服务或成果而进行的临时性的工作。这句话概括了项目的两大特性,项目是临时性的工作,项目可以创造独特的产品、服务或成果。因此,项目具有临时性,项目具有独特性。凡是满足了这两个特性的任何事情,我们都可以把它当作项目来进行对待。临时性意味着项目有明确的开始和结束,这个叫做项目的有始有终。独特性是因为项目可以创造独特的产品,服务或成果。而产品服务或成果又可以叫做可交付成果,所以可交付成果是独特的。

可交付成果不仅仅是有形的,它还可以包括一些无形的:你提供的一些服务、或者是掌握了一些知识、你发表了一篇科学论文、研发出了一些研究成果,这些都可以叫做项目的可交付成果,因此可交付成果可以是有形的,也可以是无形的。这些都是项目创造的结果,正因为项目的结果具有独特性。导致了项目的过程存在不确定性,因此项目要做好风险管理。

第三个特性是项目的渐进明细性。渐进明细是指你掌握的信息越来越多,估算越来越具体,而不断的持续改进和细化你的项目管理计划。项目管理计划又叫做项目的行动方案。在项目的早期,你只掌握了一些项目粗略的信息,只能制定一些简单的项目管理计划,而随着你对项目了解的越来越多,信息越来越准确具体,不断的会去更新修改你的项目行动方案,导致项目管理计划不断的去更新、调整和计划。这个叫做项目的渐进明细性。

所以我们可以发现,不仅仅是工作当中,而生活当中的项目也无处不在。办公室装修可以是一个项目,举办婚礼可以是一个项目,哪怕在家炒一道菜,也可以把它当做项目来进行对待。这也是PMI给我们灌输的理念,一切皆项目,事事皆项目。

 

9-1:

今天我们来说说项目集管理。项目集是一组相互关联且被协调管理的项目、子项目集和项目集活动,以便获得分别管理所无法获得的利益。怎么解读它呢?它是一组有关联性,有依赖性的项目。放在一起管,好处最多,利益最大化。比如说有人来参加英语培训,完了之后考雅思考托福,这是一组项目集。培训是为了考试,而考试又依赖于培训。这样放在一起做可以使得利益最大化,称之为项目集管理。所以,项目集管理有两个关键词,第一关联性,第二依赖关系。所以项目集是多项目,但是多项目不一定是项目集,它有可能是项目组合。

 

9-2:

今天我们来解读项目组合管理。项目组合是指为实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。项目组合当中的一组项目为了实现同一个共同目标而把它放在一起管。但是,这些项目不一定彼此间有依赖关系,或者是直接相连。可能没有关联性,也没有彼此依赖,只是为了实现同一个目标。它只关注谁的优先级更高,就把资源优先分配给谁。比如说在组合当中有三个项目:a,b,c。如果a的优先级更高,资源先给a,bc就没有那么多的资源。如果c的优先级最高,资源先给c,ab没有那么多的资源。公司的资源是有限的,去得了某一个项目,其他项目可能没有那么多的资源,所以他们彼此竞争。我们在公司企业当中,一定要想办法提高自己项目的优先级去获取更多的资源。

我们再总结一下什么是项目集管理。有一组项目有关联性,有依赖关系,这是项目集管理。如果有一组项目没有关联性,可能没有依赖关系,彼此还竞争资源,这是项目组合管理。那么项目集是多项目,但是多项目不一定是项目集,它有可能是项目组合。

 

9-3:

今天我们来聊一聊项目的生命周期。什么是项目的生命周期呢?项目的生命周期,它是指从启动到收尾的一系列的阶段,把一个项目划分为若干个阶段来进行管理,可以是两阶段,三阶段,四阶段,或者是多个阶段。每一个阶段都是一个子项目,因为每一个阶段都有开始,有结束,它具有项目的临时性。但是PMbok里面会有一个通用的项目生命周期的划分。它认为,在大多数的情况下,大多数的项目可以划分为四个阶段来进行管理:启动项目阶段,组织与准备阶段,执行项目工作阶段,结束项目阶段。

每一个阶段都以重要的可交付成果的移交作为阶段结束的时间点。比如说章程交付了,我们就认为启动项目阶段结束。项目管理计划交付了,组织与准备阶段结束。验收的可交付成果移交了,执行项目工作阶段结束。存档的项目文件交付了,那么结束项目阶段结束。那么,这若干个阶段之间会有怎样的关系呢?一般来说有两种:顺序关系和交叠关系。第一种顺序关系:前一个阶段完全结束了,后一个阶段才能够开始。比如说考试注册完全结束,考试的交费才能够开始。第二种交叠关系:前一个阶段的工作还没有完全结束的情况下,后一个阶段的工作就开始了,多个阶段的工作并行执行,同时开展。这增加了项目的风险,增加了项目返工的机会。

 

9-4:

今天来说一说事业环境因素。事业环境因素是团队不能够控制但是会对项目造成影响限制的各种条件。它可能提高项目的灵活性,也有可能限制项目的灵活性,对项目造成消极或者是积极的影响。比方说天气,它对于施工项目来说就是一种事业环境因素。团队不能够改变它,但是对你项目的进度会造成影响。

事业环境因素是你不能够改变的,比方说组织文化、组织结构、设施、基础设施,比方说IT硬件,可用性,性能等等,还有一些信息技术软件,公司的项目管理软件,工作授权系统等等,以及员工的可用性,资源的可用性,员工的能力等等,这些也都是事业环境因素。比方说一家公司只可以和这家供应商合作,那么这种就是资源的可用性,你不能够改变又必须选择它,通通都叫做事业环境因素。

 

9-5:

今天我们来说一说组织过程资产。它是在管理项目的过程中积累的知识和总结的经验教训以及遵循的流程政策,它从哪来呢?它和事业环境因素不一样,它一定是公司内部不断总结获得的。

组织过程资产包括了两部分,流程与程序共享知识库。比如说公司制定的各种标准、政策以及各种模板、合同模板、风险登记册模板,你可以对它进行各种参考,还有各种控制程序、变更控制程序、风险控制程序。比如说你的项目要进行变更了,变更按照什么流程来进行,风险要进行管控了,风险管控按照什么流程来进行?

另外一部分是共享知识库。共享知识库,又叫组织知识库,它也是内部不断总结获得的。当我们做完每个项目的时候,需要总结经验教训,更新组织过程资产。当下一个项目启动的时候,需要参考组织过程资产,避免犯同样的错误。组织过程资产,你可以选择用或者是不用,但是事业环境因素,你不能够对它进行选择,必须面对。

 

 

9-6:

我们今天来说一说组织结构。组织结构有三类:职能型、矩阵型、项目型。矩阵型又可以再细分为弱矩阵,平衡矩阵,强矩阵。

职能型组织:传统的组织结构,每个部门都有职能经理。把员工按照专业来划分为部门,员工只要向自己的顶头上司、职能经理汇报工作。这种组织结构有清楚的上、下级的汇报关系,但是跨部门沟通非常的困难。

弱矩阵型组织:项目经理的权力小于职能经理。出现了联络员、协调员来帮助跨部门间的沟通。

平衡矩阵型组织:项目经理的权力几乎等于职能经理,他与职能经理共同掌握项目的预算。员工有两个老板:职能经理和项目经理,所以这种组织结构沟通很复杂,管理难度大。但是这种组织结构,人力资源的使用效率比较高,因为员工既参与了本职工作,又可以参与项目的工作。

强矩阵型组织:项目经理的权力大于职能经理,他的顶头上司不再是职能经理,而是项目经理的经理。并且他一个人全盘掌握项目的预算,项目经理全职工作。而在职能型弱矩阵、平衡矩阵,项目经理是兼职的,但是到了强矩阵型组织,他是全职工作。

项目型组织:项目经理最大程度的掌握了项目的团队,员工只需要向自己的顶头上司,项目经理进行汇报工作。所以,这种组织结构沟通容易。但是,在这种组织结构,员工缺乏事业的连续性和保障,资源配置重复,使用效率会比较低下。

 

9-7:

各位清晖的小伙伴们,大家好,欢迎来到每日“清”听~

今天我们来介绍一个服务性的机构:项目管理办公室,英文缩写叫做PMO。PMO的作用是对与项目相关治理过程进行标准化,并促进资源方法论、工具和技术共享的一个组织部门。这句话什么意思呢?它的意思是说,项目管理办公室参与项目的治理,并且制定项目管理的标准、制定项目管理的流程,还能够把资源在多个项目之间进行共享,把好的方法论、好的工具和技术进行共享的一个部门。

那么,PMO根据企业的所需要,可以设置在不同的层级,比如企业层级、事业部层级和项目组层级。所以它的职责可大可小,根据PMO的一个权力大小,我们把PMO分为三种类型:支持型、控制型和指令型。

权力最小的叫做支持型,几乎没有什么权利担任的是一个顾问的角色,它可以给项目提供支持,可以提供项目管理的模板,一些最佳实践,可以给项目经理提供指导、辅导、培训和监督。

权力居中的是控制型,既可以给项目提供模板,提供最佳实践、提供培训、提供监督,也可以有一定的权利控制单个项目。

权力最大的是指令型,直接管理项目,直接控制项目的一个交付,他对项目的结果负责任。

所以我们总结项目经理和PMO,它有什么样的差异呢?项目经理关注的是单个项目的目标,而PMO关注的是多个项目的目标,管理多个项目的变更;项目经理控制的是单个项目的资源,而PMO关注的是优化利用多个项目的资源;项目经理管理的是单个项目的制约因素,比如说项目的范围、进度成本质量风险等等,而PMO是站在企业的高度对多个项目的制约因素进行负责,它可以参与项目组合的管理。

 

 

9-8:

今天我们来说说项目经理的权力。权力,它有很多种来源,来自于职位、人生或者是人际互动,PMbok当中提到了14种权力,我来重点说说其中的五种:专家权力、奖励权力、正式权力、参照性权力、惩罚权力。

第一种专家权力,作为技术或者管理方面的专家而产生的权力。比如,医生对病人的权力,医生对于病人来说,它是医学方面的专家。

第二种奖励权力,来自于项目经理的职位。如果下属表现优良,你可以对他进行奖励。

第三种正式权力,也叫合法权力,来自于项目经理的职位。有权力做出某种决定,但是项目经理的正式权力往往是不足的,因为我们默认在矩阵组织当中工作,项目经理会受到职能经理的制约。

第四种参照性权力,参照性权力又可以细分为两种,暗示权力以及威望或魅力。第一个暗示权力基于项目经理与职位较高者的关系。别人信任你、欣赏你,以你为榜样是因为你和高层的关系比较好;第二个威望或魅力,比如说你有漂亮的外貌,拥有人格的魅力,能够吸引到别人。

第五种惩罚权力,如果下属表现的不好,项目经理对他进行处罚,扣工资、扣奖金等等。

那么,我们现在总结五种权力,专家权力,参照性权力来自于项目经理的个人。奖励权力,正式权力,惩罚权力来自于项目经理的职位。

好了,我们今天就讲到这儿,明天再见咯~

 

9-9:

我们今天来说说项目的章程,任何项目都需要制定项目的章程,章程是为了给项目立项,确立项目的正式地位,并且还能够给项目经理进行授权,授权他在组织中使用资源。所以章程有时候又叫做项目批准书、立项书、立项报告等等。一般是由项目的发起人发布的,他会对主要可交付成果、里程碑以及每位干系人的角色和职责达成共识。

因此,章程里面会包括很多内容,它一共会包含12个内容,里面都是宏观的、大概的、一些方向性的内容。包括项目的目的、可测量的项目的目标、高层次的需求(高层次的需求就是宏观的需求、大概的需求、不是很具体的一些需求),还有高层级的项目描述边界以及主要的可交付成果(它里面都是大概的一些边界,以及一些主要的可交付成果,并不是全部的可交付成果),整体的项目风险(也是大概的一些风险),总体的里程碑进度计划(大概的里程碑进度计划)以及预先批准的财务资源(大概的预算),关键的干系人的名单,还有项目的审批要求、项目的退出标准(在什么样的条件下才能够关闭项目,或者是取消项目,也会在章程里面写清楚),以及委派的项目经理的权责和职权,还有项目的发起人以及高级管理层的姓名也会写在章程当中。

所以章程当中的内容都是宏观的,大概的,大体上的,战略上的一些内容并不是特别的具体。因为做项目是越来越清晰,渐进明细的,所以一开始在章程当中并不会特别的明确。

 

 

9-10:

我们今天来说说项目管理计划。项目管理计划是一份综合性的计划,指导项目如何执行,如何监控,如何收尾,是项目的行动方案。它包含了三部分内容,十个子计划,三大基准以及其他组件。子计划当中的十个子计划与知识领域完全吻合。比方说范围管理知识领域对应了需求管理计划和范围管理计划,进度管理知识领域对应了进度管理计划,成本管理知识领域对应了成本管理计划,质量管理知识领域对应了质量管理计划,以及后面的资源、沟通、风险、干系人以及采购。

项目基准当中又有三大基准:范围、进度和成本。把范围、进度和成本三合一又成为了绩效测量基准。所以要看一个项目的绩效,一个项目的状态,不仅仅看范围、进度或成本,而是三合一。既然叫做基准,说明你不能随便的改。如果要改基准,需要走正式的变更管理流程才能对基准进行更改。第三部分其他组件又包含了变更管理计划,指导项目如何进行变更管理。配置管理计划指导项目如何进行配置管理。项目采用什么样的生命周期,迭代、预测还是适应型,那么还有开发方法,管理审查等等。

 

 

 

9-11:

各位清晖的小伙伴们,大家好,欢迎来到每日“清”听~

我们今天来说一说开工会议:它的英文是Kick-off meeting。有时候中文翻译为开踢大会,开球大会,启动大会。就好比足球比赛开场之前,每位教练都会在更衣室对他的足球队员进行一个战略战术的宣贯。虽然它也翻译为启动大会,但是这个会议并不是在启动过程组召开的,它属于规划过程组。它是项目管理计划制定完,执行之前召开的。召开完启动大会之后,那么项目就顺利的进入了执行过程组。

启动大会有哪些干系人参与呢?比方说项目的发起人、项目经理、项目团队、客户、高级管理层等等,都会邀请来参加本次的启动大会,邀请众多的关键干系人来参加本次的启动大会。在启动大会上面,获得团队对本次项目的承诺,以及要告知每位干系人他们的角色和职责。它也是一个宏观的、务虚的会议。什么叫宏观务虚呢?不干实事,不做太过细节的事情。实际上,这个启动大会就是让大家互相见个面,熟悉一下对方,让每个人都知道自己在项目当中该干什么?然后互相沟通一下,鼓舞士气,并且在项目启动大会上面,项目经理会向项目团队展示项目管理计划,获得关键干系人对项目管理计划的正式认可。

 

 

9-12:

我们今天来说一说变更请求的四种类型。PMbok里面提到了四种类型的变更请求:纠正措施,预防措施,缺陷补救和更新。

先说一说两个比较容易混淆的:纠正措施和缺陷补救。纠正措施是指现在你和原计划做的不一致。比如说进度落后了,但是还没有造成严重的后果,或者是产品的质量缺陷,只是和原计划有一些不一致。那么,现在你需要进行纠偏,让它回到原计划,与计划保持一致。进度落后了,我采取一定的措施让它回到原计划,回到原来的轨道,这个叫做纠正。缺陷补救是指已经引起了严重的恶果,导致最终的产品有质量问题,这是一个缺陷,因此要进行补救。所以纠正措施和缺陷补救,它的区别就在于,纠正措施没有引起质量问题,没有引起缺陷,没有引起严重的后果。而缺陷补救是指一定是导致了质量缺陷、质量的问题、质量不一致。

第三个预防措施。它是指你现在和原计划保持一致,没有偏差,但是你为了确保未来也不产生偏差,做了一定的措施,对未来做防范。所以,纠正措施和预防措施它的区别在哪呢?纠正措施是指现在已经产生了偏差,然后给它进行纠正。预防措施是指现在没有产生偏差,预防未来出现差错。

第四种更新。它是针对受控文件或计划的变更。对一些重要的项目管理文件以及项目管理计划进行的一些修改叫做更新。

 

9-13:

我们今天来聊一聊管理项目知识。管理项目知识是PMbok第六版新增的一个过程。它是指使用现有的知识来生成新的知识并且帮助组织学习的过程。知识管理最重要的是要管理显性知识和隐性知识。

什么叫做显性知识呢?能够用语言、文字、图片、数字进行表达的,容易储存的、理解的、易于沟通的,这些都是显性知识。比如说,你去图书馆看书,你上网获取一些资料,你听了一个讲座,你获取到的都是显性知识。可以通过言传的方式来获取。

什么叫做隐性知识呢?不容易表达的,难以传递的,难以理解的,只能通过自身的一些反思,思考一些心得体会,这个叫做隐性知识。比如你去听驾校学开车,怎么学开车呢?师傅会给你代教,他会告诉你一些规章制度,怎么开车的一些方法,技术。那你具体自己要怎么样学会开车,怎么把车开的好?是需要自己的勤加练习,对师傅说的话的一些反思和思考。还有你听了一次讲座,你能够接纳到的那些叫做显性知识,那这些知识你接纳到了之后。要通过自身的一些反思之后,你才能够学起来、用起来。那么,真正能够用得上学习上的总结出来的那些经验教训又叫做隐性知识。所以,在管理项目知识的时候,不仅仅要重视显性知识的收集,更加要重视隐性知识的收集。因为如果你不把这些隐性知识给收集起来,那么你的这些经验教训、心得体会可能就会流失了。

 

 

9-14:

我们今天来说一说项目信息。在项目管理的过程当中会产生项目的信息。在PMbok当中,介绍了三个非常容易混淆的概念:工作绩效数据、工作绩效信息以及工作绩效报告。

第一个工作绩效数据。从每个执行的活动当中收集到的原始的观察结果和测量值。比如说已完成的工作,进度活动的开始日期,已完成的故事点,可交付成果的状态,变更请求的数量以及缺陷数量等等。你计划第一天的缺陷数量为50个,而实际上,第一天产生了30个缺陷数量。那么30就是工作绩效数据。

第二个工作绩效信息。结合相关背景,对比整合分析而得到的,叫做工作绩效信息。原计划第一天应该产生50个缺陷,而实际只有30个缺陷,那么30是叫做绩效数据。对比发现,比原计划少了20个缺陷,那么这个20是你对比整合分析得出来的,这个叫做工作绩效信息。

第三个工作绩效报告。为了制定决策采取行动,引起关注而汇编了工作绩效信息所形成的一份正式书面的文档,叫做工作绩效报告。它比工作绩效信息更加的正式。它可能是状态报告、进展报告、正值图表、预测图、燃烧图,燃尽图等等。原计划第一天产生50个缺陷,而实际上却只有30个,对比发现比原计划少了20个缺陷。第二天发现多了十个缺陷,第三天多了15个,第四天多了20个。根据这样的一份趋势,我们写成一份状态报告。缺陷原因是什么?什么原因产生的?未来应该做怎样的改进,并且加入一些自己的建议,汇总写成一份状态报告,这个就是工作绩效报告。

 

9-15:

我们今天的话题是最终报告。它是4.7结束项目或阶段的输出文件,用来总结项目的最终绩效。项目最终的状态如何,都会体现在最终绩效报告当中。里面有范围的目标:项目该干多少活才能算是达到了完工标准;产品的目标:产品做到什么程度才算是合格;成本的目标:项目原计划应该用多少钱,以及实际用了多少钱,还有你成本发生的偏差原因;进度目标:花多长时间应该完工以及你实际花了多长时间。那么还有最终产品服务或成果如何满足商业计划或者是业务需求。以及在项目过程当中发生的风险、问题和解决方案。

那么,工作绩效数据,绩效信息和绩效报告体现的是某个时刻或某个阶段的绩效状态。而最终报告体现的是在阶段末或项目收尾的时候的最终绩效状态。

 

 

9-16:

今天我们来区分项目范围和产品范围。为什么要进行范围管理呢?要确保做且只做为完成项目而必须的全部的工作,保证既不多做也不少做。该干的活该做的工作叫做项目范围,干出的活叫做产品范围。我们只干该干的,那些在范围之外的,通通都不干。有时候,调整产品范围会引起项目范围的重大变化。比方说做一碗银耳莲子红枣羹,这是产品范围。验收标准是什么呢?100克银耳,100克莲子,10颗红枣,10颗枸杞,这个叫做验收标准。什么叫做项目范围呢?先把银耳放入温水浸泡30分钟,然后撕成小朵,再把银耳放入锅内,放入莲子,红枣,还有枸杞煮开,然后改用小火慢炖30分钟,最后加入冰糖。我所说的这些步骤就叫做项目范围。为了拿到银耳莲子羹而必须干的所有的工作,所有的步骤就叫做项目范围。

那么,如何衡量产品范围已经全部完成?需求文件当中的需求已经全部实现。如何衡量项目范围已经全部完成?项目管理计划当中的工作已经全部干完。

 

9-17:

今天我们来说说范围管理计划和需求管理计划的区别。5.1规划范围管理过程当中会输出两份计划,一份是范围管理计划,一份是需求管理计划。范围管理计划管范围,需求管理计划管需求。那么,什么是范围呢?项目团队该干的活该做的工作叫做范围。什么是需求呢?客户提的、干系人提的要求和期望叫做需求。

范围管理计划教你如何制定范围说明书,如何创建WBS,如何来维护范围基准以及如何验收可交付成果。如果范围说明书要发生变更,也要参考范围管理计划。需求管理计划教你如何分析、记录和管理项目的需求。如果需求要发生增加、删除和修改,也要参考需求管理计划。它们都是项目管理十个子计划之一,一个管范围,一个管需求。

 

9-18:

我们今天来说说需求跟踪矩阵和范围说明书。需求跟踪矩阵是收集需求的输出,虽然它作为输出,但是它可以当作一种工具来使用。它可以从项目的可交付成果一直追溯需求的来源,因此它又叫做需求追溯矩阵。在这个需求跟踪矩阵当中,里面会显示需求的多种属性,这个需求是谁提出的,什么时候提出的,那么这个需求,它会产生怎样的项目目标,它会交付怎样的可交付成果,这个需求如何做设计,如何做开发,如何最后测试。因此它可以在整个项目生命中期中,跟踪需求的一种工具。需求跟踪矩阵还能够确保每项需求在项目结束的时候都能够交付。比如有一位客户,他提了一项需求,那么你这时候能够拿出需求跟踪矩阵,告诉他这项需求,它对应了什么样的项目目标,产生了怎样的WBS成果,怎么样设计它,怎么样做开发,最后如何做测试。所以,项目经理可以通过需求跟踪矩阵来证明每一项需求都已经实现了商业价值,每一项需求我确实都已经交付了。

第二个项目范围说明书。它来自于定义范围的输出,它记录了整个范围,包括了项目范围和产品范围。这里面不仅仅记录了这个项目会产生怎样的产品,还记录了为了产生这样的产品所需要做的全部的工作。一般会包含四个内容:产品范围描述、可交付成果、验收标准和项目的除外责任。产品范围描述里面会记录:这个项目会产生怎样的产品,它的功能特性是怎样。可交付成果:每一个过程,每一个阶段,会产生怎样的可交付成果。验收标准:这些可交付成果需要满足怎样的验收标准。第四个项目的除外责任:整个项目中哪些工作该做,哪些不该做,明确范围的边界。

所以我们总结需求跟踪矩阵是用来记录所有的需求并且追溯需求的来源。那么项目范围说明书是指团队应该怎么做才能够满足项目的需求。

 

9-19:

我们今天来了解假设条件与制约因素的区别。假设条件是指那些在制定计划时不需验证,仍被视为正确、真实或确定的因素。如果这些因素不成立,可能造成潜在的影响,所以它是识别风险的一项输入。假设明天天晴,我们的施工项目就可以继续。那么,看一眼天气预报,发现明天下雨,说明假设不成立,因此可能对项目造成进度风险。所以它是识别风险的一项输入。所以假设就意味着风险。那什么是制约因素呢?在项目的执行过程当中,有影响的限制性的因素,比方说公司事先确定的预算、强制性的日期、进度里程碑、合同条款等等。在合同当中规定3月1号前必须完工。对于项目来说,它就是一个制约因素,通常不可变,因此它不能够渐进明细。那么,假设条件和制约因素都可以纳入项目的章程,也可以单独放入假设日志。

 

9-20:

我们今天来说说范围基准。范围基准,它是项目的三大基准之一。是由经过批准的范围说明书,WBS和WBS词典三位一体构成,缺一不可。既然能成为基准,那么说明它是一个标准,不能随意的更改。如果想要更改范围基准,需要走一个正式的变更控制程序,用来和实际的绩效做比较。

项目范围书是产品范围和项目范围的整体框架的描述,它描述了范围的边界。WBS是把可交付成果自上而下进行分解,用一个图的形式来进行展示。那么现在这个图如果比较模糊,看不懂的话,我们应该去看一份文字层面的描写,这个叫做WBS词典。所以,WBS词典对WBS提供支持。它里面会对WBS当中的每一个组件进行详细的描述。这个组建的编码,这个组件要做哪些工作,它的假设条件和制约因素,以及谁负责来做这件事情,它的进度里程碑,相关的进度活动所需的资源以及质量要求,验收标准等等。都会详细的记录在WBS词典当中。所以通俗的来讲,WBS词典是做什么的呢?因为WBS它只是一个视图,如果看这个图没有看懂怎么办?那么出来一个WBS词典,用来对图进行补充和解释。所以说,范围基准里的范围说明书,WBS和WBS词典三者缺一不可,构成了一个完整的范围基准。

 

9-21:

我们今天来说说可交付成果。可交付成果是4.3指导与管理项目工作的输出。它可以是有形的产品或者无形的服务、能力以及知识。它成为最终产品移交之前会经历几个过程。首先,经过团队内部的质量检验,确保它在技术上做的正确,成为核实的可交付成果。但是技术上做的正确,不代表能被客户或者发起人所接受。所以,会经过5.5确认范围,成为验收的可交付成果。验收之后,确认能被客户或发起人所接受,才会变成最终产品来做移交。所以,可交付成果会有四个状态。首先,4.3指导与管理项目工作输出可交付成果。然后经过8.3控制质量得到核实的可交付成果,说明技术上没问题做得对。做的对之后,再经过客户或发起人的验收,经过5.5确认范围变成验收的可交付成果。然后再经过4.7结束项目或阶段,成为最终产品服务或成果的移交。

那么,我们得出一个结论:验收并不在收尾的时候做,而是在监控的时候做。因此,收尾的时候不会做任何的技术验收,因此收尾又叫做行政收尾。

 

 

9-22

大家好,我们今天的话题是范围蔓延。什么叫做范围蔓延呢?未经控制的产品或项目范围的扩大被称为范围蔓延。比方说团队成员和某位客户的关系比较好,客户提出加功能。由于工作量比较小,不太花钱,也不太花时间,团队成员私自帮他增加了功能。第二次,第三次,如此重复多次,每次都帮他增加,由于工作量比较小而没有被记录下来,也没有走变更管理流程,私自帮他做功能上的增加。这种方式的变更你不易察觉,等到你察觉的时候,范围上已经发生了很大的变化。那么,这种情况就叫做范围蔓延,有时候翻译为范围潜变。那么如何杜绝这种情况的发生呢?有变更一定要走变更管理流程。范围蔓延是像镀金的一种形式,镀金是指画蛇添足而多做了一些不该做的工作。所以,在项目管理当中,反对镀金,因为它浪费了时间,浪费了钱。

 

9-23:

我们今天来说一说PMbok里面提到的依赖关系:强制性依赖关系和选择性依赖关系。什么叫做强制性依赖关系呢?有法律或合同要求,或者是工作的内在性质决定的,往往和客观的限制条件有关系,又叫做硬逻辑关系或者硬依赖关系。比如先报名才能够考试,你想要考试就必须先报名,这个是硬逻辑关系。那什么叫选择性依赖关系呢?基于具体应用领域的最佳实践。什么叫最佳实践?就是最好的做法,最佳的做法,你可以这样,可以那样,但是会有一个最佳的做法、最好的做法。不强制你一定要这么做,所以它又叫做首选逻辑,或者是优先逻辑,也叫软逻辑。那么学习的过程当中,是先看书后做题,还是先了解题目后看书呢?没有强制要求你一定要按照某种顺序来做,但是我们会有比较推荐的最好的做法,最佳的做法,最好采用某一种顺序:先看书后做题。所以这个叫做选择性依赖关系。

所以我们总结一下,强制性依赖关系是你无法改变的,它有客观的限制。而选择性依赖关系是你可以改变的,可以进行选择的。只是会有最佳的做法和最好的办法推荐。

 

9-24

我们今天来说说浮动时间提前量与滞后量。浮动时间有两种:总浮动时间与自由浮动时间。总浮动时间是指某个活动可以耽误一会、延误一会,不影响整个项目的完工时间。自由浮动时间是指某个活动延误一会、耽误一会,不影响紧后活动的最早开始。总浮动是指不影响整个项目的完工,它可以耽误的时间。而自由浮动是指不影响紧后活动的最早开始,它可以耽误的时间。一个不影响项目完工,一个不影响紧后的最早开始。

那么,什么是提前量呢?提前量是相对于紧前活动,紧后活动可以提前的时间量。出差前三天可以订机票,那么提前的三天就作为提前量。什么是滞后量呢?滞后量是相对于紧前活动,紧后活动需要推迟的时间量。晚饭后休息十分钟再去散步,那么休息的十分钟就作为滞后量。提前与之后一定是相对于两个活动之间的时间。但是,浮动时间是作为单个活动内部的机动时间。一个发生在单个活动内部,另外一个发生在两个活动之间。

 

标签: 项目管理

目录
相关文章
|
7月前
|
监控 项目管理
软件工程IT项目管理复习之 三:项目管理过程组:案例研究
软件工程IT项目管理复习之 三:项目管理过程组:案例研究
127 0
|
7月前
|
存储 监控 项目管理
软件工程IT项目管理复习之 七:项目成本管理
软件工程IT项目管理复习之 七:项目成本管理
135 0
|
7月前
|
监控 项目管理
软件工程IT项目管理复习之 十二:项目采购管理
软件工程IT项目管理复习之 十二:项目采购管理
242 0
|
BI 测试技术 程序员
【软件工程题库】第四章 概要设计
【软件工程题库】第四章 概要设计
2142 1
|
7月前
|
监控 项目管理
软件工程IT项目管理复习之 十一:项目风险管理
软件工程IT项目管理复习之 十一:项目风险管理
623 0
|
7月前
|
存储 定位技术 项目管理
软件工程IT项目管理复习之 十:项目沟通管理
软件工程IT项目管理复习之 十:项目沟通管理
124 1
软件工程IT项目管理复习之 十:项目沟通管理
|
7月前
|
项目管理 调度
软件工程IT项目管理复习之 一:项目管理简介
软件工程IT项目管理复习之 一:项目管理简介
97 0
|
7月前
|
监控 项目管理
软件工程IT项目管理复习之 四:项目综合管理
软件工程IT项目管理复习之 四:项目综合管理
79 0
|
7月前
|
测试技术 项目管理 数据库
软件工程IT项目管理复习之 五:项目范围管理
软件工程IT项目管理复习之 五:项目范围管理
111 0
|
7月前
|
监控 项目管理 调度
软件工程IT项目管理复习之 六:项目时间管理
软件工程IT项目管理复习之 六:项目时间管理
215 0