IT项目管理案例及答案

IT项目管理案例及答案 案例 10 如何启动项目 海正公司的赵晓东最近心里挺烦。 公司前一段签了一个 100 多万的单子， 由于双方老板 很熟，且都希望项目尽快启动，在签时也没有举行正式的签字仪式。合同签完，公司老 总很快指定赵晓东及其他 8 名员工组成项目组， 由赵晓东任项目经理。 老总把赵晓东引见给 客户老总，客户老总在业务部给他们安排了一间办公室。 项目进展开始很顺利，赵晓东有什么事都与客户老总及时沟通。可客户老总很忙，经常 不在公司。赵晓东想找其他部门的负责人，可他们不是推托说做不了主，就是说此事与他无 关，有的甚至说根本就不知道这事儿。问题得不到及时解决不说，很多手续也没人签字。 项目组内部问题也不少， 有的程序员多次越过赵晓东直接向老板请示问题; 几个程序员 编的软件界面不统一;项目支出的每笔费用，财务部都要求赵晓东找老板签字。赵晓东频繁 打电话给老板，其他人心里想，赵晓东怎么老是拿老板来压人。由此，赵晓东与项目组其他 人员和财务部的人员产生了不少摩擦，老板也开始怀疑赵晓东的能力。 赵晓东的遭遇相信很多项目经理都亲身经历过， 尤其是刚刚开始做行业客户的公司， 往 往是公司的老板和客户单位的某个主管关系不错或业务人员关系做得很到位， 公司老板希望 赶紧做完项目，因此，常常跳过项目启动环节，直接指令项目经理进入实施阶段。结果项目 刚开始就麻烦不断。 参考讨论题: 参考讨论题: 赵晓东遇到了什么问题, 内部问题: 赵晓东遇到了什么问题, 内部 问题: 1、项目内部成员越过项目经理直接请示老总; 2、项目内部人员对建设标准出现不统一情况; 3、项目支出财务部要求赵经理找公司老总签字。 结果: 结果: 1、项目组成员、财务部人员与赵经理产生摩擦; 2、公司老总怀疑项目经理的能力。 外部问题: 外部问题: 1、什么事情都与客户老总沟通，但老总很忙; 2、客户部门负责人推托，手续没人签字。 结果: 结果: 在客户端的工作无法正常开展。 做项目启动的目的是什么, 做项目启动的目的是什么,建立项目管理制度、整理启动会资料等。 1. 项目启动会的任务有哪些, 项目启动会的任务有哪些, 阐述项目背景、价值、目标; 项目交付物介绍; 项目组织机构及主要成员职责介绍; 使双方人员彼此认识，清楚各个层次的接口; 项目初步与风险分析; 项目管理制度; 项目将要使用的工作方式。 2. 3. 在项目启动时应该注重哪些问题, 在项目启动时应该注重哪些问题, 为什么说“好的开始是成功的一半” 为什么说“好的开始是成功的一半”,做项目启动是为了形成一个良好的沟通体 系，让所有与项目相关的人都理解项目的重要性，同时形成一个由双方 老总、项目负责 人和项目组成员所构成的三 级沟通体系，确保项目管理的畅通。 4. 在项目启动时为什么要给项目经理授权, 在项目启动时为什么要给项目经理授权, 案例 11 项目论证 A 公司是国内领先的 IT 设备制造厂商，经过多年的企业信息化实践，网络基础建设和 办公自动化建设已经具备相当的规模，并取得了良好的应用效果。同时，以 ERP/SCM/CRM 为主体的信息化应用架构也初步建成，此外作为提高产 PDM)也在建设当中。随着公司研发业务管品创新能力的产品数据管理系统 ( 理的不断深化，对产品研发的项目管理提出 了更高的要求。 虽然公司整体的研发项目管理体系尚未形成， 但研发管理部门仍然希望将部 分研发项目的核算用信息化手段来实现， 以提高核算准确度。 紧迫的需求提到了公司信息化 项目部门的面前。过去的几年，公司在信息化建设方面的投入巨大，难免有一些急于上马的 项目投入与产出并不十分理想。 而且由于市场环境的迅速变化， 相应的业务模式也在不断的 改变， 从而给信息化系统的适应性提出了相当高的要求。 过去的有些项目启动时期没有很好 地考虑到这些问题，造成一些项目盲目启动、盲目建设，建成后才发现已经不适应业务的变 化。因此，公司对于项目上马的决策已经趋于理性，严格要求做好项目启动前的论证工作。 在满足当前紧迫的业务需求和长远的战略需求之间作好平衡。确保项目建设的成功。 小王作为信息化项目部任命的项目启动管理的负责人， 着手处理该项目启动前的可行性 论证工作。小王发现，这个需求在年初规划时并没有提出项目意向，属于 规划外的项目。在 与业务部门的沟通中， 他发现业务部门对于整体项目管理的模式并不十分清晰， 目前需要解 决的项目核算问题仅仅是项目管理中非常具体的一个需求， 至于项目其它方面的管理， 以及 如何与产品开发过程结合起来，如何利用产品数据管理系统等，都没有考虑。项目建设的系 统只是一个项目管理的临时解决。 对方案的风险也没有进行详细的分析。 而业务部门认 为需求已经十分清晰， 项目的价值也是毋庸置疑的， 至于以后怎样与研发平台的产品数据管 理系统结合起来，那要等立项后，做出了详细的方案才会有答案。此外，业务部门还推荐了 几个产品供应商，希望能尽快选定产品，开展实施。 如果在立项环节出现延误，影响了业务的开展，信息化项目部要承担责任。小王认为业 务的要求十分无理，需求、方案、投入产出、风险，以及业界的产品情况等很多问题都还没 有清楚，根本谈不上选型。沟通过程中，业务人员对小王的工作极为不满，向信息化项目部 经理进行了投诉。 参考讨论题: 参考讨论题: 1( 在“部分研发项目的核算用信息化手段来实现”的问题上，双方存在那些分歧, 在这个案例中，反映了目前企业信 息化项目启动管理中的普遍问题。业务一旦产生 信息化需求，总是非常急迫地希望能立刻上马。而从信息化项目管理的角度，如果 盲目、 仓促地上马信息化项目， 往导致项目的投入产出分析不清， 往 项目重复建设， 组织混乱，给后期的项目实施，项目维护，项目使用带来极大的风险，甚至导致系 统建成后被用户弃用。最终使业 务遭受损失。 本案例中，作为企业的信息化部门，在项目启动管理的重要性方面已经有了较为理性 的认识，但是在应用中不被业务部门理解，从而导致矛盾的激化。这是 双方对项目启动管理 的过程没有达成统一的认识 2( 在项目启动阶段形成统一的认知，对于实施信息化项目的企业有什么重要意义。 相对产品供应商而言，企业在项目建设中处于合同意义上的甲方，其项目的启动过 程与乙方的项目管理有很大的不同，是一个较为复杂的过程。它往往需要考虑一系 列的问题， 需求是否合理,是否有必要启动项目,项目可能带来的影响是什么, 如: 可能的投入有多大,取得的效益有多大,当前的管理模式是否能支撑,如果不 能， 可能要在哪些方面做好变革的准备,业界相关的产品有哪 些,哪些是真正适合需求 的, 因此，对项目启动管理形成统一的认知，对于实施信息化项目的企业有着非常 重要的意义。 3( 在项目立项前应该做哪些方面的论证, 可行性方案的论证是项目启动阶段的关键活动， 它的质量直接影响项目的实施效果。 技术 成本 环境 4 可行性分析的作用和目的是什么, 可行性研究的目的 (1)技术的先进性和适用性 (2)经济上的盈利性和合理性 (3)运行环境上的可能性和可行性 可行性研究的作用 (1)为决策提供依据 (2)可行性研究是项目设计的依据 )为商务谈判、签订有关合同协议提供依据 案例 12 (3)项目评估的依据 (4 投标可行性分析案例研究 玛吉、保罗和史蒂夫，这 3 个人是一家咨询企业的合伙人，该企业专门给医生设计和安 装计算机信息系统。这些系统通常包括对病人记录、处方、帐单和医疗保险过程的处理。有 时医生(客户)有自己的一套人工系统并想要把它计算机化。有时也可能是他们目前有个计 算机系统，需要升级换代并改进。 一般来说，咨询公司会购买必要的硬件和一些软件包。他们会把自己的软件用户化，以 满足医生的具体要求，并且负责安装全部系统。他们也向医生等办公人员提供培训。这些项 目的成本大都在 10000~40000 美元之间， 具体依所需硬件的数量而定。 大部分医生都愿意花 这笔钱，而不愿再雇用额外的办公人员以跟上日益增长的日常文书工作。 豪泽是保罗过去曾为之做过项目的医生之一， 她放弃了自己的业务， 而加入了一个大型 的地区性的诊所。这个组织有遍布各包括 1 间药店。该组织雇用了总 200 人。豪泽与保罗联 系，询问他的咨询公司是否对此项目感兴趣(即为整个地区的诊所的信息系统升级) ，是否 想提交。 项目包括把 6 个办事处和两间药店整合成一个系统。 该组织最后将雇用信息 系统人员来监管系统的运行。目前每个办事处都有其各自的系统。 豪泽医生告诉保罗，别的医生也有曾为大咨询公司工作的患者，他们也想做这项工作。 她说， 在组织中采购经理的帮助下， 来自 6 个办事处和两间药店的代们已经开始准备需求 建议书了。 申请书在两周内就得完成。 需求建议书在两周前就已经发布给大咨询公司了他们 已在准备申请书中了。 采购经理并不了解保罗的咨询公司， 这就是他没有接到需求建议书备 份的原因。 她告诉保罗，她很抱歉无法告诉他更多的信息，但是她在需求建 议书发布之关，并没有 机会像其他医生一样，参加讨论患者就职的大咨询公司的选择。豪泽医生说，如果保罗感兴 趣，并能在两周内提交申请书的话，她会让采购经理给保罗一份需求建议书。 “当然了， ”保罗说， “我将在今天下午 开车来取～ ”他问她是否知道该诊所已经投在项 目上的款额，但是她说不知道。 保罗得到了需求建议书，并给玛吉和史蒂夫做了几份备份。他与他们会面时，保罗很热 心于这次机会。 “如果我们进行这个项目，我们会进入一个崭新的商业舞台!”保罗对他们说， “这可是 我们一直等待的超越机会。 ”他喊道。 玛吉抱怨: “这事儿来得可真不是时候，我正在为其他医生做另外 3 个项目，他们都在 催我早点完成。事实上，他们中有一个还不是很满意。他说如果我在两周内完成不了项目， 他就不需要它了， 并且再也不会把我们推荐给别的医生。 我一天要工作 16 个小时来赶时间。 我太受约束了。我同意你的说法，保罗，经是一个大好机会，但是恐怕我无法再腾出任何时 间帮助你准备申请书了。 ” 史蒂夫大声提出质疑: “准备申请书是一回事，但是我们能做好这个项目吗,我认为我 们 3 个人具有专长，能做这样的项目，但是这确实是一个很大的项目，况且，我们还有其他 的客户。 ” 保罗回答: “我们可以雇用几个人。我有几个朋友想做兼职。我们能做它～如果我们不 做这样的项目，我们将一直是个小公司，我们每个人每天工作 12 个小时，只为了那点儿微 薄的利润。这些为单个办公室而做的小活，不可能永远有的做。总有一天我们全部计算机化 了，我们也失业了。我们只是提出申请书，会有什么损失呢,如果我们不提交申请书，我们 永 远不会有发展” 。 参考讨论题: 参考讨论题: 1( 为什么这个小组没有与大咨询公司同时接到需求建议书, .a。采购经理并不了解保罗的咨询公司，这就是他没有接到 RFP 备份的原因;b。在行业类缺少这个 业务的成功案例和知名度。 2( 为什么这个小组会被考虑作为提交申请书的候选人, 豪泽(Houser)医生是保罗过去曾为之做过项目的医生之一，可能认可保罗的能力和之前做得项目， 并且豪泽医生说， 如果保罗感兴趣， 并能在两周内提交申请书的话， 她会让采购经理给保罗一份 RFP。 结果保罗得到了 RFP。 3( 在投标决策过程中，需要评价的因素有哪些, 竞争对手分析 风险分析 目标分析 声誉与经验分析 客户资金分析 项目所需资源分析 客户本身的资信问题 4( 玛吉、保罗、史蒂夫应当怎么做,解释一下你的回答，表述一下 3 个小组成员每个 人的想法。 这个小组成员应该就保罗获得的这个项目的机会，使用 SWOT 工具进行分析，对这个项目做评审， 是否能够获取一定的利润或者说即时没有利润，完全只是将这个项目作为企业业务能力的一次经验积 累和提升。 玛吉的想法:想做，但没有时间(不愿放弃目前现有客户的项目)---缺少人力资源;史 蒂夫的想法:对公司是否有能力做好表示怀疑，底气不足---缺乏成功案例的经验;保罗的想法:想做 并且要做成功，把公司作强，这是未来生存的唯一出路，并且现在有资源，有能力---我们可以雇用几 个人。我有几个朋友想做兼职。 如果我是这个组的成员，我会力挺保罗的，并配合他完成这个项目 的。 案例 13 10000 元带来的风波 王欣是一个高技术政府部门实验室的项目经理。10 个月前，王欣为项目研发了一个需 求建议书。 工作说明很详细， 并要求在项目收尾时编写最终报告。 项目进度计划大约,个月， 王欣和他的团队估计项目价值为 145000 元。 有很多 个组织对该项目竞标，大多数都是高校。按照法律，合同必须授予合格的、成本 最低的投标者。结果王欣将合同给了一个大学，它的投标是 131500 元。他们的建议书中说 最终报告的编写大约是 140 页，编写成本为 13000 元。 现在是项目的第,个月的月底。 大学负责人通知王欣说他们已经用完了项目的资金， 所 以就不能编写最终报告了。 但是， 王欣应该再给他们 10000 元吗,这样他们就可以编写最终 报告了。 王欣的合同告诉王欣说这个事情是非常频繁的。 政府要对大学采取法律行动， 但运用法 律手段处理的话，所用费用将超过 10000 元(而且，如果政府在法庭上可以胜诉的话，该大 学就可以编写一个简单的只有 20,25 页的报告做最终报告。王欣问合同管理员在以后的竞 标中是否可以将该大学除名，他告诉王欣说不可以，因为这样会限制竞争。 案例问题: 案例问题: 1(为什么会发生这种情况, 2(最初的合同是故意做得比较低吗, 3(如果运用法律手段处理，谁将在法庭上获胜, 4(如果他们在需求建议书中详细地列举了在最终报告中应该包括的条款，这样会对政 府有所帮助吗, 5(你认为这种问题应该如何解决, 6(政府可以避免类似事件不再发生吗,如果可以，怎么 办, 7(需求建议书中应该有一部分内容对政府以前的投标绩效进行评价吗,这合法吗, 答:1.发生这种事的根本原因在于合同中出现了关于资金问题的漏洞，投资方没有在合 同中明确资金使用的条件、标准等问题，是对方有空子可钻。 2.甲方最初只是为了广泛招商，用各种手段类似于降低成本等策略来减少投资的预算资 金，过于重视市场占有率和市场范围，忽略了合同本身关于资金的明确规定，作为项目的一 部分，合同是基本，也是法制体制的关键，一个项目不能仅考虑其市场竞争力与自身预算， 体察市场机制，合同缜密无懈可击才是项目管理的关键所在。 3.我认为不宜进行官司，问题出在自身的合同漏洞上，应尽快加强管理，改善运营机制， 打官司要花费的资金比最终报告还要高， 这样更加超出了预算。 事故发生后应以最小的代价 解决问题，而不是将问题扩大化。成功的项目管理者应以此为戒，避免类似事情再度发生。 如果真的要上法庭，获胜方付出了金钱，却换来了项目管理失误的教训，失败方得到了额外 的钻漏洞的金钱，却失去了今后在市场上的竞争力 案例 14 风华电子 CIMS 需求开发历程 (1)项目背景 风华电子为了上马 CIMS，与天剑公司签定了软件集成开发合同。按照合同要求，系统 必须将 MRPII/ERP 思想引进到系统中，内容覆盖企业的人财物、产供销、质量、工艺等所 有内容，并且实现与条形码的集成， 技术上采用 C/S 架构，网络操作系统采用 Windows NT， 数据库系统采用 SQL Server7。 (2)两项基本工作 项目一开始， 摆在项目组面前的两个主要的问题是: 首先， 企业信息化基础薄弱。 当时， 一个 500 多人、年销售额超过 1 亿的企业，只 有两部 IBM 微机，一部用于电子邮件收发， 一部用于财务自编系统的运行。这种情况下，使已经制定好的项目实施计划受到影响，原先 计划制定的主要步骤包括:调研、分析、设计、分批编码、试运行、分批系统切换、总体集 成、验收。因企业基础较差，调研工作的进展不理想，直接影响到其他工作。 项目组经过研究决定从培训、考察、宣传入手，在企业组织各类培训，例如，CIMS 普 及培训、计算机基本操作培训、 汉字输入培训、 先进管理思想培训、 企业流 程培训等;然后， 组织风华电子的相关人员到其他企业学习、考察，亲身感受信息化应用的效果。 另外，当时企业处于一种快速发展的阶段，组织机构和管理流程不断在变化，这种情况 下，有可能出现软件的开发速度赶不上企业的发展变化，有经验的人员都知道，系统将陷入 一种没完没了的修改之中。怎么办,从管理入手，通过对企业进行调研，天剑公司的开发人 员对企业流程进行了分类:第一类，可以确定下来的流程;第二类，可以变通的流程;第三 类，有可能变化的流程，但变化的情况可以列举;第四类，肯定会变，但不知道怎么变的流 程。 不同的流程在软件设计中采用不 二类按正常的方法设计; 第三类， 采用参数控制法;同的解决办法: 第一、 第四类，细分业务单元，采用用户流程自定义。 (3)建立需求管理工作机制 在进行需求分析时，天剑公司的开发人员抓住决策者最迫切和最关心的问题，引起重 视。例如，整个 CIMS 系统开发初期，库存管理是企业管理的重要组成部分，库存的主要功 能是在供给和需求之间建立缓冲，减缓供需矛盾。库存作为生产、采购、物料需求计划、销 售、成本的依据，保证库存数据 的准确性、完整性与及时性，是保证生产、财务、成本、销 售、采购等其他系统顺利上线的关键，也是整个系统成功与否的关键。开发人员在开发过程 中利用一切机会了解决策者关心的问题，同时也让他们了解项目的情况。在诸如专题汇报、 协调会议、 领导视察、 阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的 问题，引导他们了解和重视项目的开发，当决策者认识到项目的重要性时，需求分析工作在 人力、物力、时间上就有了保障。 建立组织保障，明确的责任分工。天剑公司成立了相应的项目组或工程组，包括:产品 管理组、质量与测试组、程序开发组、用户代表组和后勤保障组。产品管理组负责确定和设 置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程序管理组负责 系统分析，根据软件开发标准协调日常开发工作确保及时交付开发任务，控制项目进度。程 序开发组负责按照功能规范要求交付软件系统。 质量与测试组负责保证系统符合功能规范的 要求，测试工作与开发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件 的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。 建立良好的沟通环境和氛围。 分析人员与用户沟通的程度关系到需求分析的质量， 因此 建立一个良好的沟通氛围、 处理好分析人员与用户之间的关系显得尤其重要， 针对用户作为 投资方会有一些心理优势， 希望他们的意见得到足够的重视的特点， 风剑公司的分析人员充 分的认识到这一点，做好心了理准备，尽量避免与他们发生争执。因为他们的目的是帮助用 户说出他们的最终需要。 在沟通时分析人员注意做到:1)在态度上尊重对方，但 不谦恭。2) 努力适应不同用户的语言表达方式。适应用户的语言风格，理解他们的意思。3)善于表达 自己，善于提问。4)利用工作外的交流来增进理解，加强沟通。 在需求调研及流程梳理顺利结束后， 天剑的开发人员按计划完成了需求分析的任务， 进 入软件设计阶段。 案例问题: 案例问题: 1( 本案例对需求开发工作有哪些成功的经验, 2( 对于不确定、变化的需求天剑的开发人员是如何处理的, 3( 对于用户关心的问题天剑的开发人员是如何处理的, 4( 对需求管理是如何建立组织保障的, 5( 为什么在进行沟通时要“在态度上尊重对方，但不谦恭” ，请说明原 因。 工期拖了怎么办, 案例 15 工期拖了怎么办, 某公司准备开发一个软件产品。 在项目开始的第一个月， 项目团队给出了一个非正式的、 粗略的进度计划，估计产品开发周期为 12~18 个月。一个月以后，产品需求已经写完并得到 了批准， 项目经理制定了一个 12 个月期限的进度表。 因为这个项目与以前的一个项目类似， 项目经理为了让技术人员去做一些“真正的” 技术人员参加，自己编写了详细工作(设计、开发等) ，在制定计划时就没让 进度表并交付审核。每个人都相当乐观，都知道这是公司很 重要的一个项目。 然而没有一个人重视这个进度表。 公司要求尽早交付客户产品的两个理由 是:1)为下一个财年获得收入;2)有利于确保让主要客户选择这个产品而不是竞争对手的 产品。团队中没有人对尽快交付产品产生怀疑。 在项目开发阶段，许多技术人员认为计划安排的太紧，没考虑节假日，新员工需要熟悉 和学 习的时间也没有考虑进去，计划是按最高水平的人员的进度安排的。除此之外，项目成 员也提出了其他一些问题，但基本都没有得到相应的重视。 为了缓解技术人员的抱怨， 计划者将进度表中的计划工期延长了两周。 虽然这不能完全 满足技术人员的需求，但这还是必要的，在一定程度上减少了技术人员的工作压力。技术主 管经常说:产品总是到非做不可时才做，所以才会有现在这样一大堆要做的事情。 计划编制者抱怨说: 项目中出现的问题都是由于技术主管人员没有更多的商业头脑造成 的，他们没有意识到为了把业务做大，需要承担比较大的风险，技术人员不懂得做生意，我 们不得不促使整个组织去完成这个进度。 在项目实施过程中，这些争论一直很多，几乎没有一次能达成一致意见。商业目标与技 术目标总是不能达成一致。为了项目进度，项目的规格说明书被匆匆赶写出来。但提交评审 时，意见很多，因为很不完善，但为了赶进度，也只好接受。 在原来的进度表中有对设计进行修改的时间， 但因前期分析阶段拖了进度， 即使是加班 加点工作，进度也很缓慢。这之后的编码、测试计划和交付物也因为不断修改规格说明书而 不断进行修改和造成返工。 12 个月过去了，测试工作的实际进度比计划进度落后了 6 周，为了赶进度，人们将单 元测试与集成测试同步进行。 但麻烦接踵而来， 由于开发小组与测试小组同时对代码进行测 试两个组都会发现错误， 但是对测试人员发现的错误响应很迟缓， 开发人员正忙于完成自己 的工作。为了解决这个问题，项目经理命令开发人员优先解决测试组提出的问题，而项目经 理也强调测试的重要性，但最终的代码中还是问题很多。 现在进度已经拖后 10 周，开发人员加班过度，经过如此长的加班时间，大家都很疲惫， 也很灰心和急躁，工作还没有结束，如果按照目前的进度方式继续的话，整个项目将比原计 划拖延 4 个月的时间。 案例问题: 案例问题: 1( 在本案例中，我们能吸取什么教训吗, 2( 编制计划时，邀请项目组成员参与有哪些好处, 3( 学习曲线对软件项目有哪些影响, 要熟练使用项目管理包，确实需要花些时间。所需时间根据个人的不同情况和经历而 不同。对于那些目前不使用计算机和商业软件的人来说，会有一个非常明显的学习曲 线。然后，近几年来，由于软件越来越易于使用，使得为掌握软件应用而需要的学习 培训时间大大缩短了。 4( 编制进度计划时需要考虑哪些重要因素, 项目网络图。这是在“活动排序”阶段所得到的项目各项活动以及它们之间逻辑关 系的示意图。 项目活动工期的估算文件。 也是项目时间管理前期工作得到的文件， 这 这是对于已 确定项目活动的可能工期估算文件。 项目的资源要求和共享说明。 这包括有关项目资源质量和数量的具体要求以及各项 目活动以何种形式与项目其他活动共享何种资源的说明。 项目作业的各种约束条件。在制定项目进度计划时，有两类主要的约束条件必须考 虑:强制的时间(客户或其他外部因素要求的特定日期)、关键时间或主要的里程碑(客户 或其他投资人要求的项目关键时间或项目工期计划中的里程碑)。 项目活动的提前和滞后要求。 任何一项独立的项目活动都应该有关于其工期提前或 滞后的详细说明，以便准确地制定项目的工期计划。例如，对项目定购和安装设备的活动可 能会允许有一周的提前或两周的延期时间。 5( 一个成功的项目管 理其基础是什么, 小丁该怎么办, 案例 16 小丁该怎么办, 某系统集成公司现有员工 50 多人，业务部门分为销售部、软件开发部、系统网络部等。 经过近半年的酝酿后， 在今年一月份， 公司的销售部直接与某银行签订了一个银行前置机的 软件系统的项目。合同规定，6 月 28 日之前系统必须投入试运行。在合同签订后，销售部 将此合同移交给了软件开发部， 进行项目的实施。 项目经理小丁做过 5 年的系统分析和设计 工作，但这是他第一次担任项目经理。小丁兼任系统分析工作，此外项目还有 2 名有 1 年工 作经验的程序员，1 名测试人员，2 名负责组网和布线的系统工程师。项目组成的成员均全 程参加项目。在承担项目之后，小丁组织大家制定了项目的 WBS，并依照以外的经历制订 了本项目的进度计划，简单描述如下: 1、应用子系统 1)1 月 5 日,2 月 5 日需求分析 2)2 月 6 日,3 月 26 日系统设计和软件设计 3)3 月 27 日,5 月 10 日编码 4)5 月 11 日,5 月 30 日系统内部测试 2、综合布线:2 月 20 日,4 月 20 日完成调研和布线 3、网络子系统:4 月 21 日,5 月 21 日设备安装、联调 4、系统内部调试、验收 1)6 月 1 日,6 月 20 日试运行 2)6 月 28 日系统验收 春节后， 2 月 17 日小丁发现系统设计刚刚开始， 在 由此推测 3 月 26 日很可能完不成系 统设计。请问问题发生的可能原因，小丁应该如何保证项目整体进度不拖延, 案例问题: 案例问题: 1( 请分析造成项目进度拖延的原因有哪些, 2( 从技术人员转为管理人员，做为项目经理小丁应关注哪些问题, 3( 小丁对进度计 划的控制应该怎样做, 4( 小丁应采用哪些管理措施来保证项目整体进度不被拖延, 【问题 1】 (1)销售部没有及时让软件开发部参与项目早期工作，需求分析耗时过长; (2)项目经理首次担任，经验不足，进度估算不准确; (3)项目资源配置不足，项目经理兼任系统分析，缺乏专门的系统分析和设计人员 (4)工作安排没有充分利用分配的项目资源，资源有闲置; (5)在安排进度时可能未考虑法定节假日的因素 【问题 4】 (1)向职能经理申请增加特定资源，特别是增加系统分析设计人员; (2)将部分阶段的工作改为并行进行，以节约时间 (3)临时加班/赶工，尽可能补救耽误的时间 (4)对后续工作的工期重新进行估算，并考虑节假日问题，修订计划，尽量留有余地 (5)加强沟通，争取客户能够对项目范围以及需求、设计、验收标准进行确认，避免 后期 频繁出现变更。 (6)加强对阶段性工作的检查和控制，避免后期出现返工。 此 外，如有可能还可采取外包和缩减范围等办法，不过不建议在本案例中采用.