项目进度管理研究报告4篇

项目进度管理研究报告项目管理进度报告摘要（第七十四期）一、招标采购管理完成音视频系统设备采购项目的合同流转及签订工作；完成化纤地毯和隔音毛毡采购项目的招标工下面是小编为大家整理的项目进度管理研究报告4篇,供大家参考。

项目进度管理研究报告篇1

项目管理进度报告摘要

（第七十四期）

一、招标采购管理

完成音视频系统设备采购项目的合同流转及签订工作；完成化纤地毯和隔音毛毡采购项目的招标工作。

二、投资控制管理

本月审核票据申领单17份，为ups（付款金额为274.7706万元）、精密空调（付款金额为229.8453万元）、中低压配电柜（付款金额为321.79452万元）、民防检测费（付款金额为0.8640万元）、总包进度款（2017年11月）（付款金额为864.2878万元）、控制台（付款金额为48.5706万元）、项目管理费（付款金额为60万元）、vrv空调设备供货进度款（付款金额为45.72969万元）、精密列头柜供货进度款（付款金额为115.5万元）、冷水机组供货进度款（付款金额为43.05万元）、ats供货进度款（付款金额为84.75万元）、电梯供货进度款（付款金额为56.2455万元）、气体灭火设备（付款金额为52.943895万元）、计算机房及弱电系统设计集成管理费（付款金额为29.5719万元）、绿化配套工程（付款金额为184.1965万元）、u盾购买费用（付款金额为0.1万元）、总包进度款（2017年12月）（付款金额

为955.8968万元），付款总金额为3368.117105万元。至2017年12月20日，累计审核及开具票据申领单266张，累计审核费用76715.2977 万元，其中：服务类费用4105.7788万元；工程类费用59247.2557万元；设备类费用11993.5017万元；前期及配套类费用746.7014万元；零星无合同类费用622.0602万元。

三、投资合同管理

本月新增合同2份，为控制台供货合同、音视频系统供货合同,均为概算外新增合同。

四、项目工程管理

配合基建办协调施工总包及各专业分包单位、设计单位、监理单位,配合政府主管部门开展机电安装施工、设备安装施工调试、园区弱电施工、精装修大面积施工、机房装修零星补缺、幕墙零星修补、公共配套施工、室外总体绿化工程零星修补以及竣工验收准备，现场施工技术问题沟通、协调等工作。

五、报批配套管理

协助基建办完成35kv开关站土建项目方案设计中6家主管部门征询及公示工作；协助基建办完成35kv开关站土无论何时何地 我们一直在努力

建项目方案设计审批中的网上申报工作；协助基建办完成供用电合同的流转签订工作；协助基建办跟进交通道设配套工程的合同流转签订工作；协助基建办跟进35kv开关站土建项目监理合同的流转签订工作；协助基建办跟进35kv开关站土建项目施工招标的准备工作；协助基建办开展35kv开关站土建项目测绘合同流转工作；协助基建办开展充电桩安装配套工程的合同流转签订工作；协助基建办开展分项计量配套工程的合同流转签订工作；协助基建办开展35kv开关站土建项目施工图设计文件审查的合同流转签订工作；协助基建办推进15部电梯的年检报验工作，报验申请已正式提交；协助基建办完成音视频系统合同的流转签订工作。

六、项目设计管理

配合基建办协调设计单位开展施工图纸答疑、现场技术问题协调、现场施工节点及做法确认、设备/材料招标或询比价采购的技术文件审核、编制等相关工作。

七、进度控制管理

本月进度控制重点是：数据中心装饰工程施工收尾，配套楼和客服楼石材铺贴基本完成、；室外总体管线道路施工；督促室外绿化零星补缺竣工验收准备；业务楼精装大面积开无论何时何地 我们一直在努力

展施工；督促精装修材料供货进度；督促卫生间渗漏、墙面屋顶渗漏、地下室渗漏整改；督促地下室全面施工、督促推进总包积极推进暂估价设备/材料批价报审工作和中标材料供货合同的签订及材料供货进度计划。

无论何时何地 我们一直在努力 4

项目进度管理研究报告篇2

章节测验

 1:项目经理通知客户计划安排在一周内开始项目实施，期望客户团队参加，但在计划日期，客户团队未能参加。若要防止这个问题，项目经理应该事先做什么？

