项目范围管理案例25268

合集下载

PMP项目经理的范围管理案例分析

PMP项目经理的范围管理案例分析

PMP项目经理的范围管理案例分析项目管理专业人士或PMP(Project Management Professional)项目经理在他们的职业生涯中扮演着至关重要的角色。

范围管理是项目管理的核心要素之一,对于项目的成功至关重要。

在本篇文章中,我们将通过分析一个PMP项目经理的实际案例来探讨范围管理的重要性以及如何有效地进行范围管理。

案例背景:某公司决定推出一款全新的手机应用程序,以满足用户对于手机应用的需求。

作为项目经理,我被委任负责这一项目,确保项目顺利完成并按时交付。

1. 项目范围的明确定义在范围管理的第一个阶段,我与项目团队一起明确了项目的范围,并制定了详细的项目声明。

我们与客户进行了沟通,了解了用户需求,并将其转化为功能性和非功能性的项目要求。

2. 可交付成果的规划在这个案例中,我们制定了一个详细的项目规划,以确保我们在项目中交付的可交付成果与客户需求相符。

我们利用WBS(Work Breakdown Structure)拆解项目工作,将其分解成可管理的任务列表,为每个任务分配了负责人和时间表。

3. 范围变更的控制在项目执行的过程中,我们意识到客户的需求可能会发生变化。

因此,在范围管理过程中,我们实施了变更控制。

每当有范围变更的请求出现时,我们进行了评估,并在与客户和相关方的讨论后决定是否接受变更。

4. 范围验收在项目接近尾声时,我们进行了范围验收以确保交付的成果符合客户的期望。

我们与客户一起进行了用户验收测试,并解决了任何问题和改进的要求。

本案例中的范围管理过程是项目顺利完成的关键因素之一。

通过明确定义项目范围、合理规划可交付成果、控制范围变更和进行范围验收,我们确保项目按照客户需求交付,并提高了项目成功的概率。

总结:作为PMP项目经理,在项目范围管理中起到关键作用是至关重要的。

通过明确定义项目范围、规划可交付成果、控制范围变更和进行范围验收,项目经理能够有效地管理项目范围,确保项目按照客户需求交付。

中级信息系统监理师之软件项目范围管理案例

中级信息系统监理师之软件项目范围管理案例

中级信息系统监理师之软件项目范围管理案例软件项目范围管理是信息系统监理师的核心工作之一。

在软件开发过程中,范围管理起着至关重要的作用,可以帮助监理师确保项目按照计划进行、控制项目变更,并最终交付符合需求的软件产品。

本文将通过一个软件项目范围管理案例,介绍中级信息系统监理师在范围管理方面的工作。

案例背景:某公司决定开发一个新的电商平台,以提升企业形象和竞争力。

作为信息系统监理师,我们的任务是监管这个软件项目的范围管理。

1. 需求搜集和确认:首先,我们需要与客户合作,搜集并确认项目需求。

在这个案例中,我们与公司管理层、营销团队和技术团队进行了沟通,并使用面谈、问卷调查等方法搜集了需求。

通过客户的需求,我们确定了该电商平台需要具备以下核心功能:- 商品管理:包括商品发布、库存管理和价格管理等功能。

- 订单管理:包括订单生成、支付和退款等功能。

- 用户管理:包括用户注册、登录和个人信息管理等功能。

- 营销管理:包括优惠券发放、促销活动和推广管理等功能。

2. 范围规划:在需求确认后,我们进行了范围规划。

范围规划阶段主要包括以下几个方面的工作:确定项目目标:我们明确了电商平台的目标是提升企业形象和竞争力。

制定范围说明书:我们撰写了范围说明书,详细描述了项目的范围、目标、可交付成果和排除范围等。

编制工作分解结构(WBS):我们编制了WBS图,将项目分解为多个阶段和任务,使得项目的工作可以更加清晰地进行。

