不能保证工程项目用户设计和建立测试文档与软件编码同步进行，是导致项目失败的不良习惯之一。
　　需要大量使用软件的制造项目与其他工程项目不同，因为你只有在产品接近完成之前才能了解其真实面貌。用户和检查人员最早也要在产品原型制造出来之后才能对其进行评估，而运营状况不佳的项目根本就无法开发出用户和检测人员需要的模型和产品原型。诸如设计文件、用户指南、安装手册和帮助向导之类的文档，为最终用户和测试人员提供了一个可以尽早深入项目评价系统的窗口。如果没有这些文档，就只能寄希望于开发出来的系统碰巧没有问题了。

　　缺乏档案绝对可以算得上项目管理的失败。如果项目管理者决定不去检查文档的状况，开发人员和程序员也就不会考虑它的重要性。实际上www.cechina.cn，项目经理必须要对项目文档进行检查和评估，包括检查规划中的时间节点、让开发人员负责生成文档。在不成功的项目中，开发人员往往并不负责制作文档，这也就意味着，那些了解设计决策细节和结果的人并不负责保存信息，而那些对设计一无所知的人却要努力去了解相关的知识。
　　不是所有的项目都需要保证建档在编码之前进行。在瀑布式开发方法中，所有的文档都应该在编程之前完成CONTROL ENGINEERING China版权所有，而现状更新则是在编程结束之后很久才完成。如果你正在使用这种项目管理方法，文档就应该在编程的过程中完成。如果使用敏捷或者SCRUM方法，用户文档和设计文件就需要在每一步设计、代码和测试循环完成的同时编写。

　　拖延的风险
　　你可以决定延缓建档工作，但是必须要考虑到项目风险。如果项目团队中的每个人都完全了解问题和解决方案（不需要整个公司和行业都了解，但是实际项目组成员需要了解），并且团队成员都曾经在类似的项目上工作过，那么风险就相对比较确定。但是如果达不到上述的条件，延缓建档通常是出于完美主义的考虑。尽管希望是美好的，但是这确实是一种糟糕的项目策略。如果没有相关文档的支持，项目经理就只能盼望软件开发别出什么问题了。很少能有团队具备完美主义所需要的经验和信任度。
　　·要改正这一不良习惯，需要做的最困难的事情包括：
　　·尽全力保证整个项目透明；
　　·改变理念控制工程网版权所有，把文档作为项目进展的一个衡量指标；以及
　　·让那些有相关知识的人员负责自己工作的文档编撰工作。尽管专业的技术编辑可以协助开发文档，但他们还不能完全掌握开发人员和程序员的知识。
　　通常www.cechina.cn，最失败的软件项目能够交给技术支持人员、用户和后续设计开发的只有一套代码，相关的文档却远远不够。项目是否成功CONTROL ENGINEERING China版权所有，必须要通过它的有用性和扩展性来衡量，同时也要满足官方的要求。吝啬在文档编撰上的时间，就会使一个技术上成功的项目变成最终用户的灾难。不要为了追求完美而延缓建档，因为这是一个不良习惯。