a.向客户强调团队参加的重要性

b.在计划日期前两天向客户发送提醒

c.向客户团队发送一份详细的实施计划并获得批准

d.向所有项目干系人发送一份详细的实施计划

 2:项目经理正在负责一个重要项目的执行，主管突然电话让你去验收另外一个项目，原项目经理辞职，pm怎么办？

a.查看所有文件，准备验收。

b.拒绝主管，正在负责一个重要项目

c.报告发起人

d.团队开会讨论

 3:建筑项目符合预算 符合进度，天气情况良好可以提前进度，问pm应该怎么办？

a.按原计划

b.变更提前

c.开会讨论 d.报告发起人

 4:项目经理在制定变更管理计划时要求所有相关的职能部门经理都要批准同意方可执行，但销售经理忙于业务一直无暇顾及审查文件，项目经理应该怎么办？

a.重新修订变更管理计划

b.找管理层协调

c.联系销售经理，再强调此事的重要性

d.不用他批准了，因为他业务忙

 5:项目接近尾声，开发工作完成，发起人要求项目经理提前向客户提交产品，项目经理应该：

a.找发起人洽谈，说服他收回请求

b.召开干系人会议

c.按原计划发布

d.让开发人员展开项目收尾，准备提前交付

 6:项目在ｑａ阶段，项目发起人为了抢占市场商机，要求ｐｍ直接项目收尾。ｐｍ应该

a.提变更给ccb b.直接收尾

c.提请求和所有干系人商议

d.按照发起人的指示直接收尾项目

 7:以下各项主要用于项目控制，除了（）a.偏差分析

c.挣值管理

d.成本效益分析

 8:公司之前项目都由同一供应商提供服务，pm应该把这个内容当作：

a.制约因素

b.假设条件

c.项目说明

d.工作流程

 9:作为乙方ｐｍ，对于一个新产品有３种方案，你可以用以下哪种方法去选择合适方案

a.产品分析

b.专家

c.备选方案分析

d.访谈

 10:pm作为乙方，其所在公司的销售经理让他去参加甲方的kick-off会议。然而，pm告诉销售经理，一个必须的资源2周以后才能加入此项目，销售经理认为没有什么大影响，坚持让pm参加此会议，pm该 a.不参加kick-off会议，因为没写完管理计划

b.不参加kick-off会议，告诉销售经理有一个资源2周后才能到位

c.参加，无大影响

d.参加，因为kick-off开始后，才能开始工作

 11:项目快接近尾声，客户提出新需求，pm应该

a.忽略

b.提出变更请求

c.和相关人员讨论，评估可行性

d.执行整体变更控制

 12:项目启动会即将召开(kick-off)，项目经理需要完成哪份文件？

a.项目章程

b.干系人管理计划

c.范围说明书

d.范围管理计划

 13:销售新签一个合同，通知pm第二天去客户那开kick-off meeting，项目成员两周后到岗，pm怎么办？

a.参加会议，告知客户不能开始。

b.拒绝销售，说资源两周后才能到

c.拒绝销售，说项目计划完成才能开 d.什么都不做，按时参加会议

 14:一个项目经理刚被分配到一个新项目上，项目时间有限，要保证项目干系人和项目团队成员意见统一，项目经理应该参考那个文件？

a.变更管理计划

b.沟通管理计划

c.项目管理计划

d.项目范围说明书

 15:公司内部有一个项目，范围说明书与去年的一个项目类似，项目经理可以直接借用以下哪个文件：

a.项目章程

b.预算

c.项目管理计划

d.工作分解结构

 16:项目经理把主要干系人和主题专家召集在一起讨论产品需求，用的什么工具？

a.头脑风暴

b.焦点小组

c.现场参观

d.访谈

 17:项目经理发现项目的可交付成果可能不满足政府的某些政策要求，但客户同意验收该可交付成果，请问项目经理怎么办？ a.将此情况上报至项目评审委员会，咨询意见

b.继续完成项目收尾工作

c.宣布项目失败

d.制定提前收尾程序

 18:kick-off meeting前必须确认的是什么

a.章程

b.项目管理计划

c.范围说明书

d.a和b  19:在最后一刻，项目团队实施了范围说明书中未包含的新功能。若要取得客户的批准，项目经理下一步应该执行哪个过程？

