• 读后感
  • 阅读答案
  • 导游词
  • 细则
  • 赏析
  • 案例
  • 规则
  • 简介
  • 试题
  • 试卷
  • 手抄报
  • 对联春联
  • 评语
  • 任命
  • 造句
  • 周年庆
  • 指导书
  • 论文
  • 日志
  • 说课
  • 评课
  • 采访
  • 资料
  • 剧本
  • 常识
  • 知识
  • 范例
  • 观后感
  • 墓志铭
  • 寓言寓意
  • 新闻稿
  • 公示
  • 步骤
  • 优秀范文
  • 方案大全
  • 笔记
  • 攻略
  • 俗语
  • 评价
  • 您现在的位置:书业网 > 范文 > 优秀范文 > 知识 > 正文

    项目管理10大知识领域

    来源:书业网 时间:2017-07-18

    篇一:项目管理十大知识领域之间的关系

    项目管理十大知识领域之间的逻辑关系

    项目管理最本质的内容就是整合管理,项目的范围、时间、成本、质量、人力资源、沟通、风险、采购与干系人管理等,都是为了最终实现项目的整合管理。这十大知识领导之间的逻辑关系可以描述为,在整合管理思想的指导下: 第一、 弄清楚项目的工作内容(范围);

    第二、 弄清楚这些工作要有什么时间完成(时间),以多大代价完成(成本),做到什么要求(质量); 第三、 弄清楚需要什么人力资源来完成项目,以及组织内部有没有这些人力资源(包括相应的知识与技能);

    第四、 如果没有足够的人力资源,就需要外包一些工作给其他公司或个人,从而就需要对采购及相应的合同进行管理; 第五、 项目所涉及的内外部的人力资源之间都需要进行有效沟通,才能较好的相互协调; 第六、 弄清楚哪些风险会促进或妨碍项目的成功,并积极加以管理;

    第七、 自始至终,都要进行项目干系人管理,以便了解干系人,引导干系人积极参与项目工作,并满足干系人在项目上的利

    益追求;

    这十大知识领导之间的逻辑关系,可以简单概括为: ● 整合管理是指导思想;

    ● 范围、时间、成本和质量管理是为了满足项目本身的要求(在规定的范围、时间、成本和质量之下完成项目任务); ● 人力资源、采购和沟通管理是保证项目达到要求的手段; ● 风险管理则是对所有工作的支撑,相当于项目管理大厦的柱子;

    干系人管理与每一个知识领导交叉,因为在做前九大知识领导的管理时,都要与干系人打交道

    篇二:项目管理5大过程9大知识领域44个定义

    项目管理的5大过程分别是:

    1)启动过程、2)规划过程、3)执行过程、4)监控过程、5)收尾过程 9大知识领域分别是:

    1)项目整合管理、2)项目范围管理、3)项目时间管理、4)项目成本管理、5)项目质量管理、6)项目人力资源管理、7)项目沟通管理、8)项目风险管理、9)项目采购管理

    44个定义分别是:

    项目整体管理

    1. 制定项目章程–制定正式核准项目的项目章程。

    2. 制定项目初步范围说明书–制定从高层次说明范围的项目初步范围说明书。

    3. 制定项目管理计划–将确定、编写、协调与组合所有部分计划所需要的行动

    形成文件,使其成为项目管理计划。 F

    4. 指导与管理项目执行–执行项目管理计划所确定的工作,实现项目范围说明

    书明确的项目要求。

    5. 监控项目工作–监视和控制启动、规划、执行和结束项目所必需的各个过程,

    以便满足项目管理计划中确定的实施目标。

    6. 整体变更控制–审查所有的变更请求,批准变更并控制可交付成果和组织过

    程资产。

    7. 项目收尾–最终完成所有项目过程组的所有活动,正式结束项目或项目阶段。项目范围管理

    8. 范围规划 制定项目范围管理计划,记载如何确定、核实与控制项目范围,

    以及如何制定与定义工作分解结构(WBS)。

    9. 范围定义 制定详细的项目范围说明书,作为将来项目决策的根据。

    10. 制作工作分解结构 将项目大的可交付成果与项目工作划分为较小和更易管

    理的组成部分。

    11. 范围核实 正式验收已经完成的项目可交付成果。

    12. 范围控制 控制项目范围的变更。

    项目时间管理

    13. 活动定义确定为产生项目各种可交付成果而必须进行的具体计划活动。

    14. 活动排序确定各计划活动之间的依存关系,并形成文件。

    15. 活动资源估算估算完成各计划活动所需资源的种类与数量。

    16. 活动持续时间估算估算完成各计划活动所需工时单位数。

    17. 制定进度表分析活动顺序、活动持续时间、资源要求,以及进度制约因

    素,从而制定项目进度表。

    18. 进度控制控制项目进度表变更。

    项目费用管理

    19. 费用估算估算完成项目各项活动所需资源的费用近似值。

    20. 费用预算汇总各单个活动或工作细目的估算费用,确定一个费用基准。

    21. 费用控制对造成费用偏差的因素施加影响,并控制项目预算的变更。

    项目质量管理

    22. 质量规划明确哪些质量标准适用于本项目,并确定应如何达到这些质量

    标准。

    23. 实施质量保证开展经过规划和系统化的质量活动,确保项目使用为满足

    要求而需要的所有过程。

    24. 实施质量控制监视具体的项目结果,判断这些结果是否符合有关的质量

    标准,并识别适当的方式消除造成实施结果不令人满意的原因。

    项目人力资源管理

    25. 人力资源规划明确、记载并分派项目的角色、责任和互相通

    报的关系,

    并制定人员配备管理计划。

    26. 项目团队组建取得完成项目所需要的人力资源。

    27. 项目团队建设提高团队成员个人的能力,改善成员之间的合作与配合,

    以便增强项目的实施效果。

    28. 项目团队管理跟踪团队成员的表现,提供反馈,解决问题,并协调各种

    变动,以便增强项目的实施效果。

    项目沟通管理

    29. 沟通规划确定项目利害相关者的信息与沟通需要。

    30. 信息发布为项目利害相关者及时地提供他们所需要的信息。

    31. 绩效报告收集与分发绩效信息,包括状态报告、绩效测量与预测。

    32. 利害相关者管理 对沟通进行管理,满足项目利害相关者的要求,解决他们

    提出的问题。

    项目风险管理

    33. 风险管理规划 决定如何对待、规划和开展项目的风险管理活动。

    34. 风险识别 明确有哪些风险会影响到本项目,并记载这些风险的各项特征。

    35. 定性风险分析 估计风险发生的概率和造成的后果,并将其结合起来,确定

    风险的重要性大小顺序,以便日后进一步分析或采取行动。

    36. 定量风险分析 在数值上分析已识别风险对项目总体目标的影响大小。

    37. 风险应对规划 对于为项目目标带来机会和造成威胁的风险,提出和制定可

    供选择的方案与行动。

    38. 风险监控 整个项目生命期自始至终跟踪已识别的风险,监视残余风险,识

    别新风险,执行风险应对计划并评价其有效性。

    项目采购管理

    39. 采购规划 确定购买或获取何物,以及何时以何种方式购买或获取。

    40. 发包规划 将产品、服务和成果要求形成文件并识别潜在的卖主。

    41. 询价 根据情况取得信息、报价、标书、邀约或建议书

    42. 卖方选择 审查邀约,挑选潜在的卖主并与卖主就书面合同进行谈判。

    43. 合同管理 管理合同与买卖双方之间的关系,审查并记载卖主过去和现在如

    何履行合同,据此确定必要的纠正措施,并为确定将来与卖主的关系奠定基础,管理与合同有关的变更,并在适当的时候管理同项目以外买主的合同关系。

    44. 合同收尾 完成并解决每一个合同,包括解决所有的未决事项,并结束每一

    个合同。

    篇三:项目管理知识体系中的九大知识领域

    项目管理知识体系中的九大知识领域

    九大知识领域,是项目管理知识体系的重要内容,涉及内容非常广泛,在这里将会把各个知识领域中的主要管理内容和关键点作一介绍,如需了解更为详细的内容,请参考PMBOK以及相关的专业论著。

    1.4.1集成管理

    集成管理是项目管理九大知识领域中的第一个领域,与其它八个知识领域相比,这个领域的内容比较特殊,它并没有提供具体的知识点和具体的操作方法,而是反复强调围绕项目的全局观,在项目内部各个部分之间、在项目内部与外部之间,对各种内容进行集成,使各个相关方面形成有机的整体,保持管理上的一致性。这个知识领域的内容对于项目经理们来说可能感觉比较空泛,但对于企业级项目管理体系建设来说,则是非常具有指导意义的。

    下面是项目管理中几个常见的集成方面的问题:

    1、将项目计划中各个管理领域的子计划综合而成整体的项目计划。例如在整体项目计划中,要包括范围管理计划、时间管理计划、成本管理计划、质量管理计划、人力资源计划、沟通计划、风险管理计划、采购计划等,将这些不同的管理计划有机的结合起来,使整体项目计划能够有效涵盖项目管理的各个领域的管理内容并保持一致.

    2、将项目的各个过程有机的集成起来。在后面我们会提到项目的五大过程——启动、计划、执行、控制、收尾。这些过程在整个项目当中,在项目的各个阶段当中,都可以根据管理的需要灵活运用,但是各个过程之间的关系仍然要符合基本的关系要求,这五大过程之间的关系会在后面的章节中进行介绍。

    3、项目管理与企业日常运营管理的集成。不论企业是以项目方式从事主营业务,还是利用项目从事改革、创新,都存在着项目与企业日常运营之间的关系。在项目过程中通常会占用企业资源,也会对企业的日常工作产生一定的影响,如何协调资源、配合工作,同时满足两方面的需要,这就是经常遇到的一种集成管理的要求。例如在创新活动中,项目会产出成果,可能形成面向内部用户或外部客户的产品,企业就要考虑围绕这些产品的销售、支持服务等一系列的企业运营中的问题,因此,企业往往在项目初期定义项目成果时,就要求考虑项目成果在以后的企业运营中的管理问题。

    4、项目生命周期与产品生命周期的集成。企业管理的核心内容都是围绕产品的(包括服务型产品),企业一定会对产品的生命周期进行管理,在产品的整个生命周期当中,产品的每一次进步,都是以项目的方式来实现的,从市场调研、可行性分析、产品设计、产品生产、市场促销、产品改进等各个不同的阶段,都可以单独成为项目。这时的项目的生命周期包含在产品的生命周期当中,项目的成果成为产品发展的阶段成果。因此,在项目管理中,还要同时兼顾产品长远发展的需要。

    5、项目范围与产品范围的集成。当一个产品由不同的部分组成时,每个部分都可以单独生产时,就一定存在着项目范围与产品范围集成的要求。例如在汽车装配厂,需要从许多不同的加工厂采购不同的零部件来进行装配,对于零部件加工厂来说,设计、改进零部件的创新项目,不能孤立的对待,而是要考虑该零部件与其它相关部分的配合关系,考虑对整车的影响。如果把整车涉及的全部零部件看作是产品范围,针对某个零部件的改进就是单个项目的项目范围,那么项目范围就应该与产品范围进行有效的集成。

    6、不同部门的成果的集成。当一个项目涉及企业内外多个部门和单位时,特别是当项目在企业中处于职能式或弱矩阵式组织结构时,通常会出现各个部门分头完成自己所分管部分的任务,将各自的成果提交给项目,那么在项目中就必须将这些成果集成在一起,形成项目的整体成果。

    7、项目中不同约束条件的集成。不同的利益干系人可能会对项目提出不同要求,各种各样的外部因素会对项目形成不同的约束条件,例如外部法规的强制性要求、企业内部的管理要求、不同领导和部门的限制性要求、内部资源自身的特殊要求、项目发起者对项目本身的相关要求等,为项目管理勾画出了项目的边界,这个边界就直接反映出各个方面的约束条件的集成结果。

    还有许多其它方面的集成问题,这里不能一一列举。由此可以看出,项目并不是孤立存在的,它受到来自项目内部和外部的多方面的影响,要管理好项目,就必须有很强的全局观。因此,在企业级项目管理

    体系建设中,就要尽可能将这些问题,通过企业级的项目管理制度加以明确并使之相对稳定,加强对各个具体项目的指导和监督。

    1.4.2 范围管理

    项目的范围管理,是针对项目交付成果的,通过对项目交付成果的计划、跟踪、控制和获取,保证项目中的所有活动始终是围绕所要求的项目成果开展的,而且保证全部的应交付成果都已完成。可以说,范围管理是具体描述项目目标的。

    在范围管理中最重要的一项内容,就是范围定义,就是对所要求的项目成果进行分解、细化,这样做的目地有三方面:

    1,提高估算时间、资源、成本的准确程度。

    2,定义衡量和控制项目绩效的基线。

    3,明确职责分派。

    将所要求的项目成果一层一层的细分,就形成了工作分解结构,简称WBS(Work Breakdown Structure),它是范围定义的主要输出结果。“工作分解结构”包含了三个含义:

    工作:是针对成果的,而不是面向过程的;

    分解:对成果进行细分,直到能够满足管理的要求为止;

    结构:成果被分解以后,每一小块内容并非是孤立的,而是有着内在的关联关系,这种相互之间的关系,是结构化的。

    WBS中所分解出来的各个组成部分,就形成了项目的子成果,以后所有的项目活动都应该是针对如何实现这些子成果的,而不应该存在与项目目标无关的项目活动。同时,全部的子成果都被完成,是项目整体成果被完成的必要条件。也就是说,通过细化分析项目成果所包含的各个组成部分,使项目的各项行动都有了具体的目标。正是因为项目范围是针对项目成果的,项目的成果就是产品或服务,所以项目范围往往与产品工艺特性(把服务视为无形产品)有着紧密的关系,需要有丰富的专业领域知识才能够做好。

    明确项目目标所要求的交付成果,需要辨析有形产品和无形产品的区别,这一点非常重要的。WBS是面向交付成果的。在制定WBS时,当交付成果是有形产品时,比较容易识别交付物,因为交付物确实都可以是可见的、可验证的,而且交付物都可以表示成为名词的形式。但是当交付成果是无形产品时,往往会带来混乱。无形产品的制造和交付过程是同时的,甚至有些成果与制造过程的行动是一一对应的,所以在表示交付成果时,就难以与制造过程彻底划清界限,经常会用无形产品的制造过程的行动动词来表示交付成果,结果将交付成果与项目活动混在一起,例如在WBS中不是用“歌曲1”、“歌曲2”这样的名词来表示范围的内容,而是用“演唱歌曲1”、“演唱歌曲2”这样的动词来表示,虽然这样写大家也都能理解,但是却混淆了WBS的标准,可能会导致将项目行动也写入WBS,作为项目范围进行管理,结果给项目管理带来麻烦。项目范围和项目活动之间的差别应该是大家早已熟知的,这里不再赘述。因此,对于项目交付成果,无论是产品还是服务,在WBS中都应该使用名词,而不要使用动词,即使像做广播体操这样一个强调过程体验的“项目”,在WBS中也应该使用各个动作的名称,而不是使用做这些动作的动词。

    另一方面,有些项目经理是用“可见的、可验证的”作为识别交付成果的依据,对于这一点也不能过于机械,特别是当项目的交付成果是无形产品时,这种判断标准有时就会产生误导。一方面,由于无形产品随着过程结束也会消失,所以其可验证的标准经常会不能满足。有人说,可以形成文档记录或者录像,这不就是可验证的了吗?这种做法固然满足了可验证的要求,但是如果简单的把文档记录作为交付成果,就可能从根本上偏离了项目目标,因为大家来听音乐会,希望得到的是音乐家的高超技艺给听众带来的享受,而根本不关心什么文档记录,项目是否成功,大家对成果的满意度不是来自苍白的文档,而是来自生动的过程,即使将文档记录作为必须的验证证据列入交付物,也不能代替根本的交付成果。在另一方面,项目中可见、可验证的东西不一定都是项目所需要的交付成果,例如,当我们要乘火车去某地的时候,其目标是人要到达目的地,而非提交一张“可见、可验证”的火车票。

    因此,对于交付成果的“可见、可验证”的特性,需要针对具体项目目标的要求,根据项目交付成果是属

    于有形产品还是无形产品来区别对待,即使在交付无形产品时使用一些辅助手段来满足大家早已习惯的“可见、可验证”的标准,也一定不要忘记项目的根本目标是什么,最主要的交付成果是什么。

    利用所形成的WBS,在项目接近完成时,就可以执行项目范围确认的工作,以保证项目成果至少在内容、数量上满足了当初的范围要求,然后才是对每个具体内容的质量的检查。

    下面的例子是一个组装个人计算机的工作分解结构的示例,它只需要说明一台台式计算机需要由哪些部分组成,但并不需要说明它是如何组装起来的。

    组装者只要按要求将上述部件都组装好,就可以认为是完成了工作。当用户在验收时,只要按照这个WBS来逐一核对,就可以比较容易的对计算配置的完整性作出确认。

    WBS分解到多细、分解出多少层,这方面没有固定的标准。在上面这个例子中,如果组装者希望自己分别选择不同的机箱和电源,而不是选择已经组装好的,那么这个WBS中就还要将“机箱和电源”这一个节点继续向下分解出“机箱”、“电源”两个节点。

    需要反复强调的是,范围管理是针对成果的,而不是面向过程的,只是说明项目要实现的成果是如何组成的,而不说明如何实现的过程。因此,WBS中所包含的内容,都是项目成果的组成部分,反映着项目目标的要求,而项目目标不是项目内部自己给自己定义的,是从项目外部设定的,所以WBS中的内容,对于项目来说,是必须完成的来自外部的要求,不能够在项目内部随意更改。如果项目范围需要进行调整,一定需要外部的项目目标提出者进行确认。同时,项目的成果并非单纯指项目的客户所要求的成果,同时还应包括各种项目干系人所要求的项目管理的成果,例如一些企业内部有相应的项目跟踪机制,要求项目在规定的时间提交相应的报告,项目过程中形成的各种项目管理文档,也必须被视为项目的交付成果,列入WBS当中,并在项目计划中为此安排任务资源及成本。上面的组装计算机的例子是一个比较简单的项目,没有很苛刻的项目管理成果要求,但在很多规范的项目中,都会在WBS中单独列出一个项目管理分支,将所要求的管理工作放在其中,例如项目周报、评审报告、里程碑报告等。

    项目范围是对项目目标的具体细化,是项目中各项活动存在的前提条件,是项目资源需求和成本预算的依据,是整个项目管理的基础。所以说,正确的范围定义是项目成功的基础。如果项目范围发生变更了,必然要导致项目计划中的进度、资源、成本的全面调整,对项目的影响是非常大的。在后面具体介绍项目计划过程时,我们可以更加清楚的看到项目范围对其它各方面因素的重要影响。因此,所有项目,都会将项目范围控制作为一项非常重要的项目管理工作内容,对于项目范围变更是非常谨慎的。

    例如,在软件开发项目中,我们可以将需求分析的工作视作项目范围定义的工作,通过需求分析,对于所要开发的软件的结构、功能进行分解,形成了一个个具体的功能需求,所有这些功能需求共同组成了整体软件的功能,当所有这些功能都被一一实现了,也就意味着软件的整体功能也被实现了。但是如果软件需求发生变更了,那么后续所有的设计、编码工作都可能要随之调整,甚至可能导致结构的调整,直接影响到了项目的各方面工作。

    同样的项目范围,在项目的不同阶段,出于不同目地,对项目范围的描述也可以是不同的。例如搞居室装修,在设计阶段,设计人员会首先按照居室、客厅、厨房和卫生间的方式来划分,然后对每一部份描述其墙面、地板、门窗的装修方式,这样比较利于理解装修效果,而在施工阶段,施工人员会首先按照墙面、地面、门窗等划分工作内容,然后再对每一部份描述不同房间的特别要求,这样比较适合施工的思路,

    容易理解施工的工序,铺地板的会一次把各个房间的地板都铺好,装灯具的通常会在最后一次性把各处的所有灯具都安装到位。因此,项目范围虽然反映的是目标,不是过程,但是其不同的分解方式,将会对后续的过程产生影响。所以项目范围的划分也应基于对项目工艺过程的基本理解。

    在企业级项目管理体系中,企业就需要认真研究各种项目的主要交付物,结合自身的生产工艺特点,对交付物进行仔细的定义,直接指导和规范各个项目的范围管理,做好项目范围变更控制,提高各项目经理的管理水平,提升项目管理的质量。

    1.4.3 时间管理

    为了能够完成和交付WBS中所要求的各个项目成果,在项目中必须要采取相应的行动。因此,WBS帮助项目活动定义了具体的目标,而项目活动则是实现这些具体目标的行动过程。项目活动与WBS的这种对应关系,保证了所有的项目活动都具有针对性,都是为了项目目标服务的,从而避免项目活动的盲目性产生的资源浪费。另一方面,WBS中所有的项目成果都应该有对应的项目活动来支持,以保证项目范围不被遗漏。如果将所有的项目活动与WBS中的具体成果连接起来,就会看出项目活动是对WBS的进一步扩展,将WBS这样一个树形分解结构扩展到了对应的项目活动。但是项目活动与项目范围有着本质的区别,一定不能混同起来。前面已经反复强调,项目范围是对项目目标的细化,是来自项目外部的要求,而项目活动则是根据项目内外的各种条件,由项目经理及其项目成员所决定的。对于同一范围要求,完全可以选择不同的实施过程,允许通过不同的项目活动来实现。范围是目的,活动是手段。在这个问题上经常容易出现的错误,就是将活动也当作了范围,把手段错当成了目标,使得项目经理在面对复杂多变的项目环境时,不能及时、灵活的采取不同的项目活动、运用不同的手段来完成项目目标。同时,另一方面的错误有时也会存在,就是有时会模糊了项目范围的边界和内容,过于随意的单方面更改项目范围,这种情况相对较少,但是一旦发生,就会给项目带来非常严重的后果。

    项目的时间管理,直接关系到项目的进度、资源的时间安排等最基本的管理内容。项目的时间管理是围绕项目活动的,项目活动的时间要求,决定了项目整体的时间进度安排,项目活动是时间管理的基础内容。在此基础上,在项目计划过程中要形成时间进度表,在项目执行和控制过程当中,要对时间进度进行跟踪和控制。对时间进度表的管理,是时间管理的集中表现。我们下面主要来说明一下时间进度表的相关因素:

    1,根据WBS,列出所需的项目活动列表,要保证WBS中所有内容最终都有对应的项目活动,同时不应存在多余的活动。

    2,为这些活动建立依赖关系。依赖关系的产生,一方面是由产品特性决定的,例如在房屋建设中,首先要打地基,然后才能是地上建筑,另一方面是企业管理和项目管理的需要,例如项目方案必须经过专家评审通过后,才能进行下一步的工作。这种具有强制性的依赖关系,被称为项目活动之间的硬逻辑。而对于其它的项目活动,就可以根据一般的工作习惯来安排先后顺序。项目活动之间一般存在四种依赖关系:

    前一任务结束、后一任务才能开始(FS),这是最常见的顺序执行的关系;

    前一任务结束、后一任务才能结束(FF);

    前一任务开始、后一任务才能开始(SS);

    前一任务开始,后一任务才能结束(SF);

    利用上述这四种关系,在所有的项目任务中建立依赖关系,形成所谓的项目活动网络图。建立依赖关系后,就会发现此时的项目活动的分组并非保持着原来按照WBS的成果的分组。例如在项目中几个部分中都需要到异地出差现场处理问题的活动,那么就可以将这些活动组织在一起,到达异地现场时一并解决各个部分的问题。在实际当中,甚至还经常出现出差一次为不同项目提供支持的情况。这也再次反映出项目活动与项目范围的重要差异,项目活动的安排是具有很大的灵活性的。

    3, 活动时间间隔

    在确定了项目活动之间的依赖关系后,还需要了解各个项目活动之间可能存在的间隔。这种间隔是由于一些客观原因而必须流逝掉的时间,这段时间不需要对应项目活动。例如家具刷好油漆后需要晾干的时

    间,领导或相关机构对一些重要事项的审批过程所需要的等待时间,这些时间不是项目组成员所能决定的,如果这些时间间隔有规律可循,例如通过技术特性指标、服务承诺、工作规范等,使得这种时间间隔相对确定,那么项目时间进度安排也容易落实,否则项目进度方面就存在不可控因素,应列入项目风险进行管理。调整了活动时间间隔后,项目活动网络图就得到了更新。

    4, 确定项目活动的工期。

    项目活动的工期决定了项目活动的时间长度,可以是天、小时,也可以是周、月,时间表中项目活动工期的单位,取决于项目管理的要求。项目活动的工期是受资源影响的,对于同一项目活动来说,在通常情况下,提供的资源越多,所需工期越短,资源的工作效率越高,所需工期越短,但也有很多情况,资源分配过多反而会效率降低、工期延长。资源管理不是时间管理这一领域的内容,我们会在后面的章节中介绍。资源与时间的关系,在后面的项目管理三角形部分还会具体说明。

    确定项目中各个活动的工期后,由于各项活动之间存在的依赖关系,项目活动网络图就具有了时间长度,能够初步反映出项目的总工期。

    5, 日历

    项目管理中所说的日历主要包括这样一些信息:日期、工作日/非工作日、每日可工作时间。在项目管理中,涉及到的日历包括企业基准日历、项目日历和项目资源日历。

    在项目中一般大家都可以将普通公历日历作为基础日历,结合政府发布的法定节假日和企业特定的工作日要求,对基础日历中的工作日和非工作日进行调整,再根据企业特定的工作时间要求,具体定义日历中每个工作日和工作时间,形成了所谓的企业基准日历,所反映的是企业的基本工作时间要求。

    项目日历,则是在企业日历的基础上,根据项目特定的要求,为项目制定的日历,其工作日/非工作日的安排,每日工作时间,都必须根据项目的特殊要求来安排。有些项目可以按照正常的企业日历进行,但是有些则不能,例如有些项目必须在政府的法定节假日中进行,有的项目只能在夜间进行,很多项目为了赶工期,需要加班加点工作,这些都导致项目必须采取与常规的基准日历不同的特定项目专用的日历,这种专为项目定制的日历,就是项目日历,每个项目都可以有自己的项目日历。

    项目资源日历是针对项目中的资源的。项目当中必定需要资源,对于企业内部的人力资源来说,通常可以按照项目日历来安排,也就是把项目日历作为这些资源的资源日历,但在某些情况下则会存在特殊情况。对于从企业外部获得的人力资源来说,特别是一些专家级的稀缺资源,只能依赖于这些资源的时间表,来安排与其有关的项目活动,资源能够为项目提供服务的时间安排,就是该资源在此项目中的工作时间,其它时间不能为项目提供服务,就都被视为非工作时间。对于机械设备这类资源,在可用的时间段内,每天24小时均可作为工作时间,这是与人力资源的一个很大的差别。可见,项目资源日历关心的是各种资源能够为本项目提供服务的时间范围。从资源角度来说,一个资源能够为多个不同项目或其它任务提供服务的时间安排,就称为该资源的资源日历。

    根据这些日历的要求,将带有工期的项目活动网络图映射到具体时间上,就确定了各个项目活动的起止时间,形成了初步的项目时间表。

    6, 限制条件

    项目各个方面的干系人,在项目时间方面可能会提出一些限制性条件,例如规定了项目的启动时间或结束时间,规定了项目中一些里程碑的具体时间点,前面所说的项目日历、项目资源日历也对项目提出了时间方面的限制条件。根据这些限制条件,调整初步的项目时间表。

    7, 识别关键路径

    在初步形成的项目时间表中,存在着所谓的关键路径(Critical Path)。这条关键路径由一系列的项目活动组成,关键路径上的项目活动如果有任何的延迟,都会导致整个项目的延期。因此,一般在制定出项目时间表以后,都要识别出其中的关键路径,对时间表的优化,以及在项目执行过程中对进度的控制,主要都是围绕关键路径的。

    通过综合以上各个步骤,形成了初步的项目时间表,但这个时间表未必能够完全满足所有限制条件的要求,也未必就是最佳的,也许还有进一步优化的可能。具体优化的方法我们就不在这里具体介绍了,有