文档介绍：文件编码（008-TTIG-UTITD-GKBTT-PUUTI-WYTUI-8256）
软件项目工程延期的处理案例
某软件项目工程延期的处理案例
某公司是一家专门从事系统集成和应用软件开发的公司，公关），不能完全按照合同进展。
，在项目实施进程中，严重单方面拖延实施进度，造成项目延期。（他们很小的项目决定需要开会讨论）
（机关领导一句话，项目经理就要处理变更需求；可称其为领导人风险）。
（软件项目）等认识，对合同规定的验收不予回应。这个需要该公司老总才能协调。（项目经理没有这方面的权利）
项目经理在项目组中本来负责软件开发设计，开发后期被部门经理任命为项目主管，对于客户主关需求变更，项目管理目前沟通的比较好。但对于一些政策性的变更，则非常的难处理（需要必须改动），没办法，只有进行变更处理。该公司应该怎么才能结束该项目呢。
分析列表：
题目：维护方式 作者：丁丁 (m)
客户是政府机关，单位机制。不太适应常规的市场经济运营方式。那就软件公司适应客户吧。
1、列举重要的指标点，让客户确认。
2、在合适的时间点，把项目由开发阶段过渡到稳定维护阶段。而且可以收取所谓的验收费用（运作～～）
3、抽出原班人马，稳定一个阶段后，指定个人，就在现在做维护和简单开发（不限期），也是保持良好的客户关系，和公司名誉。
题目：分析干系人 作者：张清俭 (大连)
这是中国现阶段制度决定的。在接政府的项目时，干系人分析显得异常重要，一定要有风险分析和应对计划，管理储备的比例也要增加，同时项目经理的沟通时间提高到95%。
题目：服务客户，培养人才 作者：贺炜 (西北工业大学)
以前我们也曾接手这样的两个政府信息化项目，最终通过为对方培养人才脱手的。最后项目完成后一个月，还偶尔要求我们过去，后来就完全由我们培养的政府自己的技术人员接手了。
题目：电子政务实施中的服务意识 作者：冷酷到底 (EXOA)
电子政务建设必须经历“从无到有，从有到好”的过程，所以我们在事实电子政务的时候也必须向用户灌输一个这样的理念，明白电子政务的建设需要过程需要时间，如果达成一个这样的共识的话项目的实施相对来说风险会小的很多，所以晓川先生分析的非常的精辟，但是电子政务建设出现了“用而不验”或“验而不用”那就是项目组的悲哀，所以实施电子政务项目必须要树立一个服务意识，项目靠服务产生利润，而不是单纯的靠产品产生利润！政府向企业买产品，也要买服务。项目应该将设计和实施划分开来，明确设计和实施的区别和界定，这样项目作的轻松，政府用的放心，用户当然也是开心了（特别是领导，电子政务是很大的业绩），总结一句电子政务项目实施要企业要作好定位，服务才是最能产生利润的。
题目：关系与商务不能等同 作者：陈荣森 (深圳市佳创)
与客户关系亲密固然是好事，但不能等同于在做项目时都事事迁就于客户，朋友是朋友，商务是商务，不能等同，否则会陷入很被动的局面。建议：
如果客户领导提出变更的想法，你不好意思明说，但你必须每次都向他列举这样的变更会给系统带来很大的变更和变更的困难，以便给提出变更的客户压力，随着压力的积累，客户再次提变更时会有压力而变得谨慎。
题目：如何实施电子政务项目 作者：石灵 (SIM)
我同意晓川先生的说法。在我国的行政机构中存在的两个突出问题就是领导意志和作风拖沓。相信在短期内这一现象难以消除。因此，阶段目标的制定就变得非常重要。管理水平的提高，往往不在于某项重大制度的变革，而是基于许多细微的、渐进的变化。因此，在进行阶段目标的设定时，要首先提供让政府各级部门感到方便的功能，使他们逐渐具有兴趣，从而形成一种良性循环，其过程如同微软公司的软件发布一样。
我们做的是一个财务管理软件，在项目初期我们的项目经理做的售前工作，跟客户了解了大体的需求，并且制定了项目方案，而项目方案是一个很笼统的框架性的东西，而我被指派与客户详细的调研需求，整个项目的与客户面对面接触调研需求共3次，第一次我已完全理解客户的需求和意图，而第二次并没有什么实质性的收获，因为客户给我的时间就很少，我们只简单讨论了与客户现存系统的接口问题，第三次谈需求，客户提出了一些需求而针对他的子系统的结构是很难实现的，当时我极力反对，但反对无效，因为我们的客户分两部分：转包客户、最终客户。
这还是个二包项目。而这种很难实现的需求是最终客户提出而转包客户不反对反倒支持。这样三次需求调研的结果就是得到一个业务逻辑异常复杂的业务模型。有了详细的业务模型之后，我很快初步估算出代码最少5