3. 范围定义:在范围定义阶段,我们进一步明确了项目的详细需求和交付物,并制定了相应的项目范围说明。

对于商品管理功能,我们明确了需要实现商品发布、库存管理和价格管理等功能,并详细定义了每个功能的具体要求和期望效果。

对于订单管理功能,我们明确了需要实现订单生成、支付和退款等功能,并确定了订单状态流转和支付方式等细节。

对于用户管理功能,我们明确了需要实现用户注册、登录和个人信息管理等功能,并规定了用户权限和个人信息保护措施。

项目范围管理案例

项目范围管理案例

项目范围管理案例项目范围管理是指确定项目目标、阐明项目边界和项目可交付成果,并定义如何管理项目范围的过程。

以下是一个关于项目范围管理的案例。

某公司计划开展一个新的建筑项目,目标是建造一座现代化的办公大楼。

为了确保项目能够按时按质完成,项目经理决定采用项目范围管理的原则。

首先,项目经理召集了相关利益相关方进行会议,包括公司高层、建筑设计师、施工队等。

会议讨论了项目的目标和可交付成果,并确立了项目的整体范围。

经过讨论,项目的目标被明确为建造一座10层楼高的办公大楼,包括内部装修和设备安装等。

接下来,项目经理制定了项目范围说明书,详细描述了项目的范围、目标和可交付成果。

范围说明书还包括了项目的边界和排除的工作内容,例如土地购置和大型机械设备采购等。

项目经理将范围说明书分发给所有相关利益相关方,确保大家对项目的范围有一个共识。

随后,项目经理将项目的范围划分为不同的阶段,并为每个阶段制定了详细的工作计划。

他还与利益相关方一起审查了工作计划,确认每个阶段的可交付成果和工作内容。

这样可以确保项目进展顺利,避免在项目执行过程中出现范围的变更和冲突。

在项目执行阶段,项目经理通过监控和控制项目的进展情况,确保项目在范围内按计划进行。

他与利益相关方保持沟通,及时反馈项目的进展情况,并与他们讨论任何可能影响项目范围的变更。

最后,在项目完成阶段,项目经理进行了项目范围的验证和验收。

他与利益相关方一起检查了项目可交付成果,确保其符合范围说明书中的要求。

如果发现任何范围内的问题,项目经理将及时进行修正和改进。

通过项目范围管理的实施,该建筑项目顺利完成,并在预定的时间内交付。

范围管理的过程确保了项目的目标和可交付成果的明确,并通过监控和控制确保了项目按计划进行。

这个案例展示了项目范围管理在项目成功实施中的重要性。

项目管理-项目范围管理(课件)

项目管理-项目范围管理(课件)
*
5.3.2 蔓延 镀金
*
未得到控制的变更 可交付物和范围定义不一致
范围蔓延
1
为讨好客户,做了不该做的事情等行为称为镀金 项目角度:都是失败的项目
镀 金
2
*
5.3.3 工具与技术-产品分析
*
适用于产品为主要交付成果的项目
产品分解 系统分析 系统工程 需求分析 价值工程 价值分析
*
5.3.3 工具与技术-备选方案识别
WBS词典是针对每个WBS组件,详细描述 可交付成果、活动和进度信息的文件
*
分解步骤
5.4.5 工具与技术—分解
*
核实分配程度是否恰当
制定和分配标识编码
识别可交付成果及相关工作
自上而下的分解
确定WBS结构和编排方法
*
5.4.5 工具与技术—分解
*
分解规则
可交付成果为导向
子要素等于母要素
100%原则
*

自由畅谈、禁止批评
延迟评判
所有的观点被记录下
首要任务追求数量
*
群体创新技术(名义小组技术)
头脑风暴法的深化应用
名 义 小 组 1
名 义 小 组 2
全体投票排列最有用创意 独立思考,写下方案并陈述 主管有权决定接受或拒绝方案
群体创新技术(思维导图)
*