a.制定范围管理计划

b.核实范围

c.执行整体变更控制流程

d.执行定性风险分析

 20:在收集需求过程中，需要逐

一、深入地了解每一个干系人的具体需求，最好使用下列哪个技术？

a.访谈

b.问卷调查

c.焦点小组 d.原型法

项目进度管理研究报告篇3

浅谈项目进度管理之计划编制

软件项目计划（spp：software project plan）是cmm二级中列出的第二个关键过程域。这是因为cmm2软件项目计划需要根据纳入配置管理后的软件需求进行项目估算，并依据文档化的流程，形成项目计划文档。软件项目计划的目的在于建立合理的计划，执行软件工程和管理软件项目。软件项目计划管理在软件开发过程中处于十分重要的地位，它体现了对客户需求的理解，是开展项目活动的基础，是软件项目跟踪与监控（spto）的基础。

一、软件项目计划这一关键过程域在实施的过程中应该贯彻如下方针：

1.以分配的软件需求作为计划软件项目的基础。

在项目定义阶段，针对用户提出的原始需求（又称statements of work ,sow）,通过用户方和承接方的相互协商，确定双方一致同意的、项目组承诺实现的需求，这个需求即是“分配给软件的系统需求”或者更简洁地说，“分配需求”，然后根据它来提出项目意见，制定初始的项目计划。由此可见项目计划是以分配给软件需求作为软件项目的基础。

2.由项目经理、项目软件经理和其他软件经理共同协商软件项目的各项约

定，并与系统工程组、硬件工程组和系统测试组协商，这些组介入该活

动的有关事宜，同时记入文档。

所谓约定有对外约定和对内约定。对外约定如与客户、分包商有关部门约定。对内约定包含两方面：一是项目组与组织内部其他组，如测试组、硬件组、系统组的约定。二是项目组内部的约定。对软件而言，对外约定像用户需求的更改是不可避免的，一旦有变动会影响整个项目。因此cmm提出由高级管理者控制对外约定。约定是计划的基础，cmm spp中将其列为一个目标，即约定必须是有关各方一致同意、认可的。

另外，软件计划要包括所有项目活动和所有参加方面的责任，这些活动和责任都要文档化，以保证有效地将计划传达给项目各个参加方。在项目计划执行前，各个项目参加方要认同所承担的项目责任，这种认同是项目计划有效性的一个基本保证。

3.软件项目的规模、工作量和成本估计、进度和其他约定必须通过相关组的审查，以获得相关组及个人的支持。

cmm中的一个组织或一个机构里，通常有许多小组，比如软件质量保证组，负责计划和实施项目的质量保证活动的团队；软件配置管理组，负责策划、协调和实施软件项目正式配置管理活动的团队等等。在执行每个活动时候，这些组并不是独自行事的，而是相互影响的。在spp这个关键过程域中受影响的组包括软件工程组、软件估计组、系统工程组、系统测试组、软件质量保证组、软件配置管理组、合同组和文档组。但是在对所有与组织外部的个人和组所作的软件项目约定，则由高级管理人评审。所以cmm中提出“高级管理者参加按照文档化规程对组织外部个人和组所作的软件项目约定的评审”以此作为一项活动。

4.项目软件开发计划需要进行管理和控制

项目计划是cmm实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。所以需要对项目软件开发计划进行管理和控制以保证项目顺利实施。

二、软件项目计划的关键问题及解决方案

1.关于软件项目的估计

建立合理的软件计划的基础是对软件项目规模、资源要求和风险等要有一个合理的估算。这个估算过程应是规范的，而不是任意的。例如，如果提出一个项目计划需十个软件工程师工作六个月的计划，那么就要问这些数据是如何得到的。用户提出的时间和费用的要求仅能作为项目计划约束的条件，而不能作为项目计划的基础。

根据cmm spp 的活动9、10、11，估计对象应该包括软件规模、工作产品的工作量和成本、软件进度、风险、关键计算机资源等。项目计划的基础要求是估计项目中的各种工作所需的工作量和进度，软件成本通常由工作量换算而得到。

估计模型有很多种，常用的如下：

算法模型：包括一个或多个算法，生成的软件估计是一些变量的函数，如coco-mo

专家判断：利用一个或多个专家的经验作估计。

