软件项目工程延期的处理案例doc

某软件项目工程延期的处理案例某公司是一家专门从事系统集成和应用软件开发的公司，公司目前有员工50多人，公司有销售部、软件开发部、系统网络部等业务部门，其中销售部主要负责进行公司服务和产品的销售工作，他们会将公司现有的产品推销给客户，同时也会根据客户的具体需要，承接应用软件的研发项目，然后将此项目移交给软件开发部，进行软件的研发工作。软件开发部共有开发人员有18人，主要是进行软件产品的研发，及客户应用软件的开发。经过近半年的跟踪后，今年元旦，销售部门与某银行签订了一个银行前置机的软件系统的项目，合同规定，5月1日之前系统必需完成，并且进行试运行。在合同鉴定后，销售部门将此合同移交给了软件开发部，进行项目的实施。王伟被指定为这个项目的项目经理，王伟做过5年的金融系统的应用软件研发工作，有较丰富的经验，可以作系统分析员，系统设计，但作为项目经理还是第一次。另外项目组还有另外4名成员，1个系统分析员（含项目经理），2个有1年工作经验的程序员，1个技术专家（不太熟悉业务）。项目组的成员均全程参加项目。在被指定负责这个项目后，王伟制定了项目的进度计划，简单描述如下为：1)1月10日～2月1日需求分析2)2月1日～2月25日系统设计，包括概要设计和详细设计3)2月26日～4月1日编码4)4月2日～4月30日系统测试5)5月1日试运行但在2月17日王伟检查工作时发现详细设计刚刚开始，2月25日肯定完不成系统设计，您建议王伟应该如何做？他在项目的管理中有问题吗？分析列表：题目：项目在2.1完成需求分析作者：forgiveme([e-mail])项目在2.1完成需求分析，在设置检查点的时候，在此是否应该考虑有个点；在项目计划中应该对项目的关键路径进行设置，并依据此路径设置必要检查点。问题既然已经发生，5.1已成为必定的时间，那么，首先必须对原因进行分析，在之基础之上再进行重新构建，我会考虑对项目范围作些调整，也会作些相应的加班题目：否有例会作者：forgiveme([e-mail])延期前：1、5月1日这个日期是如何定下的？定期Deadline之前是否考虑了公司的研发资源/力量？2、项目开始前是否做过风险分析？进度是否是该项目的风险？3、项目是否有例会？例会的频度是否与项目的周期相匹配？例会的议程是否包含对目前项目面临的问题/风险的跟踪？4、项目组的组成：项目经理同时又是系统分析员。项目经理应该懂业务，最好不要当系统分析员，不然会陷入技术细节纠缠不清。5、项目计划是怎么做出来的？是否经过工作量的详细估计？是谁估计的？应该由具体执行人员估计，再加上技术专家的意见。6、是否识别出了关键路径？是否对关键任务进行了重点监控？7、项目的人力资源是如何获取的？是否与该项目的难度、进度相匹配？资源的数量是如何确定的？是根据工作量确定的吗？题目：计划调整是必须的作者：寇震(中铁十八局集团[e-mail])软件开发计划包含了需求分析，这是造成开发计划不准确的最大风险来源，我们的开发计划必须是根据需求分析后，进行工作分解得到的，而我们通常都不能这么做。我认为需求分析后，再次进行计划调整变更，确定项目的最终时间表，并和领导、客户沟通是最可靠的。题目：常见现象作者：李子军(北京诺德信科技开发有限公司[e-mail])虽然王伟第一次做项目经理，但仅从本文描述来看，并不能完全断定王伟的管理有问题：1、阶段性的时间延迟是常有的事，资深的项目经理也不能完全控制每个阶段一定遵循预定时间2、对于需求不明确、业务背景复杂的项目，适当延长需求分析的时间，有利于保证后期设计的准确性和减少需求变更的幅度和次数3、需求分析是与客户共同开展的，你所做的工作、所花费的时间，客户是有目共睹的，是能够容忍的4、延误的时间只有从后面几个阶段中挤出来，例如编码和测试同步进行等5、万不得已，由于客户原因导致项目延期，适当延长工期，是必不可少的，总比开发成果与客户预期相悖要好为政府实施电子政务项目的案例公司A是市政府背景很强的股份制企业，机制比较灵活（shanghai），目前该公司的正在进行的一个项目是政府机关的一个Mis系统，现在整个开发全部完成，系统已经试运行2个月左右，目前运行情况比较顺利，但是，目前有几个比较大的问题如下：1.客户同公司关系特别密切（毕竟客户是机关），不能完全按照合同进展。2.政府的工作节奏比较慢，在项目实施进程中，严重单方面拖延实施进度，造成项目延期。（他们很小的项目决定需要开会讨论）3.不可预测的项目变更风险（机关领导一句话，项目经理就要处理变更需求；可称其为领导人风险）。4.客户没有项目周期（软件项目）等认识，对合同规定的验收不予回应。这个需要该公司老总才能协调。（项目经理没有这方面的权利）项目经理在项目组中本来负责软件开发设计，开发后期被部门经理任命为项目主管，对于客户主关需求变更，项目管理目前沟通的比较好。但对于一些政策性的变更，则非常的难处理（需要必须改动），没办法，只有进行变更处理。该公司应该怎么才能结束该项目呢。分析列表：题目：维护方式作者：丁丁([e-mail])客户是政府机关，单位机制。不太适应常规的市场经济运营方式。那就软件公司适应客户吧。1、列举重要的指标点，让客户确认。2、在合适的时间点，把项目由开发阶段过渡到稳定维护阶段。而且可以收取所谓的验收费用（运作～～）3、抽出原班人马，稳定一个阶段后，指定个人，就在现在做维护和简单开发（不限期），也是保持良好的客户关系，和公司名誉。题目：分析干系人作者：张清俭(大连[e-mail])这是中国现阶段制度决定的。在接政府的项目时，干系人分析显得异常重要，一定要有风险分析和应对计划，管理储备的比例也要增加，同时项目经理的沟通时间提高到95%。题目：服务客户，培养人才作者：贺炜(西北工业大学[e-mail])以前我们也曾接手这样的两个政府信息化项目，最终通过为对方培养人才脱手的。最后项目完成后一个月，还偶尔要求我们过去，后来就完全由我们培养的政府自己的技术人员接手了。题目：电子政务实施中的服务意识作者：冷酷到底([e-mail])电子政务建设必须经历“从无到有，从有到好”的过程，所以我们在事实电子政务的时候也必须向用户灌输一个这样的理念，明白电子政务的建设需要过程需要时间，如果达成一个这样的共识的话项目的实施相对来说风险会小的很多，所以晓川先生分析的非常的精辟，但是电子政务建设出现了“用而不验”或“验而不用”那就是项目组的悲哀，所以实施电子政务项目必须要树立一个服务意识，项目靠服务产生利润，而不是单纯的靠产品产生利润！政府向企业买产品，也要买服务。项目应该将设计和实施划分开来，明确设计和实施的区别和界定，这样项目作的轻松，政府用的放心，用户当然也是开心了（特别是领导，电子政务是很大的业绩），总结一句电子政务项目实施要企业要作好定位，服务才是最能产生利润的。题目：关系与商务不能等同作者：陈荣森(深圳市佳创[e-mail])与客户关系亲密固然是好事，但不能等同于在做项目时都事事迁就于客户，朋友是朋友，商务是商务，不能等同，否则会陷入很被动的局面。建议：如果客户领导提出变更的想法，你不好意思明说，但你必须每次都向他列举这样的变更会给系统带来很大的变更和变更的困难，以便给提出变更的客户压力，随着压力的积累，客户再次提变更时会有压力而变得谨慎。题目：如何实施电子政务项目作者：石灵([e-mail])我同意晓川先生的说法。在我国的行政机构中存在的两个突出问题就是领导意志和作风拖沓。相信在短期内这一现象难以消除。因此，阶段目标的制定就变得非常重要。管理水平的提高，往往不在于某项重大制度的变革，而是基于许多细微的、渐进的变化。因此，在进行阶段目标的设定时，要首先提供让政府各级部门感到方便的功能，使他们逐渐具有兴趣，从而形成一种良性循环，其过程如同微软公司的软件发布一样。我们做的是一个财务管理软件，在项目初期我们的项目经理做的售前工作，跟客户了解了大体的需求，并且制定了项目方案，而项目方案是一个很笼统的框架性的东西，而我被指派与客户详细的调研需求，整个项目的与客户面对面接触调研需求共3次，第一次我已完全理解客户的需求和意图，而第二次并没有什么实质性的收获，因为客户给我的时间就很少，我们只简单讨论了与客户现存系统的接口问题，第三次谈需求，客户提出了一些需求而针对他的子系统的结构是很难实现的，当时我极力反对，但反对无效，因为我们的客户分两部分：转包客户、最终客户。这还是个二包项目。而这种很难实现的需求是最终客户提出而转包客户不反对反倒支持。这样三次需求调研的结果就是得到一个业务逻辑异常复杂的业务模型。有了详细的业务模型之后，我很快初步估算出代码最少5万行，并且向项目总监通报了情况，但是项目总监认为项目不可能这么简单，也没去与客户沟通。我只好按着这个需求继续往下进行（当我与客户做二次需求调研时，我就已经变为项目经理的角色，当然此时我就是项目经理了，而原来的项目经理就是现在的项目总监了），当然了，在有了详细业务模型后，我们先设计了软件原型，用了两个星期，这阶段解决了几乎所有的界面组件（有很强的通用性）。然后再与客户讨论原型，不过客户那边的反映很迟缓，光让他确认这个原型就浪费了二十天时间，不过这段时间我也没闲着，开始着想考虑他那个难缠的需求是不是有什么解决方法，结果分析来分析去，最终得出结论，根本不存在什么合适的解决方案，而这块需求倒底做不做一直困惑我很长时间，其实与客户沟通很不方便，因为我们开发的地点与客户不在一个城市里，对于这样的问题我跟客户在msn上沟通过多次，客户都不明白我要说的问题的本质是什么，他还是坚持要实现这个需求，结果为此我又努力偿试寻找解决方案。客户催要一个初步的软件版本，因为但是因业务逻辑的核心问题，我们无法进行业务模块的编码，已经完成的是与业务关系不大的部分。而此时我又进一步估算，代码量应该有8万行了，因为更细致的架构接口已经有了，也就是说一个完整的框架都有了，估算出的代码行数就比较准了。8万行代码远远超出了原来的预算，就是去掉与客户不断的争论业务需求的时间都用来写代码，8万行代码也不是这个费用够用的，目前我处在骑虎难下的境地，公司要求我能拿出有利于我们有说服力的证据来，但事实上，客户除了那个比较难缠的需求外，没有更多多余的需求，而我也只对需求做了一些润色，我觉得这是很有必要的，去掉反倒不妥，并没有增加多余的需求。但就是这样的需求完成他确实需要写8万行代码，如果去掉业务员的功能，我想能精减个一万行代码。那还有7万呢啊。公司要求我在尽可能短的时间内先完成一些基本的功能，但我不知道应该如何划分基本功能，在我看来，这些功能都很必要嘛，可以说大部分功能都是紧扣客户需求的，只有少部分可以暂时省掉。与其说在最短的时候内完成一个基本功能版与客户谈，还不如说在最短的时候内完成软件第一个完整版本（只缺少很少的一点儿功能），短时间肯定没戏。完成了再跟客户谈价钱吗？其实这个项目我们是赔大发了，继续做，公司也是支持不下去的。这个问题难道就无解了吗？案例太长了，大概了解了一下意思：我的建议如下：1.软件开发前期准备做的不到位，项目的准备成本是永远低于实际操作成本（当然在项目完成时间内）；2.将用户需求明细在合同中；3.项目开发的所有功能均按照合同的确定后方案执行，期间用户需求一但有变动，需让用户直接与项目管理人沟通，并明确需求的变动不在我方。个人建议，请参考！题目：重新梳理需求，评估项目和预算，适量要求追加预算作者：游永明(广东省计算中心[e-mail])通过对案例的分析，我们了解到1、对于项目的需求比较清晰，但是核心业务了解不够，同时还存在不合理需求2、项目进度控制存在问题，和客户沟通因为2次转包存在一定的弊端，对客户的引导不够3、对系统基本功能把握不够，其实也是对客