从头脑风暴法
获得创意,用
思维导图联系
起来,反应创
功能需求 非功能需求
*
5.2.2 输出
*
需求文件
记录干系人的需求 单一需求如何满足业务需求
需求跟踪矩阵
链接需求与需求源的表格 对需求进行跟踪 需求与业务目标或项目目标相联系 确保需求都具有商业价值 产品范围变更的框架

项目管理案例

项目管理案例

项目管理案例一、项目背景某公司决定开展一个新的项目,旨在开辟一款全新的挪移应用程序。

该应用程序将提供在线购物、社交媒体和娱乐等多种功能,旨在吸引泛博用户。

为了确保项目的成功实施,公司决定采用项目管理方法来组织和管理该项目。

二、项目目标1. 开辟一款功能完善、用户友好的挪移应用程序。

2. 吸引并留住大量用户,提高公司的市场份额。

3. 在预定的时间内完成项目开辟,并确保项目交付的质量和可靠性。

三、项目范围1. 需求分析:与相关利益相关方合作,采集和分析用户需求,明确项目的功能和特性。

2. 设计和开辟:基于需求分析结果,设计应用程序的界面和功能,并进行开辟和测试。

3. 市场推广:制定市场推广计划,通过各种渠道宣传和推广应用程序,吸引用户。

4. 运营和维护:确保应用程序的正常运行,并及时修复和更新。

四、项目组织1. 项目经理:负责项目的整体规划、执行和控制,协调各个团队成员,确保项目按时交付。

2. 开辟团队:包括软件工程师、UI/UX设计师和测试人员等,负责应用程序的开辟和测试工作。

3. 市场团队:包括市场营销人员和推广人员等,负责制定和执行市场推广计划。

4. 运营团队:负责应用程序的运营和维护工作,包括监控和解决用户反馈的问题。

五、项目计划1. 项目启动:确定项目目标、范围和关键要素,制定项目计划和时间表。

2. 需求分析阶段:与利益相关方合作,采集和分析用户需求,编写需求文档。

3. 设计和开辟阶段:根据需求文档,进行应用程序的设计和开辟工作,进行测试和修复。

4. 市场推广阶段:制定市场推广计划,通过各种渠道宣传和推广应用程序,吸引用户。

5. 运营和维护阶段:确保应用程序的正常运行,及时修复和更新。

六、项目执行1. 需求分析:与利益相关方合作,采集和分析用户需求,明确项目的功能和特性。

2. 设计和开辟:根据需求分析结果,进行应用程序的设计和开辟工作,进行测试和修复。

3. 市场推广:制定市场推广计划,通过各种渠道宣传和推广应用程序,吸引用户。

案例分析:(定义+举例)制定项目范围管理

案例分析:(定义+举例)制定项目范围管理

案例分析:(定义+举例)制定项目范围管理预览说明:预览图片所展示的格式为文档的源格式展示,下载源文件没有水印,内容可编辑和复制项目的范围管理作为一个合格的项目经理,切记要准确控制好项目范围。

孙子兵法中提到“知己知彼,百战不殆”,在一个项目中我们应该知道对方需要什么,自己要做什么,这是项目成功的基础所在。

做过项目的人可能都会有这样的经历:一个项目做了很久,感觉总是做不完,就像一个“无底洞”。

用户总是有新的需求要项目开发方来做,就像用户在“漫天要价”,而开发方在“就地还钱”。

实际上,这里涉及到一个“范围管理”的概念。

项目中哪些该做,哪些不该做,做到什么程度,都是由“范围管理”来决定的。

那么,到底什么是“范围管理”,请跟我们一块来揭开谜底。

几年前,我和一位同事在外地共同参与一个软件项目的开发。

项目本身并不算很大,开始的需求调研进行了很长时间,期间不但几乎拜访了所有部门,还与用户反复讨论,征求意见,需求文档几易其稿。