类比：和已完成的与新项目的规模和功能十分类似的项目做比较，作估计 自顶向下的估计：从项目的全局特性导出项目的整体估计，然后将其分配到各个分量上

自底向上的估计：分别估计软件作业的各个分量，再综合出整体估计

在具体进行估计的时候应该注意以下几个问题：

1)选择科学的估计方法。cmm的核心思想是不断学习、不断改进。在项

目过程中，计划是被不断修订的，所以每做一次修订，就必须作估计。

因此在某个项目中只对项目选定一种（几种）能改进的估计方法，多次

估计的结果进行比较，才能积累经验和数据，估计也才能越来越精确。

2)必须积累本组织自己的数据

随着生命周期阶段的进展，估计会越来越精确。一方面是不确定性随着

阶段的进展而减少，另一方面基于对估计值与实际值的分析比较，可合理选择估计模型的参数。组织在每一个项目结束时，需要将项目数据综合归纳，保留。如果在刚开始没有估计值的情况下，我们只要选定方法，做就是了。需要数据的地方如项目有数据用自己的数据，否则用本组织数据。对于无组织的数据，则一次选定本地区的数据、本国行业数据，国际上的行业数据。cmm 2级spp的活动场15要求建立一个数据库，记录项目估计数据，包括计划时的数据、再次调整计划后的数据。为使数据可用，必须记录下估计的假定，如采用的估计模型、模型参数、估计时作业的描述等。

另外，cmm2的本关键过程域还提到要按照文档化规程进行估计。由前面，在整个生存期内，随着项目的发展，需要不断进行估计。为确保估计的有效性，结果的可比性，必须描述项目进行估计的具体步骤，即所谓规程。这样一来就能保证估计过程的可重复性，无论什么人去估计，或是在不同时间估计、估计的步骤都是一致的，估计的假设也是一致的。cmm spp中要求有4个文档化的估计规程，具体的规程形式由项目自己确定，cmm仅提出了对规程的一般要求。这些规程指出：

估计假定要记入文档；

如有历史数据，使用历史数据；

估计要经过评审；

规模估计是多种估计的基础；

在用cmm进行过程改进的实践中，许多项目常常忘记进行规模估计，认为项目计划内容未明显包含规模。然而正是规模大小会影响技术解决方案。对于同一计划，人和月是不能交换的，比如说5个人干3个月的活就不等于4个人干4个月的工作。规模越大。通信与管理的开销越大。规模直接影响进度的安排、人力资源的安排、计算机资源的安排以及风险的分析。所以最初的模型估计也应该在项目定义阶段给出。其中代码行技术和功能点技术两个技术用来对软件规模进行估计。代码行技术是比较简单的定量估计软件规模的方法。这种方法根据以往开发类似产品的经验和历史数据，估计实现一个功能需要的源程序行数。功能点估计依据对软件信息域特性和软件复杂性的评估结果，估计软件规模。

在进行估计的时候我们可以参考如下几点建议：

首先下功夫精简软件需求规格说明书。从根本上来讲，估计的输入是需求规格说明书。要做合理的估计首先要力争使需求规格说明清晰。

尽可能将工作分解得详细。分解得越详细，对开发软件的技术方面理解越透，估计越精确。

采用几种独立的技术，没有一种估计技术是万能的，所以要避免其弱点利用其强处，最好采用技术组合。可以按情况对不同软件成分采用不同的估计技术。

比较与印证。对同一对象采用不同的估计技术，然后比较其结果，研究为何它们得到不同估计，从中能做出较精确的估计。

注意采集数据，将实际数据与估计值进行比较，不断修订估计值和估计模型的参数。

总之，根据cmm，当我们需要制定项目计划，首先确定了项目的需求后，估计出所有的可交付产品，以及这些产品的规模。比如，规模可能包括哪些？如果是生产类项目，可能估计的是交付的东西的数量，比如凳子多少条，牛奶多少箱等，如果软件开发类项目，可能是特性多少个，代码行多少行等，这些根据你所估计的对象来确定。另外，规模估计出来后，需要根据生产率估计项目可能的工作量，比如生产一条凳子要多长时间，一箱牛奶要多长时间，软件开发的话，可能就是一天生产多少行代码。在设计阶段，可能就是一天设计几个特性或者几页设计文档等。根据生产率再估计出总工作量。最后，根据你所拥有的人力，来确定出项目的进度计划。

