依稀背影103700466
软件开发项目的进度安排方式有哪些？
软件开发项目的进度安排可以有两种考虑方式。
第一种，系统最终交付使用的日期已经确定，软件开发机构必须在合同规定的时间内安排；第二种，只确定了大致的年限，最后交付使用的日期由软件开发机构根据具体情况确定。
后一种考虑能够对软件开发任务进行细致的分析；能够最好地利用资源，合理地分配工作量，但实际工作中常常遇到第一种情况，问题是软件管理人员如何在规定的期限内分配人力和安排进度。
进度安排的好坏往往影响整个项目的按期完成和用户的使用，如不能按期完成，用户就会不满，而且需向用户赔偿损失。
如作为商品，将会失去市场竞争力。
进度安排的精确性有时比成本估算更重要。
在商品生产的社会中，某种商品的损失往往还可以通过其他商品或分期偿还来承担。
而进度拖延的损失是无法弥补的。
下面就软件开发项目进度安排中的几个问题进行讨论。
1.软件工作的特殊性 制定软件进度与其他工程没有很大的区别，因此使用一般的通用技术和工具即可。
但重点要强调的是软件产品是逻辑产品，这与其他工程不同。
因此当几个人共同完成某项任务时，人与人之间就有一个思想交流问题，称之为通信关系。
通信是要付出代价的，不只是要花时间，同时由于通信中的疏忽常常会使错误增加。
如一个组有4个软件工程师，两两之间进行通信联系，通信路径有6条；对6个软件工程师，则通信路径增加至14条。
因此所付的代价就必然会增加，所以工作组的人员不宜太多，一般3—5人为好，目前国外一般采用主程序员组的制度。
另一点要强调的是软件工作切忌中间临时加人，必须在安排进度时就考虑周到。
2.各阶段工作量的分配 估算出总的工作量以后，就需要一个可以进行各阶段工作量分配的模型。
某一阶段工作量所占的百分比必须根据经验数据确定。
这里要再一次强调，在开发过程中保存的记录将增加经验数据库存，而且将改善今后估算的准确性。
R.S.Pessman提出一种称作40-20-40的工作量分配规则，即前期工作（计划、需求分析、概要设计和详细设计阶段）和后期工作（测试阶段）各占40%，编码阶段占20%。
应该强调要重视前期和后期工作。
前期工作容易被忽视，主要原因是：管理人员认为不开始编码工作就算没有进行，他们不了解前期工作的重要性；技术人员往往也急于编码，认为写出代码任务就算完成了。
后期工作也容易被忽视，认为编码出来就完事了，对测试工作要占这么大的工作量没有思想准备。
所以要制定好进度计划，就要研究软件工作的规律，前期基础工作没做好，将会给后期工作带来很大困难，往往使工程进度一拖再拖，难以坚持，有的不得不中途夭折。
3.制定开发进度 需要涉及的下一个未知量是开发进度。
进度安排是软件计划工作中一项最困难的任务，计划人员要把可用资源与项目工作量协调好；要考虑各项任务之间的相互依赖关系，并且尽可能地平行进行；预见可能出现问题和项目的“细脖子”，并提出处理意见；以及规定进度，评审和应交付的文档。
假设用作变量的开发时间TD按线性变化，而且已经得到了总的开发工作量估算值ED，要求在规定的时间TD内完成，在项目中最好有参加工作的人员平均值M，即M=EDTD，这将是一个非常有用的数据。
遗憾的是在上述算式中，项目的工作量和开发时间不能作为独立的变量。
Books定律描述了这种现象的最极端情况：为误期的软件项目增加人员将会使其进度更慢。
来源：www.examda.com （四） 软件开发组织 有多少个软件开发机构，几乎也就有多少人员的组织机构。
不管这些组织机构是好或坏，一般是不可能轻易改变的。
尽管组织机构的改变不属于软件计划人员的职责范围内的事。
不过，在一个新的软件项目中直接涉及人员的组织问题却是可以，也应该在软件计划阶段加以认真考虑的。
软件开发项目进度如何控制？
文主要谈谈影响软件开发项目进度的因素、项目进度控制的目的、常用项目进度控制措施，软件开发项目进度控制中对项目经理而言需要注意的问题和一些工作经验、工作方法。
关键词：项目管理、进度、控制 一、影响软件开发项目进度的因素 要有效地进行进度控制，必须对影响进度的因素进行分析，事先或及时采取必要的措施，尽量缩小计划进度与实际进度的偏差，实现对项目的主动控制。
软件开发项目中影响进度的因素很多，如人为因素、技术因素、资金因素、环境因素等等。
在软件开项目的实施中，人的因素是最重要的因素，技术的因素归根到底也是人的因素。
软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。
常见的问题有以下几种情况： 1、80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在：80%的项目工作可以在20%的时间内完成，而剩余的20%的项目工作需要80%的时间。
这个80%的项目工作不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20%左右的项目工作大部分是在后期。
所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。
有些领导看到软件交付给用户了，就一块石头落地“总算交差了”，同时又可能撤出一些被认为不必要的人力资源。
但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。
这样的结果是拖延了后期的工作，同时如果软件还不成熟的话，会给用户造成不好的影响。
2、范围、质量因素对进度的影响 软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。
这样集少成多，逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了，但经检验其质量没有达到要求，则必然要通过返工等手段，增加人力资源的投入，增加时间的投入，实际上是拖延了进度。
不管是从横向或纵向来看，部分任务的质量会影响总体项目的进度，前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响 资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。
还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。
其他资源，如开发设备或软件没有到货，也会对进度造成影响。
预算其实就是一种资源，它的变更会影响某些资源的变更，从而对进度造成影响。
4、低估了软件开发项目实现的条件 低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。
软件开发项目团队成员，有时甚至是企业的高级项目主管也经常低估项目技术上的困难。
低估技术难度实际上也就是高估人的能力，认为或希望项目会按照已经制定的乐观项目计划顺利地实施，而实际则不然。
软件开发项目的高技术特点本身说明其实施中会有很多技术的难度，除了需要高水平的技术人员来实施外，还要考虑为解决某些性能问题而进行科研攻关和项目实验； 其次，低估了协调复杂度，也低估了多个项目团队参加项目时工作协调上的困难。
软件开发项目团队成员比较强调个人的智慧、强调个性，这给项目工作协调带来更多的复杂度。
当一个大项目由很多子项目组成时，不仅会增加相互之间充分沟通交流的困难，更会增加项目协调和进度控制上的困难。
另外，企业高级项目主管和项目经理也经常低估环境因素，这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。
低估这些条件，既有主观的原因，也会有客观的原因。
对项目环境的了解程度不够，造成没有做好充分的准备。
5、项目状态信息收集的情况 由于项目经理的经验或素质原因，对项目状态信息收集的的掌握不足，及时性准确性完整性比较差。
另外其它一些原因也会造成这种现象。
某些项目团队成员报喜不报忧，不希望别人知道自己工作的不好的情况，例如软件程序的编制，可能会先编制一些表面的东西，现有界面，看起来好像完成任务了，实际上只是一个“原型系统”或演示系统。
给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况，将对项目的进度造成严重的影响。
当然，如果出现这种需要时时刻刻都互相提防的氛围，管理人员就应该从管理的角度，从制度的角度检讨一下，进行改进，让大家实事求是地进行沟通。
温伯格说：“无论你多么聪明，离开了信息，对项目进行成功的控制就是无源之水、无本之木。
” 6、执行计划的严格程度 没有把计划作为项目过程行动的基础，而是把计划放在一边，比较随意去做。
例如对于项目团队内部沟通或外部沟通，在计划中要说明清楚...
软件项目计划的计划制定
项目计划详细说明了所需软件工作及如何实现。
它定义了每一个主要任务，并估算其所需时间和资源，同时为管理层的评估和控制提供了一个框架。
项目计划也提供了一种很有效的学习途径。
如果能合理建档，它便是一个与实际运行效能比较的基准。
这种比较可以使计划者看到他们的估算误差，从而提高其估算精确度。
我们着重强调对项目规模和资源的估算，是因为低质量的项目资源估算将不可避免地造成资源短缺，进度延迟和预算超支。
又由于项目资源估算是从软件规模估算中直接衍生出来的，所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出，并随着工程的进展不断地加以精化。
起初，由于软件需求通常是模糊而又不完整的，我们的工作重点应在于明确该项目需要哪些领域的知识，并且如何获取这些知识。
如果不遵循这一指导原则，程序员们通常会积极地投入到那部分已知的工作中去，而把未知部分留滞到以后。
这种工作方式通常会产生很多问题，因为未知部分具有最高的风险系数。
软件项目计划的逻辑如下所述 ：由于软件需求在初始阶段是模糊而又不完整的，质量计划只能建立在对客户需求的大致而不确切的理解之上。
因此，项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨慎，因为它通常标定了产品模块的分割线，同时描述了这些模块所实现的功能及所有模块间的关系。
这就为项目计划和项目实施提供了组织框架，因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时，也应同时精化资源映射，项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划，软件项目计划其实就是一个用来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。
一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性，不确定因素多，工作量估计困难，项目初期难于制定一个科学、合理的项目计划。
我曾主持和参与过大大小小的软件项目十余项，下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。
高级计划，是项目的早期计划。
高级计划应当是粗粒度的，主要是进行项目的阶段划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。
大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。
详细计划要确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，小的事件点（即里程碑）。
如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发组，二级计划是各开发组制订的适合的自己小组的计划。
如果开发组还分了小组，可以有小组的三级计划。
开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制定，要把任务细化到人·日。
一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和人员数量来支撑，合理的划分小组，减少组织的层次，有利于项目计划的制订和实施。
较小的软件项目由于工期不长，人员较少，有二级计划（高级计划与低级计划）也是可行的。
2.重视与客户的沟通与客户的沟通是很重要的。
不必害怕客户知道我们的开发计划，特别是项目进度情况，应当和客户共享这些信息。
首先，客户会提出一些对项目时间、进度、效果上的要求，这个指标往往经不起推敲，有的还带有较强的政策性。
如：在我主持的一个某单位人nnerlink>MIS系统的开发中就发现，客户方对时间上的约束是有成形的文件的，是他们单位领导们开会的决定。
客户给出的从项目启动到验收的时间只有三个月，但是，经过我们认真的需求调研，做出项目进度的粗计划和部分的二级计划后，发现三个月的时间是难于实现的。
我们把做出的调研文档和项目计划摆出来和和客户讨论，最终使项目的开发时间延长为六个月。
站在为了科学地分析和解决问题的立场上来看，项目组和客户的目的是一致的，所以对于合理的项目进度客户是会理解与支持的。
其次，我们有义务要让客户知道项目的计划。
这样才能让客户和用户主动、积极参与项目，达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不愿意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非正式的，但留下了项目工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。
3.该详细的详细，该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工的小项目，可能项目计划就四五页纸，包括一个WBS（工作分解结构）和一个Gantee图（甘特图）。
一个需要五六十个人甚至上百人，要花上半年或更长时间的...
施工进度计划表表格中的横线如何画
利用project软件，任务之间的横线是自动生成的。
1、Microsoft Project（或MSP）是由微软开发销售的项目管理软件程序。
软件设计目的在于协助项目经理发展计划、为任务分配资源、跟踪进度、管理预算和分析工作量。
2、本应用程序可产生关键路径日程表──虽然第三方ProChain和Spherical Angle也有提供关键链关联软件。
日程表可以以资源标准的，而且关键链以甘特图形象化。
3、另外，Project可以辨认不同类别的用户。
这些不同类的用户对专案、概观、和其它资料有不同的访问级别。
自订物件如行事历、观看方式、表格、筛选器和字段在企业领域分享给所有用户。
4、项目管理分五个阶段，启动、规划、执行、监控和收尾，起码在中间三个阶段project可有助于项目经理的工作。
5、project用得最多的是甘特图。
6、project虽归属于office中，但须独立安装和购买，office套装软件中并未包括。
...
施工进度计划表表格中的横线如何画
利用project软件，任务之间的横线是自动生成的。
1、Microsoft Project（或MSP）是由微软开发销售的项目管理软件程序。
软件设计目的在于协助项目经理发展计划、为任务分配资源、跟踪进度、管理预算和分析工作量。
2、本应用程序可产生关键路径日程表──虽然第三方ProChain和Spherical Angle也有提供关键链关联软件。
日程表可以以资源标准的，而且关键链以甘特图形象化。
3、另外，Project可以辨认不同类别的用户。
这些不同类的用户对专案、概观、和其它资料有不同的访问级别。
自订物件如行事历、观看方式、表格、筛选器和字段在企业领域分享给所有用户。
4、项目管理分五个阶段，启动、规划、执行、监控和收尾，起码在中间三个阶段project可有助于项目经理的工作。
5、project用得最多的是甘特图。
6、project虽归属于office中，但须独立安装和购买，office套装软件中并未包括。
开发开发计划书怎么写
关于网站计划书的写法 1、相关行业的市场是怎样的，市场有什么样的特点，是否能够在互联网上开展公司业务。
2、市场主要竞争者分析，竞争对手上网情况及其网站规划、功能作用。
3、公司自身条件分析、公司概况、市场优势，可以利用网站提升哪些竞争力，建设网站的能力（费用、技术、人力等）。
二、建设网站目的及功能定位 1、为什么要建立网站，是为了宣传产品，进行电子商务，还是建立行业性网站？是企业的需要还是市场开拓的延伸？ 2、整合公司资源，确定网站功能。
根据公司的需要和计划，确定网站的功能：产品宣传型、网上营销型、客户服务型、电子商务型等。
3、根据网站功能，确定网站应达到的目的作用。
4、企业内部网（Intranet）的建设情况和网站的可扩展性。
三、网站技术解决方案 根据网站的功能确定网站技术解决方案。
1、采用自建服务器，还是租用虚拟主机。
2、选择操作系统，用unix,Linux还是Window2000/NT。
分析投入成本、功能、开发、稳定性和安全性等。
3、采用系统性的解决方案（如IBM,HP）等公司提供的企业上网方案、电子商务解决方案？还是自己开发。
4、网站安全性措施，防黑、防病毒方案。
5、相关程序开发。
如网页程序ASP、JSP、CGI、数据库程序等。
四、网站内容规划 1、根据网站的目的和功能规划网站内容，一般企业网站应包括：公司简介、产品介绍、服务内容、价格信息、联系方式、网上定单等基本内容。
2、电子商务类网站要提供会员注册、详细的商品服务信息、信息搜索查询、定单确认、付款、个人信息保密措施、相关帮助等。
3、如果网站栏目比较多，则考虑采用网站编程专人负责相关内容。
注意：网站内容是网站吸引浏览者最重要的因素，无内容或不实用的信息不会吸引匆匆浏览的访客。
可事先对人们希望阅读的信息进行调查，并在网站发布后调查人们对网站内容的满意度，以及时调整网站内容。
五、网页设计 1、网页设计美术设计要求，网页美术设计一般要与企业整体形象一致，要符合CI规范。
要注意网页色彩、图片的应用及版面规划，保持网页的整体一致性。
2、在新技术的采用上要考虑主要目标访问群体的分布地域、年龄阶层、网络速度、阅读习惯等。
3、制定网页改版计划，如半年到一年时间进行较大规模改版等。
六、网站维护 1、服务器及相关软硬件的维护，对可能出现的问题进行评估，制定响应时间。
2、数据库维护，有效地利用数据是网站维护的重要内容，因此数据库的维护要受到重视。
3、内容的更新、调整等。
4、制定相关网站维护的规定，将网站维护制度化、规范化。
七、网站测试 网站发布前要进行细致周密的测试，以保证正常浏览和使用。
主要测试内容： 1、服务器稳定性、安全性。
2、程序及数据库测试。
3、网页兼容性测试，如浏览器、显示器。
4、根据需要的其他测试。
八、网站发布与推广 1、网站测试后进行发布的公关，广告活动。
2、搜索引掣登记等。
九、网站建设日程表 各项规划任务的开始完成时间，负责人等。
十、费用明细 各项事宜所需费用清单。
以上为网站规划书中应该体现的主要内容，根据不同的需求和建站目的，内容也会在增加或减少。
在建设网站之初一定要进行细致的规划，才能达到预期建站目的。
网站项目建设流程概述 网站项目管理就是根据特定的规范、在预算范围内、按时完成的网站开发任务。
二.需求分析 项目立项 我们接到客户的业务咨询，经过双方不断的接洽和了解，并通过基本的可行性讨论够，初步达成制作协议，这时就需要将项目立项。
较好的做法是成立一个专门的项目小组，小组成员包括：项目经理，网页设计，程序员，测试员，编辑/文档等必须人员。
项目实行项目经理制。
客户的需求说明书 第一步是需要客户提供一个完整的需求说明。
很多客户对自己的需求并不是很清楚，需要您不断引导和帮助分析。
曾经有一次，我问客户：“您做网站的目的是什么？”他回答：“没有目的，只是因为别人都有，我没有！”。
这样的客户就需要耐心说明，仔细分析，挖掘出他潜在的，真正的需求。
配合客户写一份详细的，完整的需求说明会花很多时间，但这样做是值得的，而且一定要让客户满意，签字认可。
把好这一关，可以杜绝很多因为需求不明或理解偏差造成的失误和项目失败。
糟糕的需求说明不可能有高质量的网站。
那么需求说明书要达到怎样的标准呢？简单说，包含下面几点： 1.正确性：每个功能必须清楚描写交付的功能； 2.可行性：确保在当前的开发能力和系统环境下可以实现每个需求； 3.必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时砍掉； 4.简明性：不要使用专业的网络术语； 5.检测性：如果开发完毕，客户可以根据需求检测。
三.系统分析 网站总体设计 在拿到客户的需求说明后，并不是直接开始制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。
总体设计是非常关键的一步。
它主要确定： 1.网站需要实现哪些功能； 2.网站开发使用什么软件，在什么样的硬件环境； 3.需要多少人，多少时间； 4.需要遵循的规则和标准有哪些。
同时需要写一...
在项目执行的过程中如何进行项目的控制,确保项目进度
转载，供参考。
软件开发项目进度控制 一、影响软件开发项目进度的因素 要有效地进行进度控制，必须对影响进度的因素进行分析，事先或及时采取必要的措施，尽量缩小计划进度与实际进度的偏差，实现对项目的主动控制。
软件开发项目中影响进度的因素很多，如人为因素、技术因素、资金因素、环境因素等等。
在软件开项目的实施中，人的因素是最重要的因素，技术的因素归根到底也是人的因素。
软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。
常见的问题有以下几种情况： 1、80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在：80%的项目工作可以在20%的时间内完成，而剩余的20%的项目工作需要80%的时间。
这个80%的项目工作不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20%左右的项目工作大部分是在后期。
所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。
有些领导看到软件交付给用户了，就一块石头落地“总算交差了”，同时又可能撤出一些被认为不必要的人力资源。
但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。
这样的结果是拖延了后期的工作，同时如果软件还不成熟的话，会给用户造成不好的影响。
2、范围、质量因素对进度的影响 软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。
这样集少成多，逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了，但经检验其质量没有达到要求，则必然要通过返工等手段，增加人力资源的投入，增加时间的投入，实际上是拖延了进度。
不管是从横向或纵向来看，部分任务的质量会影响总体项目的进度，前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响 资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。
还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。
其他资源，如开发设备或软件没有到货，也会对进度造成影响。
预算其实就是一种资源，它的变更会影响某些资源的变更，从而对进度造成影响。
4、低估了软件开发项目实现的条件 低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。
软件开发项目团队成员，有时甚至是企业的高级项目主管也经常低估项目技术上的困难。
低估技术难度实际上也就是高估人的能力，认为或希望项目会按照已经制定的乐观项目计划顺利地实施，而实际则不然。
软件开发项目的高技术特点本身说明其实施中会有很多技术的难度，除了需要高水平的技术人员来实施外，还要考虑为解决某些性能问题而进行科研攻关和项目实验； 其次，低估了协调复杂度，也低估了多个项目团队参加项目时工作协调上的困难。
软件开发项目团队成员比较强调个人的智慧、强调个性，这给项目工作协调带来更多的复杂度。
当一个大项目由很多子项目组成时，不仅会增加相互之间充分沟通交流的困难，更会增加项目协调和进度控制上的困难。
另外，企业高级项目主管和项目经理也经常低估环境因素，这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。
低估这些条件，既有主观的原因，也会有客观的原因。
对项目环境的了解程度不够，造成没有做好充分的准备。
5、项目状态信息收集的情况 由于项目经理的经验或素质原因，对项目状态信息收集的的掌握不足，及时性准确性完整性比较差。
另外其它一些原因也会造成这种现象。
某些项目团队成员报喜不报忧，不希望别人知道自己工作的不好的情况，例如软件程序的编制，可能会先编制一些表面的东西，现有界面，看起来好像完成任务了，实际上只是一个“原型系统”或演示系统。
给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况，将对项目的进度造成严重的影响。
当然，如果出现这种需要时时刻刻都互相提防的氛围，管理人员就应该从管理的角度，从制度的角度检讨一下，进行改进，让大家实事求是地进行沟通。
温伯格说：“无论你多么聪明，离开了信息，对项目进行成功的控制就是无源之水、无本之木。
” 6、执行计划的严格程度 没有把计划作为项目过程行动的基础，而是把计划放在一边，比较随意去做。
例如对于项目团队内部沟通或外部沟通，在计划中要说明清楚人员、周期、方式、方法，不能遗漏，但在实际项目过程中，可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。
若项目计划本身有错误，执行错...
翰林进度计划软件怎么编制进度计划表
(1)缺少进度指路明灯 当我们在路上行走的时候，会在沿途观看路标，当到达某一个路标时，我们便知道还有多少路或多少时间才能够到达终点。
这些路标是我们在旅程中的里程碑，让我们可以清楚地知道目前所在地离开目的地有多远，也让我们能估算何时才能够到达目的地。
对于在路上行走的我们，可以通过路边的里程碑这一个简单工具来获知自己的进度信息。
当进行软件开发的时候，我们也需要建立开发项目的里程碑，使我们知道项目的进度。
里程碑是项目管理不可忽视的一部分，通常意味一个时间点上可交付成果的完成，好的里程碑管理就像一张地图指示我们走向项目目标的进度。
（2）项目进度估算准确性差 软件项目开发进度控制面临的最大挑战就是项目进度估算的准确性差。
据统计，在对软件项目进度与成本估算时，大多数项目实际完成时间超过估算进度的25%到100%。
根据我的经验要想对项目进度进行有效的估算，必须抓好以下两个方面：一是项目计划的可行性和可操作性，这是进度估算的基础。
二是要对项目进度进行合理的度量，这样才能够获得项目的真实进展情况，并对项目估算做出相应调整。
（3）前松后紧，项目进度缺乏有效监管和控制 一般人在工作时都有前松后紧的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理粒度。
对复杂的软件开发项目而言，每一阶段的进度都需要逐步逼近目标，里程碑产出的中间“交付物”就是每一步逼近的结果，也是控制的对象。
如果没有里程碑，中间想知道“现在进度做的怎么样了”是很困难的。
（4）没有尽早发现和降低项目风险 在软件开发中错误发现得越晚，对于开发造成的损失越大。
里程碑式开发模式可根据每个阶段产出结果分期确认成果，避免血本无归。
通过早期里程碑评审一般可以提前发现需求和设计中的问题，降低后期修改和返工的可能性。
例如，在需求分析阶段发生的错误，那么最多就是把需求分析写一遍，损失的是一个人的劳动；而到了测试阶段发现了需求错误，再回去重新做需求分析，那么损失可能是致命的。
转载请注明出处51数据库 » 软件开发的进度计划表