即便这样仍然有许多不确定因素,搞得人心烦意乱。

当时我牢骚很多,总觉得又花时间似乎还没真正做事。

我的同事经验比较丰富,他给我说了一个他自己的亲身经历。

那时候他在深圳参与一个证券项目,当时软件开发管理非常不规范,基本上是了解需求后就编程序,根本没有太多的交流,需求文档就更没有了。

系统开发出以后,用户不断提出新需求。

每天追着开发人员解决问题,项目实际是一个无底洞,没完没了地往下做,按他的说法是项目成员“肥的拖瘦,瘦的拖死”,实在做不下去只能跑了。

这个故事刚听起来感觉非常可笑,当我自己真正做项目负责人时才体会到这其实是一个项目范围管理的问题。

上面提到我所参与的项目中花费大量时间用于需求调研也是为了确定项目范围。

那么,首先要明确的是项目范围管理中的范围是如何定义的1、什么是范围我们知道项目是为完成产品或服务所做的一次性努力。

因此在这里,范围的概念包含两方面,一个是产品范围,即产品或服务所包含的特征或功能,另一个是项目范围,即为交付具有规定特征和功能的产品或服务所必须完成的工作。

项目管理项目管理案例

项目管理项目管理案例

项目管理项目管理案例公司计划推出一款新产品,为了实现项目目标,公司决定进行项目管理。

以下是该项目的项目管理案例。

一、项目概述:该项目的目标是推出一款全新的智能手机。

该手机具有高性能、良好的用户体验和创新的功能。

预计项目启动后的时间为一年。

二、项目组建:公司成立了一个专门的项目团队,该团队由各个职能部门的员工组成,包括研发、设计、市场、销售和财务等部门的代表。

项目由一位项目经理负责统筹管理。

三、项目计划:项目经理与各个部门的代表进行了沟通,制定了详细的项目计划。

根据市场调研结果,确定了产品的需求和特性,并制定了产品的设计和开发计划。

四、项目执行:在项目执行阶段,各个部门按照项目计划进行工作。

研发团队开展了技术研发和硬件设计,设计团队进行了外观和用户界面设计,市场和销售团队制定了市场推广方案。

五、项目风险管理:为了应对项目风险,项目团队定期进行风险评估和规划。

针对可能出现的技术问题、市场竞争和财务风险等,制定了相应的风险应对措施。

同时,项目团队也制定了项目变更管理计划,以应对项目执行过程中可能出现的变更请求。

六、项目监控:项目经理定期召开项目会议,对项目进展进行监控和评估。

根据项目计划的执行情况,及时调整资源分配和项目进度,保证项目的顺利进行。

项目经理还定期向公司高层报告项目进展情况,以确保项目与公司整体发展目标一致。

七、项目交付:在项目完成后,项目团队进行了最终产品的测试和验证。

确保产品达到了预期的质量标准和用户需求。

随后,项目团队进行了产品的发布和推广,以实现项目目标。

八、项目总结:项目结束后,项目团队进行了项目总结。

分析了项目成功的因素和不足之处,总结了经验和教训,并提出了对未来类似项目的改进措施。

以上是公司推出智能手机项目的项目管理案例。

通过合理的项目组建、项目计划、项目执行、项目风险管理、项目监控、项目交付和项目总结等环节,项目团队成功完成了项目目标,并为公司带来了业务增长和竞争优势。

项目范围管理系统案例

项目范围管理系统案例

第2章项目围管理案例项目的围管理影响到信息系统项目的成功。

在实践中,需求蔓延”是信息系统失败最常见的原因之一,信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能,无论是客户的要求还是项目实现人员对新技术的试验,都可能导致信息系统项目围的失控,从而使得信息系统项目无论在时间、资源和质量上都受到严重影响。

2.1 案例一:围定义阅读以下关于信息系统项目管理过程中围管理方面问题的叙述,回答问题1至问题3。