根据这个再对应到软件开发上来。一个软件开发项目可能的生命周期有可能包括以下几个阶段： 需求分析、软件设计、编码、单元测试、系统测试、交付。不同的项目有不同的生命周期，但项目计划阶段一定要把项目的生命周期确定下来，这也是计划的一部分。那么，在制定计划时，怎么估计这几个阶段的里程碑时间呢？在处于二级的组织，由于之前没有什么量化的能力基线（也就是一般的每个阶段的生产率），那么也只能去参考历史项目的信息。假使以前的项目刚好做了这些度量的话，比如度量过每个阶段花费的时间，投入的人力，统计过交付件的规模（文档页数、代码行数等）。那么，项目刚好可以参考这些历史的数据，大致估计一下这个项目各个阶段可能需要的时间，来确定这个项目的阶段里程碑时间。假使没有类似的项目数据的话，可能估计的可信度就不高了。业界有估计方法，都是用来帮助我们得到比较可信的估计结果的，比如delphe、pert sizing。

在项目的生命周期不同阶段，因为所作的工作不同，生产率也就不同，每个阶段甚至都有不同的生产率度量单位，比如需求分析阶段，可能就是需求分析文档页数/人天。在编码阶段，可能就是代码行/人天等。一个组织需要积累和建立

这些能力数据，才能保证后面的项目有可信赖的数据参考，支撑后面的项目进行估计和计划的制定。

2.鉴别和评估软件风险

风险管理是项目管理的重要内容之内，从某种意义上讲，项目管理就是风险管理。风险就是不利事件发生的不确定性。所有。首先必须清楚风险是可能事件，它可能发生，也可能不发生。所以决定了风险的动态性。

风险评估是项目计划时必不可少的一项工作。正如前面提到的项目成本估算和进度估计一样都是项目管理的重要活动。忽略了风险，轻者给项目工作带来被动，重者可能对项目造成严重的灾难性后果。

cmm实际上在本关键过程域的活动13是如此表述这个问题的：

“对与项目的成本、资源、进度和技术方面相联系的软件风险进行鉴别、评估和建立文档”。

风险评估包括风险识别、风险分析和对风险进行优先级排序。

风险识别是风险评估的第一步。就某个特定的软件工程项目来说，从项目具体情况出发，列举出可能出现的风险。真正弄清每一个可能风险的情况是风险识别的主要任务。检查单是风险识别的一个有力的工具。采用检查单中所列举的各种风险，对照即将开发的软件项目，逐一加以甄别，判定检查单中哪些风险在该项目中可能发生。在进行风险识别时采用访谈、调查还是会议方式应根据软件项目的具体情况决定。

风险识别以后需要弄清楚已识别的风险可能何时何地发生，发生了会怎么样。风险分析的任务是分析每个风险可能造成的影响，给出比较风险大小的量值。进行分析可以借助一些已有的模型，但不是所有列出的风险都可以借助模型进行分析的，因此常常采用主观分析。

识别出风险，对其进行分析后就要对其进行排序了。排序步骤包括对已识别和分析的风险估计概率类型，如高概率风险、低概率风险；评估每个风险对项目的影响级，如低级、中级、高级。风险排序应该根据该项目各有关风险的概率和影响级。显然高概率和高影响级的风险应该排在中概率和高影响级风险的前面。最后针对排序列在前几位的风险采取缓解措施和跟踪措施。

3.确定软件生存周期

确定软件的生命周期，这在cmm本关键过程域活动5也有体现“识别和确定具有可管理的预先规定阶段的软件生命周期”。典型的几种生命周期模型包括瀑布模型、快速原型模型、渐进模型、喷泉模型等。

瀑布模型严格规定各阶段的任务，上一阶段任务输 出作为下一阶段工作输入。此模型适合于用户需求明确、开发技术比较成熟、工程管理严格的场合使用，其缺点是：由于任务顺序固定，软件研制周期长，前一阶段 工作中造成的差错越到后期越大，而且纠正前期错误的代价高。

渐进模型是指从一组简单的基本用户需求出发，首先建立一个满足基本要求的原型系统。通过测试和运行原型系统，有用户提出进一步细致的需求，然后修改和完善原型系统，反复进行这个过程直到用户满意为止。该模型适合开发初期用户需求不甚明确，相关技术和理论需要不断研究、反复实验以及开发过程需要经常与用户交互的场合，学习或研究类软件的开发常用此法。

快速原型是指快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。这个模型的优点是软件产品的开发

基本上是线性顺序进行的。

喷泉模型主要用于面向对象软件技术开发项目，其特点是各项活动之间没有明显的界限。由于面向对象技术的优点，该模型软件开发过程与开发者对问题认识和理解的深化过程同步。该模型重视软件研发工作的重复与渐进，通过相关对象的反复迭代并在迭代中充实扩展，实现了开发工作的迭代和无间隙，该开发过程分为：分析、设计、实现、确认、维护和演化。

三软件项目计划的实际应用模式如下：

1.项目采用 microsoft word 拟定计划文档，以 microsoft project 拟定计

划的进度表。

2.项目经理根据项目软件需求进行估算，确定进行项目选择的生命周期、项目规模、所需的人员、时间、进度、资源、风险等内容。将估算的结

果形成估算过程文档，并拟定软件开发计划。

3.软件开发计划内容包含：软件项目计划、迭代计划、进度时间表、配置

管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计

划、产品验收计划、问题解决计划、测试计划。

4.估算过程文档和软件项目计划文档必须通过相关组的审查，以获得相关

组及个人的支持，包括：系统分析组、设计组、编码组、测试组、质量

保证组、配置管理组、文档管理中心及个人。通过审查，发现并修正项

目估算和项目计划的偏差。只有获得了支持，软件项目组在开发过程中

才能尽量避免或消除风险。

5.在高层管理者复审通过后，项目经理指定人员或参与拟定软件开发计划

其它部分，并由相关组和个人复审。

6.配置管理人员将软件开发计划文档纳入配置管理。

7.实际项目中应用的文档有：

制定项目计划流程定义、项目估算流程定义、项目评估表、资源评估表、软件开发计划模板（包括：软件项目计划、迭代计划、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划）、进度时间表、制订软件开发计划的指南。

综上所述，spp阶段需要制定的计划不仅仅是进度计划，也包括需求管理计划（对需求如何管理，变更如何控制,谁来评审这些变更，如果变更了要怎么办），进度计划，配置管理计划（项目所有的交付件包括可交付的产品和中间的交付物等如何归档，如何变更，如何控制等），风险管理计划（项目开展中会碰到哪些风险，目前有哪些不确定因素后面可能发生，这些风险如何应对，假使风险发生如何处理，如何预防这些风险等等），资源配置计划（项目开展过程中需要哪些资源，包括办公用品，电脑，机器等等，这些资源何时提供，怎么分配，怎么管理等），等等这些都是项目计划要考虑的，比较复杂的内容，计划阶段会考虑所有的东西，甚至可能要包括利益关系人管理计划（比如识别项目的利益关系人，这些人应该如何管理，如何及时向他们汇报项目的信息等）。

项目进度管理研究报告篇4

二、it项目进度管理中的问题

本案例是笔者公司研发平台整合的it项目，该项目包括研发平台整合及需求定制开发；信息网络建设及硬件平台搭建，是一个一体化综合性的系统集成项目。企业希望通过本次项目的实施，建立产品研发管理平台系统，把产品设计、产品数据管理、变更管理及研发并行设计过程的协作等有机地集成为一个整体。

（一）进度计划不周全。项目涉及多个事业部的研发部门，各自的基础环境均有差异，实施的进度计划也都会有不同的时间点和困难点，初期计划定制时并没有考虑到这些关键影响因素，因而计划的执行和落地有些顾此失彼。

（二）调研分析不到位。项目的实施方把售前和售后严格分开来，致需求调研信息脱节，实施方人员衔接不到位；其次实施方人员对企业的业务模式了解不透彻，双方在范围定义的理解上存在偏差，含糊的需求和频繁的变更容易导致外延无法界定。

（三）团队成员沟通不顺畅。本项目组的成员来自不同部门的业务骨干，容易从自己部门的角度出发希望平台的建设能更加符合其应用习惯，刚开始的磨合期工作推进缓慢。另外实施方顾问人员不稳定工作衔接也出现问题。