2.1.1 案例场景希赛信息技术(CSAI 原本是一家专注于企业信息化的公司,在电子政务如火如荼的时候,开始进军电子政务行业。

在电子政务的市场中,接到的第一个项目是开发一套工商审批系统。

由于电子政务要求,该系统涉及到两个互不联通的子网:政务网和政务外网。

政务网中储存着全部信息,其中包括部分信息;政务外网可以对公众开放,开放的信息必须得到授权。

系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是一致可靠,政务网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务网系统。

工是该项目的项目经理,在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同,有其自身的特殊性,若照搬企业信息化原有的经验和方案必定会遭到惨败。

因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实施。

在项目交付时,虽然系统完全满足了性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操作也不够便捷,要求彻底更换。

由于最初设计的缺陷,系统表现层和逻辑层紧密耦合,导致 70%的代码重写,而第二版的用户界面仍不能满足最终用户的要求,最终又重写的部分代码才通过验收。

由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,项目工期也超出原计划的 100%。

【问题1】请不超过 300 字,对工的行为进行点评?【问题2】请从项目围管理的角度找出该项目实施过程中的主要管理问题?不超过200字回答。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第2章项目范围管理案例项目的范围管理影响到信息系统项目的成功。

在实践中,需求蔓延”是信息系统失败最常见的原因之一,信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能,无论是客户的要求还是项目实现人员对新技术的试验,都可能导致信息系统项目范围的失控,从而使得信息系统项目无论在时间、资源和质量上都受到严重影响。

2.1 案例一:范围定义阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述,回答问题1至问题3。

案例场景希赛信息技术有限公司(CSAI 原本是一家专注于企业信息化的公司,在电子政务如火如荼的时候,开始进军电子政务行业。

在电子政务的市场中,接到的第一个项目是开发一套工商审批系统。

由于电子政务保密要求,该系统涉及到两个互不联通的子网:政务内网和政务外网。

政务内网中储存着全部信息,其中包括部分机密信息;政务外网可以对公众开放,开放的信息必须得到授权。

系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是一致可靠,政务内网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务内网系统。

张工是该项目的项目经理,在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同,有其自身的特殊性,若照搬企业信息化原有的经验和方案必定会遭到惨败。

因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实施。

在项目交付时,虽然系统完全满足了保密性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操作也不够便捷,要求彻底更换。

由于最初设计的缺陷,系统表现层和逻辑层紧密耦合,导致70%的代码重写,而第二版的用户界面仍不能满足最终用户的要求,最终又重写的部分代码才通过验收。

由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,项目工期也超出原计划的100%。

【问题1】请不超过300 字,对张工的行为进行点评【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题不超过200字回答。

【问题3】请结合你本人实际项目经验,指出应如何避免类似问题不超过200字回答。

案例分析这是一个失败的项目,张工在项目管理中既有闪光点,也有失败的地方。

但项目管理中的任何差错都会影响项目的结果,而范围管理的失误对项目的影响更为明显。

模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。

张工对项目范围有一定的把握。

在范围定义中,张工发现了不同行业间具有不同的特点,电子政务行业对系统运行环境有着特殊的要求。

根据国家对电子政务的要求,政务内网与政务外网是该行业一致的标准,这与企业信息化是完全不同的。

张工捕获到该需求,并对这个需求进行了清晰的定义,根据瀑布模型的要求,对设计和实现都进行了严格的控制,因此在系统交付时完全满足了用户对保密性的要求。

在这一点上,张工是成功的。

如果在范围定义时忽略了行业标准,项目肯定会招致更大的失败。

但用户界面的风格和操作的便捷性也属于系统范围的一部分。

与系统运行环境一样,我们通常称这类需求为隐性需求。

这类需求往往不是由用户直接提出,而且受行业特点决定的范围所约束。

对于电子政务来说,系统保持一致的风格非常重要。

作为政府对公众开放的窗口而言,并不需要很强的个性化,但一致的界面风格可以体现出政务的严肃性。

考虑到全体民众层次差异较大,大多数访问系统的用户一般都没有接受过系统使用的培训,操作的便捷性也是政务系统必须实现的功能之一。

很明显,对于这些系统的隐性需求张工没有充分考虑,从而导致一而再,再而三的变更。

对于软件项目,所有的需求都必须经过清晰的定义,这些需求都是项目范围的一部分。

张工仅仅注意了其中的一部分,而忽略了用户界面,最终导致项目的失败。

对于电子政务信息系统,尤其是面向公众开放的信息系统,范围定义更加困难。

这些系统的最终用户几乎不会参加需求开发的工作,他们的需求都是间接的,通过政府部门的负责人传递到项目组。

但最终用户的意见对项目的结果会有巨大的影响,这是就对范围管理提出了更高的要求。

除了在范围定义方面的问题外,张工在范围确认和范围控制方面也存在不小的失误。

当系统第一次更改时,就应该意识到系统界面风格和操作便捷性的重要性。

这时应该清晰地定义系统的界面风格和操作风格,并设法进行确认。

如果采取了恰当的措施,第二次的变更是完全可以避免的。

在刚刚进入一个陌生领域的时候,其中充满了各种各样的风险。

隐性的行规和行业特点都是项目范围的风险。

面对这些风险,即使再细致的调研也无法完全避免,也不能完整定义系统的范围。

因此可以考虑采取原型法等方式来提前暴露风险,减少风险带来的损失。

因此在案例中,张工也没有进行充分的风险管理,采用严格的瀑布模型增加了风险发生后带来的损失。

对于这个案例,缺乏良好的设计也是很明显的缺陷。

用户界面中耦合了大量的业务逻辑,这必然增加变更的代价,从而导致大部分代码重写。

若在项目初期意识到界面变更的风险,随之采用良好的设计,将表现层和业务逻辑彻底分开,系统变更的代价也会小得多。

综上所述,项目经理张工在整个案例中,针对范围管理做了一些工作,但不全面,在风险管理和质量管理上也都存在缺陷。

有了上面的分析,这道题就很容易作答。

项目的闪光点在于对系统运行环境进行了清晰的定义,并最终满足了用户的要求;但不充分的范围定义和范围确认招致了项目的失败,而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜,最终导致项目延期100%.因此第一题答案的要点就很明确了:(1)张工注意到了系统运行环境的特殊性,在良好设计和实现的情况下满足了用户的要求。

(2)张工忽略了系统用户的潜在要求,在用户界面和操作的风格上范围定义不清晰,造成系统交付的重大变更。

(3)张工在第一次问题发生后仍没有对范围进行有效的管理,造成了系统第二次的变更。

(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开发。

(5)张工没有对设计质量进行有效的控制,造成表现层中耦合了业务逻辑,增加了修改的代价。

对于第二题,是在第一题的基础上考察对范围管理的理解,因此可以忽略在其他领域的问题。

在范围管理中主要包括如下内容:(1)范围管理计划。

(2)范围定义。

(3)工作分解。

(4)范围确认。

(5)范围控制。

在本案例中,没有专门设计到范围管理计划和工作分解的内容。

从表面上看,范围定义存在明显的缺陷。

但案例中提到系统又发生了第二次变更,由此可见,张工在范围确认和范围控制上也存在不足。

若在问题第一次出现时就进行有效的范围确认和范围控制,则完全可以避免第二次的变更。

因此,第二题的答案要点如下:(1)张工没有挖掘到系统的全部隐性需求,缺乏精确的范围定义。

(2)在发生第一次变更时,张工仍没有有效的范围管理,从而造成系统的二次变更。

(3)重复的系统变更说明张工对系统范围控制不足,导致一而再再而三的反复。

在完成第二题后,第三题就是水到渠成了,第三题的要点见参考答案,此处不再赘述。

项目管理是一个系统工程,没有哪种单一的手段可以有效地改善项目,反之管理中的任何疏忽都可能招致严重的后果,造成项目的失败。

而软件项目的复杂性又决定了项目中的工作环环相扣,问题也总是相互关联的。

在发现问题后,也需要采取多种手段才能彻底解决问题。

这对信息系统的项目经理来说是重大的挑战。

参考答案【问题1】(1)张工注意到了系统运行环境的特殊性,在良好设计和实现的情况下满足了用户的要求。

(2)张工忽略了系统用户的潜在要求,在用户界面和操作的风格上范围定义不清晰,造成系统交付时的重大变更。

(3)张工在第一次问题发生后仍没有对范围进行有效的管理,造成了系统第二次的变更。

(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开发。

(5)张工没有对设计质量进行有效的控制,造成表现层中耦合了业务逻辑,增加了修改的代价。

【问题2】(1)张工没有挖掘到系统的全部隐性需求,缺乏精确的范围定义。

(2)在发生第一次变更时,张工仍没有有效的范围管理,从而造成系统的二次变更。

(3)重复的系统变更说明张工对系统范围控制不足,导致一而再再而三的反复。

【问题3】有效的范围管理包括了从范围定义到范围控制等多方面的工作,每一项工作都是重要的。

对于本案例,要结合行业特点进行需求分析,挖掘系统潜在的需求,同时通过原型等方法来辅助需求的定义,避免范围定义不清晰的问题。

在发生需求变更时需要进行有效的需求控制,尽量在满足用户需求的前提下缩小需求范围,坚决避免需求的再次变更。

2.2 案例二:工作要点阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述,回答问题1至问题2。

案例场景M 集团是希赛信息技术有限公司(CSAI )多年的客户,CSAI 已经为其开发了多个信息系统。

最近,M 又和CSAI 签订了新的开发合同,以扩充整个企业的信息化应用范围,张工担任该项目的项目经理。

张工组织相关人员对该项目的工作进行了分解,并参考了公司同M 曾经合作的项目,评估得到项目,总工作量60 人月,计划工期 6 个月。

项目刚刚开始不久,张工的高层经理S 找到张工。

S 表示,由于公司运作的问题,需要在4 个月内完成项目,考虑到压缩工期的现实,可以为该项目在增派两名开发人员。

张工认为,整个项目的工作量是经过仔细分解后评估得到的,评估过程中也参考了历史上与K 企业合作的项目度量数据,该工作量是客观真实的。

目前项目已经开始,增派的人手还需要一定的时间熟悉项目情况,因此即使增派两人也很难在四个月内完成。

如果强行要求项目组成员通过加班等方式追逐 4 个月完成的目标,肯定会降低项目的质量,造成用户不满意。

因此,张工提出将整个项目分为两部分实现,第一部分使用三个半月的时间,第二部分使用三个月的时间,分别制定出两部分的验收标准,这样不增派开发人员也可以完成。

高层经理认为该方案可以满足公司的运作要求,用户也同意按照这种方案进行实施。

六个月以后,项目在没有增加人员的前提下顺利地完成,虽然比最初计划延长了半个月的工期,但既达到了公司的要求,客户对最终交付的系统也非常满意,项目组的成员也没有感受到很大的压力。

【问题1】请不超过500字,指出张工是如何保证项目成功的【问题2】请不超过500字,试结合案例指出项目范围管理的工作要点案例分析这是一个成功的项目管理案例,项目经理张工有效的运用范围管理,在不同的项目干系人中达成一致,使项目的结果同时满足了高层经理、客户和项目组成员的要求。

作为一个项目管理者,必须熟练掌握和应用项目管理九大领域涵盖的知识与技能,对于进行信息系统开发项目而言,范围管理是其中最重要的技能之一。

软件项目的范围主要是由系统需求构成的,而系统需求既是难以把握的,也是容易调整和控制的。

相关文档
最新文档