（四）进度控制追踪不及时。实施范围临时扩大且时间节点不容变更，使得项目时间更为紧迫。首先每个事业部的领导重视程度不同，推行执行力度不同，其次产品迁移的数据量不同，还有部门本身设计使用的软件的兼容性，数据规范性可用性等等。为项目计划落实带来了一定的难度，各事业部任务完成的时间点无法同步，进度执行追踪的及时性无法保障。

三、完善研发平台整合项目进度管理的对策

（一）采用分层管理细化计划。

“凡事预则立，不预则废”。计划的制定对于整个项目运行来说无疑十分重要。

1.多层计划分段制定。项目计划分成整体、事业部、底层三个层次，分别对应项目组、事业部组和关键用户的管理结构。按里程碑的节点计划进行逐步细化，每层计划的变化频度及单位不同。

2.底层计划实时更新。动态跟踪关键用户的工作任务完成情况，可赵文星厦门厦工机械股份有限公司有效地了解项目的当前状况和整体趋势，及时发现问题点有的放矢地进行纠错。采用该方法制定的项目计划，既可符合事业部自己的进度，又可全面掌控各组的进度。

（二）掌握正确的调研方法。

it项目主要风险来自于不准确的需求，目标清晰范围精准是前期调研的重点。

1．售前售后脱节处理。要求实施方的售后经理等人直接介入到售前的投标阶段，并一直负责到项目结束，同时企业方的信息部人员全程督导协助，可较好的解决这个问题。

2．多轮调研把控。首轮调研注重现状与未来平台的差异分析；第二轮调研与技术人员沟通评估其工作量和工作难点，选出数据迁移最优方案；第三轮调研重点了解各部门、各岗位之间的联系，及其准确真实的业务流程。本过程对于优化现有平台提供有效准确的依据。

（三）缩短团队的磨合沟通。

团队内的信息沟通、意见交流，保证顺畅至关重要，成员之间建立和改善人际关系是必不可少的条件。

1．建立良好的沟通。项目组周例会进行重点难点的问题沟通，日常问题则是电话或oa直接沟通，若发现进度偏差则采取纠偏措施，及时调整或变更，确保项目整体进度。

2．增加团队的凝聚力。使团队成员都明了项目目标并共同为此努力，及时通报项目进度让大家清楚自己、他人和整个项目的工作进展，主动参与所关注的问题并及时协调解决，团队意识才能得到进一步强化。

3．知识传递增强成员自信。项目组内部根据进度计划，适时举行专题培训进行相应的知识传递，提升成员的自信心，对系统平台构架配置等有更多了解，为日后平台维护奠定基础。

（四）进度控制采用关键链。

项目是若干个相对独立的任务链条组成，各链条之间的协作配合直接关系到整个项目的进度，利用系统网络化的管理方法，可以优化整个项目的进度控制。

1．监控关键环节实现动态平衡。项目的进度管理绝不是一个静态的过程，实施与计划是互动的，不断优化协调以实现整体的动态项平衡，保证项目的均衡发展。底层计划关键链的任务之一就是数据迁移，迁移工作量与数据的多少及数据的规范性密不可分，是确保项目能否按时完成的关键。根据各事业部的数据现状，采用并行整理，分批迁移的策略。

2．找短板强突破。任何部门和环节的时间延误，都会导致整个项目实施周期的延长。因此，对影响项目进度的”短板”环节，进行着力攻坚，协同共进有效保障项目的实施周期。例如小型机事业部的服务器老旧数据多，数据形态与总部差异较大，如同步替换修改时间长达2-3个月，直接采取了先迁移后修改的方式以保证数据安全，事业部成员积极配合将进度提前了半个月。该短板的突破为项目按进度保质量提供了有效的保障。

四、结束语

本文以项目进度管理论为依据，结合案例实施的经验，对it项目的进度管理在执行过程中充分地考虑这些影响因素，有效地控制了进度确保该项目的顺利实施。只有适合项目的模式才是最好的模式，再好的管理方式针对不同的项目也会有不同的效果，因此项目实施过程必须多沟通、多分析、多实践、多总结。

相关热词搜索：研究报告，进度，项目，项目进度管理研究报告范文，项目进度管理研究报告怎么写，项目进度管理研究报告模板，项目进度管理研究现状，项目进度管理研究论文，工程项目进度管理研究，项目进度管理理论研究，项目进度管理分析报告，项目进度管理研究参考文献，项目进度管理论文范文，