当前位置:文档之家› 第2章 项目范围管理案例

第2章 项目范围管理案例

第2章  项目范围管理案例
第2章  项目范围管理案例

第2章项目范围管理案例

项目的范围管理影响到信息系统项目的成功。在实践中,需求蔓延”是信息系统失败最常见的

原因之一,信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能,无论是客户

的要求还是项目实现人员对新技术的试验,都可能导致信息系统项目范围的失控,从而使得信息系

统项目无论在时间、资源和质量上都受到严重影响。

2.1 案例一:范围定义

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

2.1.1 案例场景

希赛信息技术有限公司(CSAI 原本是一家专注于企业信息化的公司,在电子政务如火如荼的时候,开始进军电子政务行业。在电子政务的市场中,接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求,该系统涉及到两个互不联通的子网:政务内网和政务外网。政务内网中储存着全部信息,其中包括部分机密信息;政务外网可以对公众开放,开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是一致可靠,政务内网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务内网系统。

张工是该项目的项目经理,在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同,有其自身的特殊性,若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实施。在项目交付时,虽然系统完全满足了保密性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操作也不够便捷,要求彻底更换。由于最初设计的缺陷,系统表现层和逻辑层紧密耦合,导致70%的代码重写,而第二版的用户界面仍不能满足最终用户的要求,最终又重写的部分代码才通过验收。由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,项目工期也超出原计划的100%。

【问题1】请不超过300 字,对张工的行为进行点评?

【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题?不超过200字回答。

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

2.1.2 案例分析

这是一个失败的项目,张工在项目管理中既有闪光点,也有失败的地方。但项目管理中的任何差错都会影响项目的结果,而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。

张工对项目范围有一定的把握。在范围定义中,张工发现了不同行业间具有不同的特点,电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求,政务内网与政务外网是该行业一致的标准,这与企业信息化是完全不同的。张工捕获到该需求,并对这个

需求进行了清晰的定义,根据瀑布模型的要求,对设计和实现都进行了严格的控制,因此在系统交付时完全满足了用户对保密性的要求。在这一点上,张工是成功的。如果在范围定义时忽略了行业标准,项目肯定会招致更大的失败。

但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样,我们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出,而且受行业特点决定的范围所约束。对于电子政务来说,系统保持一致的风格非常重要。作为政府对公众开放的窗口而言,并不需要很强的个性化,但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大,大多数访问系统的用户一般都没有接受过系统使用的培训,操作的便捷性也是政务系统必须实现的功能之一。很明显,对于这些系统的隐性需求张工没有充分考虑,从而导致一而再,再而三的变更。

对于软件项目,所有的需求都必须经过清晰的定义,这些需求都是项目范围的一部分。张工仅仅注意了其中的一部分,而忽略了用户界面,最终导致项目的失败。

对于电子政务信息系统,尤其是面向公众开放的信息系统,范围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作,他们的需求都是间接的,通过政府部门的负责人传递到项目组。但最终用户的意见对项目的结果会有巨大的影响,这是就对范围管理提出了更高的要求。

除了在范围定义方面的问题外,张工在范围确认和范围控制方面也存在不小的失误。当系统第一次更改时,就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面风格和操作风格,并设法进行确认。如果采取了恰当的措施,第二次的变更是完全可以避免的。

在刚刚进入一个陌生领域的时候,其中充满了各种各样的风险。隐性的行规和行业特点都是项目范围的风险。面对这些风险,即使再细致的调研也无法完全避免,也不能完整定义系统的范围。

因此可以考虑采取原型法等方式来提前暴露风险,减少风险带来的损失。因此在案例中,张工也没有进行充分的风险管理,采用严格的瀑布模型增加了风险发生后带来的损失。

对于这个案例,缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑,这必然增加变更的代价,从而导致大部分代码重写。若在项目初期意识到界面变更的风险,随之采用良好的设计,将表现层和业务逻辑彻底分开,系统变更的代价也会小得多。

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

有了上面的分析,这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义,并最终满足了用户的要求;但不充分的范围定义和范围确认招致了项目的失败,而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜,最终导致项目延期100%.

因此第一题答案的要点就很明确了:

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

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

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

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

(5)张工没有对设计质量进行有效的控制,造成表现层中耦合了业务逻辑,增加了修改的代价。对于第二题,是在第一题的基础上考察对范围管理的理解,因此可以忽略在其他领域的问题。在范围管理中主要包括如下内容:

(1)范围管理计划。

(2)范围定义。

(3)工作分解。

(4)范围确认。

(5)范围控制。

在本案例中,没有专门设计到范围管理计划和工作分解的内容。从表面上看,范围定义存在明显的缺陷。但案例中提到系统又发生了第二次变更,由此可见,张工在范围确认和范围控制上也存在不足。若在问题第一次出现时就进行有效的范围确认和范围控制,则完全可以避免第二次的变更。

因此,第二题的答案要点如下:

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

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

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

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

项目管理是一个系统工程,没有哪种单一的手段可以有效地改善项目,反之管理中的任何疏忽都可能招致严重的后果,造成项目的失败。而软件项目的复杂性又决定了项目中的工作环环相扣,问题也总是相互关联的。在发现问题后,也需要采取多种手段才能彻底解决问题。这对信息系统的项目经理来说是重大的挑战。

2.1.3 参考答案

【问题1】

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

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

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

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

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

【问题2】

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

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

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

【问题3】

有效的范围管理包括了从范围定义到范围控制等多方面的工作,每一项工作都是重要的。对于本案例,要结合行业特点进行需求分析,挖掘系统潜在的需求,同时通过原型等方法来辅助需求的定义,避免范围定义不清晰的问题。

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

2.2 案例二:工作要点

阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述,回答问题1至问题2。

2.2.1 案例场景

M 集团是希赛信息技术有限公司(CSAI )多年的客户,CSAI 已经为其开发了多个信息系统。最近,M 又和CSAI 签订了新的开发合同,以扩充整个企业的信息化应用范围,张工担任该项目的项目经理。张工组织相关人员对该项目的工作进行了分解,并参考了公司同M 曾经合作的项目,评估得到项目,总工作量60 人月,计划工期6 个月。项目刚刚开始不久,张工的高层经理S 找到张工。

S 表示,由于公司运作的问题,需要在4 个月内完成项目,考虑到压缩工期的现实,可以为该项目在增派两名开发人员。张工认为,整个项目的工作量是经过仔细分解后评估得到的,评估过程中也参考了历史上与K 企业合作的项目度量数据,该工作量是客观真实的。

目前项目已经开始,增派的人手还需要一定的时间熟悉项目情况,因此即使增派两人也很难在四个月内完成。如果强行要求项目组成员通过加班等方式追逐 4 个月完成的目标,肯定会降低项目的质量,造成用户不满意。因此,张工提出将整个项目分为两部分实现,第一部分使用三个半月的时间,第二部分使用三个月的时间,分别制定出两部分的验收标准,这样不增派开发人员也可以完成。高层经理认为该方案可以满足公司的运作要求,用户也同意按照这种方案进行实施。

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

【问题1】请不超过500字,指出张工是如何保证项目成功的?

【问题2】请不超过500字,试结合案例指出项目范围管理的工作要点?

2.2.2 案例分析

这是一个成功的项目管理案例,项目经理张工有效的运用范围管理,在不同的项目干系人中达成一致,使项目的结果同时满足了高层经理、客户和项目组成员的要求。

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

软件项目的范围主要是由系统需求构成的,而系统需求既是难以把握的,也是容易调整和控制的。软件系统的需求来源于用户需求,在软件项目目标是满足用户需求的情况下,对于相同的用户价值可以定义出不同的系统需求。举一个简单的例子,用户的需求是“解决口渴的问题”,那么最简单的系统需求可以是递上一杯水,复杂一些的可能是递上一杯热水,更复杂的是递上一杯经过多层过滤的纯净水,当然也可以是打一桶虎跑泉的水,然后沏上一杯龙井茶。

用户当然希望用买矿泉水的钱换一杯正宗的龙井茶,但这样的项目范围肯定会导致项目失败。聪明的软件项目经理总是从范围管理开始,先界定系统的边界,然后再在明确的范围内进行时间、成本、风险等的管理。

在项目中,时间、成本和范围构成了一个稳固的三角形,如图2-1 所示。

对于该三角形来说,任何一边都不可能孤立地改变。换句话说,我们不可能固定其中两边而试图缩短第三边。其实这也是很容易理解的问题,如果项目需要做的东西已经确定(项目范围固定),项目的人员也已经确定(项目成本固定),那么项目需要的时间就也是固定的。同理,已经固定的项目投入和项目时间也只能做出固定的工作。对于这个三角形而言,非但不可能孤立地改变某一边的长短,就是三边的变化比例不一致也不可能。不成比例的变化与孤立的改变某一边是一样的,都将破坏三角形的结构,违反项目的客观规律,最终招致失败。因此有效的范围管理更像一门艺术,可以帮助项目经理在已经确定的时间和成本下完成项目目标。

在本案例中,高层经理S 就提出了试图打破这个三角形的要求。他要求,项目组可以增加部分资源,但要提前两个月完成。初一看,并没有在不增加投入的情况下要求项目提前完成,似乎合情合理,比起既要马儿跑又不让马儿吃草的要求好得多,但细一想,增加的资源和提前的时间还是不成比例。项目经理张工深知此中奥妙,因此在听到高层经理的要求后,马上意识到这是一个不可能完成的任务。

那么该如何解决这个矛盾呢?还是要从这个三角形入手。既然时间和资源的变化已经打破了项目规律,那么不妨根据新的时间和资源来重新划定合理的项目范围,保证项目的正常运作。于是,张工将这个项目拆分为两部分,重新定义这两部分的项目范围,使每一部分的范围都可以与已经确定的资源和时间匹配起来,让项目的运作又重新满足了项目的客观规律,最终取得了成功。

在案例中,还有一些细节需要考生注意。张工最初估算整个项目需要花费60 人月的总工作量,但如果考虑到拆分为两个阶段后会增加设计的复杂度,增加了额外的验收过程等因素,超出原计划半个月是正常的。计划在 6 个月内完成。在把项目拆分后,实际是用了6 个半月的时间,也就是花费了65 人月完成了项目。对于上面介绍的时间、成本和范围的关系而言,仅是在理想情况下成立,即项目成员始终能以固定的成本完成固定的工作。而在实际情况下,项目的工期、复杂度等因素都会对项目造成影响。在案例中,虽然看似两部分工作的总和等于没有拆分前的项目,但这仅对于最终目标而言,拆分后的项目增加了若干中间成果,项目的范围实际上还是扩大了。

因为软件项目的范围直接与需求相关,所以,很多人误认为控制项目范围就是控制需求,而控制的方法就是减少需求的内容。这种理解是完全错误的。

范围控制体现在软件开发的各个阶段,很多范围控制并非是针对客户的要求而进行的。例如,本案例中,范围控制就是针对高层经理的要求进行的。再比如,在设计中,我们既可以设计刚刚够用甚至略有欠缺,通过牺牲系统的扩展性、维护性等方面来简化设计,也可以对系统进行充分良好的设计,甚至可能是过度设计。采取哪一种设计策略也是软件项目范围管理的一部分。项目经理可以根据目前的项目的目标与环境出发,综合考虑质量和成本的约束,制定明确的项目范围,保证项目的成功。根据笔者的经验,即时需求已经确定,通过有效的范围管理仍能给项目带来很大的收益,可以在不牺牲软件质量的前提下通过范围管理来降低项目成本,缩短项目工期。

上面主要针对张工在范围控制方面进行了分析,实际在整个案例中,张工还进行了其他的范围管理工作。

首先,在项目刚刚开始,张工就对项目范围进行了定义,进而划分了WBS 并对项目进行了估算和计划。在S 提出需要缩短工期的要求后,张工首先进行了项目范围的控制,缩小了第一步需要完成的项目范围。紧接着张工又对两阶段需要完成的项目范围进行了重新定义,制定了验收标准。最后,张工对重新定义的范围进行了确认,与客户和高层经理达成一致。

对于项目而言,仅仅管理范围仍不能保证项目的成功。在这个案例中,张工也运用了其

他的管理手段。其中包括,张工对项目进行了估算,这属于项目时间管理的范畴;张工协调了多个项目干系人之间的矛盾,这属于沟通管理的范畴。

有了上面的分析,这道考题的答案也就很清晰了。

2.2.3 参考答案

【问题1】

(1)张工首先对最初的项目范围进行了清晰的定义,并根据定义对工作进行了分解,制定了WBS。

(2)张工对项目进行了估算,且估算结果真实可信,对项目工作量有量化的把握。

(3)在出现新的项目目标后,张工对项目进行了范围控制,缩小了第一阶段实现的范围。

(4)张工对重新定义的项目范围进行了确认,与高层经理和客户达成一致。

(5)张工对项目进行了沟通管理,协调了多个项目干系人之间的矛盾。

【问题2】

项目范围管理的要点:

(1)范围管理计划。

(2)范围定义。

(3)工作分解。

(4)范围确认。

(5)范围控制。

在本案例中,张工首先进行了范围定义和工作分解,得到了清晰的项目范围;在出现新的项目目标后,张工进行了范围控制,重新定义了两个阶段的项目范围;最后,张工将重新定义的范围与项目干系人进行了确认。

2.3案例三:范围确认

阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述,回答问题1至问题3.

2.3.1 案例场景

希赛信息技术有限公司(CSAI )刚刚和M 签订了一份新的合同,合同的主要内容是处理公司以前为M 公司开发的信息系统的升级工作。升级后的系统可以满足M 公司新的业务流程和范围。由于是一个现有系统的升级,项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下,很快地完成了需求开发的工作并进入设计与编码。由于M 公司的业务非常繁忙,M 公司的业务代表没有足够的时间投入到项目中,确认需求的工作一拖再拖。张工认为,双方已经建立了密切的合作关系,李工也参加了原系统的需求开发,对业务的系统比较熟悉,因此定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。

进入编码阶段后,李工因故移民加拿大,需要离开项目组。张工考虑到系统需求已经定义,项目已经进入编码期,李工的离职虽然会对项目造成一定的影响,但影响较小,因此很快办理好了李工的离职手续。

在系统交付的时候,M 公司的业务代表认为已经提出的需求很多没有实现,实现的需求也有很多不能满足业务的要求,必须全部实现这些需求后才能验收。此时李工已经不在项目组,没有人能够清晰地解释需求说明书。最终系统需求发生重大变更,项目延期超过50%, M 的业务代表也因为系统的延期表示了强烈的不满。

【问题1】请以400 字对张工在项目管理工作中的行为进行点评。

【问题2】请从项目范围管理的角度找出该项目实施过程中的问题,以500字内回答。

【问题3】请结合你本人项目经验,谈谈应如何避免类似的问题,以500 字内回答。2.3.2案例分析

这是一个失败的软件项目,与很多失败的软件项目一样,在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环,这是每个从事信息系统建设的项目经理都清楚的事情,但往往又因为一时的疏忽而造成需求的重大缺陷,最终导致项目的失败。案例中的项目经理张工就是既重视需求又没有控制好需求的一个例子。

在案例中,张工接手了一个系统升级的软件项目。对于这样的项目,首先需要熟悉原有的系统,然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新系统的需求问题。

这无疑是一个很好的办法,可以快速准确地把握新系统的需求。从这一点上来说,张工是成功的,找到了合适的资源进行需求的开发与定义。李工也没有让张工失望,很快就整理出了新系统的需求,并进入了设计和编码阶段,除了客户太忙没有时间确认需求外,一切尽在张工的掌握之中。这是一个阳光灿烂的开端,如果一切顺利的话,项目的成功也就是早晚的事情。就如同大多数经典的悲剧故事一样,故事的序幕是美好的。

晴朗的天空飘来一块乌云,李工要移民加拿大。不过仅仅是一片乌云而已,并没有下起雨来。

开发出的需求都已经过设计,一些编码工作也已经开始,李工的工作已近圆满完成,毕竟,一些细枝末节的问题还可以同客户直接沟通。

经过项目组努力,项目终于完成开发,准备发布了。这时,乌云开始下雨,问题爆发了。客户不认可项目组的工作,认为很多需求没有实现,实现的功能也与需求不符。

谁是这个项目组的罪人呢?李工?还是张工?换一个思路考虑一下,如果李工没有离开项目组,结果又会是什么样呢?客户会因为李工还在项目组就认可这个系统吗?很显然,不会。至多可以在双发的协商下少一些变更,项目延期不是50%,而是30%而已。如果非要区分50%和30%的区别,也不过是五十步笑百步而已。

从项目管理的角度来说,项目范围直接决定了工作量和工作目标,所以项目经理必须管理项目的范围。在范围管理中,范围定义、范围确认和范围控制又是最核心的三项活动,缺一不可。范围定义是基础的活动,不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义的范围,是范围控制的依据。范围控制的作用在于减少变更,保持项目范围的稳定性。

在案例中,由于张工没有进行范围确认,最后的范围控制也就变成了无本之木,控制过程肯定变成了讨价还价,失去本身的意义。

在软件系统的开发中,系统需求就是项目的范围。从软件诞生至今的几十年中,人们探索出了很多获取系统需求的方法,但是熟悉软件开发的人都知道,无论哪种方法都不可能定义出完美无误的需求,需求中的缺陷必然存在,无法完全避免。因此需求确认或者说是范围确认就显得更为重要。

有人可能会说,很难说服客户在需求上签字,很难让客户为需求的缺陷负责。以现在软件行业的情况,这种说法是不无道理的。让客户在需求上签字很困难,但并不等于就不需要进行范围确认,而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审、详细记录最原始的调研材料,让客户确认调研报告、采用迭代开发逐步确认系统需求,都是可以采用的方法。这些方法虽然没有直接确认需求分析报告,但至少可以让现有需求在项目组和客户之间达成一致,提供范围控制的基准,一样可以达到范围确认的目的。

再回到这个案例,项目经理张工乐观认为李工开发的需求没有什么问题,也误认为双方已经有良好的合作,在不紧逼要求客户代表签字显得不近人情,于是就抱着侥幸信息进入了开发。然而最终的结果是,项目延期严重,业务代表反而更不满意,张工也要承担项目延期造成的成本增加的责任。

有了上面的分析,后面问题的答案就不难得出。首先看第一个问题,对张工的行为进行点评。前面已经提到,张工注意到了需求的问题,专门找到了原系统需求负责人李工进行需求开发,这是对项目有利的一面。但由于缺少需求评审和确认的过程,造成需求中的缺陷没有被及时发现,系统需求没有与客户确认,造成缺少需求控制的基准,最终导致需求的重大变更。

对于第二题,联系范围管理的知识,我们不难发现张工在范围确认和范围控制中都有重大的缺陷,在范围定义中也由于缺乏评审造成需求的质量问题。

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

2.3.3 参考答案

【问题1】

(1)张工为了更明确地把握系统需求,聘请了原系统的需求调研人员李工,提高了需求定义的效率和质量。

(2)张工没有对李工开发的系统需求进行评审和复查,从而使得需求的缺陷没有被及时发现。

(3)张工没有要求用户对已经定义的需求进行确认,从而导致需求理解的偏差。

(4)张工对需求的不能进行缺乏有效控制,最终造成项目延期50%.

【问题2】

该项目实施过程中的主要问题包括:

(1)在范围定义中,张工没有对李工定义的需求进行评审,造成需求中的质量缺陷没有被及时发现。

(2)在范围确认中,张工没有主动地要求用户对需求进行确认。

(3)在范围控制中,张工无法进行有效的范围控制,最终造成了重大的需求变更。

【问题3】

对于本案例,项目经理需要对需求定义的结果进行质量控制,采取评审等方式减少需求中的问题。对已经定义的需求需要与用户进行确认,保证双方理解的一致。在发生需求变更时,也应该采取灵活的手段,在满足用户需求的前提下,尽量减少需求变更的范围。

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

项目的范围管理 作为一个合格的项目经理,切记要准确控制好项目范围。孙子兵法中提到“知己知彼,百战不殆”,在一个项目中我们应该知道对方需要什么,自己要做什么,这是项目成功的基础所在。做过项目的人可能都会有这样的经历:一个项目做了很久,感觉总是做不完,就像一个“无底洞”。用户总是有新的需求要项目开发方来做,就像用户在“漫天要价”,而开发方在“就地还钱”。 实际上,这里涉及到一个“范围管理”的概念。项目中哪些该做,哪些不该做,做到什么程度,都是由“范围管理”来决定的。那么,到底什么是“范围管理”,请跟我们一块来揭开谜底。 几年前,我和一位同事在外地共同参与一个软件项目的开发。项目本身并不算很大,开始的需求调研进行了很长时间,期间不但几乎拜访了所有部门,还与用户反复讨论,征求意见,需求文档几易其稿。即便这样仍然有许多不确定因素,搞得人心烦意乱。当时我牢骚很多,总觉得又花时间似乎还没真正做事。 我的同事经验比较丰富,他给我说了一个他自己的亲身经历。那时候他在深圳参与一个证券项目,当时软件开发管理非常不规范,基本上是了解需求后就编程序,根本没有太多的交流,需求文档就更没有了。系统开发出以后,用户不断提出新需求。每天追着开发人员解决问题,项目实际是一个无底洞,没完没了地往下做,按他的说法是项目成员“肥的拖瘦,瘦的拖死”,实在做不下去只能跑了。 这个故事刚听起来感觉非常可笑,当我自己真正做项目负责人时才体会到这其实是一个项目范围管理的问题。上面提到我所参与的项目中花费大量时间用于需求调研也是为了确定项目范围。那么,首先要明确的是项目范围管理中的范围是如何定义的?

1、什么是范围? 我们知道项目是为完成产品或服务所做的一次性努力。因此在这里,范围的概念包含两方面,一个是产品范围,即产品或服务所包含的特征或功能,另一个是项目范围,即为交付具有规定特征和功能的产品或服务所必须完成的工作。在确定范围时首先要确定最终产生的是什么,它具有哪些可清晰界定的特性。要注意的是特性必须要清晰,以认可的形式表达出来,比如文字、图表或某种标准,能被项目参与人理解,绝不能含含糊糊、模棱两可,在此基础之上才能进一步明确需要做什么工作才能产生所需要的产品。也就是说产品范围决定项目范围。 举例说明可能会更好理解一些。假设你在一家培训公司做培训专员,负责组织一次PMP(美国项目管理专业人员认证)考前培训。那么我们完全可以把这项工作当成一个项目来管理,如何确定产品范围和项目范围呢?培训产生的不是有形的产品,而是无形的服务。组织PMP考前培训的目的是讲授项目管理体系基础知识,提高学员的项目管理理论水平,为参加PMP考试做准备,这就是产品范围。如果学员突然提出想获得如何提高企业核心竞争力的知识,很明显此内容不在本项目的产品范围之内。有了明确的产品范围,接下来就可以确定为达到这个目的需要做哪些工作,即项目范围。首先要聘请知名的项目管理权威专家,拟订授课内容,根据授课内容准备学员教材,联络舒适的培训地点,安排好学员食宿。开始培训也并非万事大吉,每天都要与学员交流,听取他们的意见并反馈给老师,甚至学员的日常起居都要过问。由于PMP考试是英文试题,而模拟习题都是中文,假设某些学员希望讲解一些英文题以避免翻译带来的理解偏差,这时老师就要多讲一些内容,产品范围有所扩大,但从总的培训目标看是合理的。

项目范围管理

项目范围管理 项目范围管理的内容 1.范围计划编制 2.范围定义 3.创建工作分解结构 4.范围确认 5.范围控制 项目范围管理,包括为成功完成项目所需要的一系列活动,以确保项目包含且仅仅包含项目所必须的完成的工作。 产品范围 产品范围表示产品或服务的特性或功能,包含产品的规格、性能、技术指标等描述,即产品的特征和具体功能。 项目范围 项目范围是为了完成具有所规定特征和功能的产品必须完成的工作。 项目范围对项目的影响是决定性的。 项目只有完成项目范围中的全部工作才能结束,因此一个范围不明确、或干系人对项目范围理解不一致的项目是不可能获得成功的。 项目范围不明确最可能的后果是,项目的范围蔓延,项目永远都做不完。 对范围理解不一致的结果往往使项目组的工作无法得到其他项目干系人的认可。 需求不明确的系统总会产生新的需求。 需求理解的偏差则会造成系统的严重缺陷。 用户不会接受一个没有满足要求的软件系统,开发团队只能返工。 项目的几个生命周期和管理过程、项目的一次性和临时性,共同决定了项目的工作范围是有限的,可控的,不是无限制的和无序的。 对项目范围的管理及控制的有效性,是衡量项目是否成功的一个必要标准。 项目范围管理能够让项目管理和实施人员知道为达到项目目标,需要完成哪些具体的工作,清楚相关各方在每项工作中清晰的分工界面和责任。

详细、清晰的界定分工界面和责任,不但利于项目实施中变更管理和推进项目发展,减少责任不清的事情发生,也便于项目结束时项目范围的清晰确认。 对项目范围定义,实际上就是对项目工作范围进一步细化的过程,使项目范围具体化、层次化、结构化,从而达到可管理、可控制、可实施的目的,减少项目的风险。 WBS 是一种以结果为导向的分析方法,用于分析项目所涉及的工作,所有这些工作构成了项目的整个工作范围。 WBS为项目进度成本、变更的计划和管理提供了基础。 制定WBS 的主要方法包括 1.使用指导方针 2.类比法 3.自上而下法 4.自下而上法 项目范围的确认是指项目干系人对项目范围的正式承认。项目范围确认是贯穿整个项目生命周期的。从开始组织确认WBS的具体内容,到各个项目阶段的交付物检验,直至最后项目收尾文档的验收,甚至是最后项目评价的总结。 项目范围控制实际上发生在项目实施阶段,也就是计划执行阶段,只有具体实施项目,才有可能产生项目范围的变更。因为项目环境、资源水平和管理能力等因素,会造成项目范围在实施过程中的增加和减少。 对项目范围变更控制的主要工具有: 建立并运用项目变更控制系统 规避变更控制 划清相关责任 项目范围管理水平低下,是项目失败的主要因素之一。要实现高水平的项目范围管理,重要做好用户参与,明确需求,以及范围变更管理的程序设置。 确认项目范围对项目管理的意义 1.清楚项目的具体范围和具体工作,为准确估算时间和资源打下基础。 2.项目范围是确定要完成哪些具体的工作,项目范围管理和控制是项目管理计划的一部分,也是 项目各项计划的基础,因此项目范围计划编制是确定项目进度、测量和控制的基准。 3.项目范围确定,就是确定项目的具体工作任务,这样有助于清楚的划分责任和分派任务,为进 一步安排工作和任务打下基础。

完整版项目管理案例经典分析珍藏版

案例1背景: 某钢厂改造其烧结车间,由于工期紧,刚确定施工单位的第二天,施工单位还未来得及任命项目经理和组建项目经理部,业主就要求施工单位提供项目管理规划,施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计,其内容深度满足管理规划要求,但业主不接受,一定还要求施工单位提供项目管理规划。 问题: ①项目经理未任命和项目经理部还未建立,就正式发表了施工组织设计,其程序是否正确? ②业主一定要求施工单位提供项目管理规划,其要求是否一定正确? ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及内涵。 ④试说明施工项目管理规划的控制原则。 答:①程序不正确,公司还未任命项目经理,项目经理部还未建立,施工组织设计无人审核和批准,不能发表。 ②施工组织设计可以代替施工项目管理规划,但施工组织设计的内容深度应能满足施工项目管理规划的要求;冶金建设工程中,实际上一直使用施工组织设计代替项目管理规划;施工单位可以向业主说明提供的施工组织设计的内容深度已达到项目管理规划的深度要求,不必再编制项目管理规划。 ③施工项目管理规划的规划目标及内涵有: a.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他内容等; b.内涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为:实现最优化控制;动态控制;主动控制;全过程控制;全要素控制;建立大控制系统的观念;要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进,进一步进行总结。 案例2背景: 华北某厂1260m3级高炉扩容改造工程。根据招标文件要求,为了实现快速、高效、优质、低耗地完成扩容改建任务,该扩容改造,应采用高炉整体平移新技术。高炉分两段安装:第一段为移送;第二段为悬吊,高炉本体工程拟定在拼装平台上基本完成,尽量缩短停炉后施工工期,保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合,标高与原设计标高相符,误差控制在5~8m”。高炉本体移送重量约4500t。推移高度约为36m,推移距离约42m。高炉本体在液压缸推动下,分步向炉基平移。 问题: ①结合本案例谈谈项目目标的制定。

项目管理经典案例

一个项目经理的困难选择 张炎正在打电话的时候,他的秘书拿进来一封总部抄送的来自德勤公司的信。张炎是益达公司的项目经理,这两年一直在负责公司在海外的项目开发业务。而此刻这封信正是关于张炎所负责的一个香港的项目。 由于益达是在NASDAQ上市的公司,每个季度的财务报表要经过德勤公司的严格审计。益达核算项目收入的方式是采用完工百分比法,即随着项目的时间进度,按比例将合同款记入公司收入。这个项目2003年9月合同签订之日起,到2004年11月,历时1年多,合同款的80%也已经记入公司收入,而客户实际上的现金支付只有合同款的30%。2004年12月德勤在对公司的审计中发现了这一问 题,于是便寄来这封信,要求公司给予说明。财务部给出的建议是:请德勤向客户公司发欠款确认书,以此证明益达没有虚假账面收入。但是客户公司会签署这份确认书吗?张炎实在是没有把握。 益达公司和AHZ软件 益达公司成立于1992年,伴随着中国电信和因特网事业一路成长发展。其中AHZ软件是益达的核心产品,在国内为中国电信、中国移动等多家大型运营商提供对用户的管理和计费功能。 2003年香港凯业公司对益达的AHZ计费系统表示了兴趣,而益达的董事会也把这次合作看作步入海外市场的重要机遇。凯业成立于1994年,是香港首批获得允许为公众提供互联网服务的电信服务提供商之一,其主要投资方来自于日本。2003年9月,益达公司和凯业公司签署了用户管理和计费软件开发合同,合同金额为695,000美元。在这次项目中,益达将以AHZ产品为基础,结合凯业的业务需要,进行客户化和二次开发工作。对益达来说,这是公司第一个海外项目,标志益达业务步入了国际市场,这一消息使益达在NASDAQ的股票价格因

第六章(一)范围管理案例分析

1范围定义 1.1 案例场景 希赛信息技术有限公司(CSAI原本是一家专注于企业信息化的公司,在电子政务如火如茶的时候,开始进军电子政务行业。在电子政务的市场中,接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求,该系统涉及到两个互不联通的子网:政务内网和政务外网。政务内网中储存着全部信息,其中包括部分机密信息;政务外网可以对公众开放,开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是一致可靠,政务内网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务内网系统。 张工是该项目的项目经理,在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同,有其自身的特殊性,若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实施。在项目交付时,虽然系统完全满足了保密性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操作也不够便捷,要求彻底更换。由于最初设计的缺陷,系统表现层和逻辑层紧密耦合,导致70%的代码重写,而第二版的用户界面仍不能满足最终用户的要求,最终又重写的部分代码才通过验

收。由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,项目工期也超出原计划的100%。 1.2 问题 问题1:请大家对张工的行为进行点评。 问题2:从项目范围管理的角度找出该项目实施过程中的主要管理问题。 问题3:如何避免类似的问题 1.3 参考答案 【问题1】 (1)张工注意到了系统运行环境的特殊性,在良好设计和实现的情况下满足了用户的要求。 (2)张工忽略了系统用户的潜在要求,在用户界面和操作的风格上范围定义不清晰,造成系统交付时的重大变更。 (3)张工在第一次问题发生后仍没有对范围进行有效的管理,造成了系统第二次的变更。 (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理,而是采用了对风险适应性较差的瀑布模型组织开发。

项目管理范围答案

项目管理范围 二、名词解释 21、项目章程 项目章程是正式批准项目的文件。任何一个项目,都是由一个或多个原因而被批准的,这些原因包括市场需求、营运需要、客户要求、技术进步、法律要求和社会需要等。主管部门必须作出批准或不批准某个项目并且颁发项目章程的决策,决策主要基于项目对于项目所有人和赞助人的价值和吸引力。而其前提则是可行性研究的审查和通过。 22、范围变更控制 是指为使项目向着有利于项目目标实现的方向发展而变动和调整某些方面因素而引起项目 范围发生变化的过程。 23、情景分析法 情景分析法又称脚本法或者前景描述法,是假定某种现象或某种趋势将持续到未来的前提下,对预测对象可能出现的情况或引起的后果作出预测的方法。 24、PMO 即Project Management Office(项目管理办公室),是随着IT产业的潮流应运而生的产物,最初的目的是节约成本,提高项目成功率,以及实施标准流程,以应对越来越多的项目管理任务。 三、简答题 25、项目范围说明书的内容 包含项目的目标、产品范围描述、项目的可交付物、项目边界、产品验收标准、项目的约束条件、项目的假定。 26、项目组织结构的类型 1、职能式组织结构。 2、项目式组织结构。 3、矩阵式组织结构。 4、复合式组织结构。 27、项目建议书的定义内容 定义:是拟建项目单位向国家提出的要求建设某一项目的建议文件,是对工程项目建设的轮廓设想。 内容:(1)项目提出的必要性和依据。 (2)产品方案、拟建规模和建设地点的初步设想。 (3)资源情况、建设条件、协作关系和设备技术引进国别、厂商的初步分析。 (4)投资估算、资金筹措及还贷方案设想。 (5)项目进度安排。 (6)经济效益和社会效益的初步估计。 (7)环境影响的初步评价。 28、马斯洛需求层次理论 即马斯诺需求层次理论,是美国犹太裔人本主义心理学家亚伯拉罕·马斯洛在1943年在《人类激励理论》一书中提出的需要层次论,将人类需求象阶梯一样从低到高按层次分为五种,分别是:生理需求、安全需求、社交需求、尊重需求和自我实现需求五类,是行为科学理论之一。

软件项目管理与案例分析 期末复习题

《软件项目管理与案例分析》复习题 一选择题 1. 核心计划过程有明确的依赖关系,在大多数项目中要以同样的顺序必须完成。下列哪一项符合核心计划过程的正确顺序:. A. 范围规划--范围定义--活动排序--活动工期估计 B. 范围定义--范围规划--活动定义--活动排序--活动工期估计 C. 范围规划--范围定义--活动排序--活动定义--活动工期估计 D. 活动工期估计--范围规划--范围定义--活动定义--活动排序 参考答案:A 2. PERT和CPM的主要区别在于PERT: A.在计算进度时使用分布的均值(预期值) B.使用最可能估算计算浮动时间 C.侧重计算浮动时间来确定那些活动的进度没有灵活性 D.在图中包括了回路或条件分支活动 参考答案:A 3.由于你的项目的范围发生变更,因此成本基线也发生变更。你的下一步将是: A.估计范围变更的程度 B.更新预算 C.记录获得的经验 D.执行得到批准的范围变更 参考答案:D

4. 以下哪项不属于合同管理的部分? A.评估风险 B.确认已经送出建议书 C.确认已经进行了合同变更 D.回答潜在卖方的问题 参考答案:D 5. 你负责对项目进行成本估计工作。因为要求成本估计尽可能精确,所以你决定做出保守的估计。你的第一步工作是: A、确定一种计算机工具帮助进行估计成本 B、利用以前的项目成本估计 C、确定并估计项目的每项工作的成本 D、咨询各方面的专家,并在他们的建议的基础上进行成本估计 参考答案:C 6. 项目整体管理是指? A.复杂系统的软件集成管理 B.将系统开发过程的管理和项目管理结合起来 C.将系统的主机平台.网络平台.应用软件开发和系统环境建设作为一个整体来进行项目管 理 D.包括在项目生命周期中协调所有其它项目管理知识领域所涉及的过程 参考答案:B 7. 涉及多领域工作的复杂项目最好由下列哪种组织形式管理: A.项目型 B.职能型

项目管理最佳实践案例

项目管理最佳实践案例 主讲:陈宝光(通用管理、内训师培养高级讲师) 课程对象:企业中层管理者、项目总监、项目经理、项目工程师、项目相关参与人员。 【课程背景】 项目是遗憾的艺术:每次结束的时候都觉得本来还可以发挥更大的价值。即便技术质量指标都达到了要求,使用部门或者公司领导也还有不满意的地方,为什么会这样呢?其实每个项目在运行过程中,总会出现这样或那样的问题,比如:项目管理者的鼓励和推动不够 项目总监一开始就没有想透彻,项目团队的专家没有帮助领导整理思路 项目团队有经验的人手不足 中期设计开发的时候谁都有新要求 后期上线的时候大家方才如梦初醒:怎么是这么个东西 随着生产规范化、流程化,以及企业管理国际化的大环境下,越要求企业面向项目化管理。而在每一个项目运行过程中,项目经理都充当着非凡的角色,需要他们能够: 能够充分协调资源,保障项目有效运行, 制定详细的项目运行计划; 对项目各阶段的内容实施与进行动态跟踪; 促进多部门的沟通协作; 有效控制项目各阶段风险…… 以保证每个项目能够在预定的时间、预算和质量要求下达到的最终成功。 特别推出《项目管理最佳案例实践》课程,重点面向企业中高层经理,项目经理、核心项目组员,通过培训,帮助受训人员掌握现代的项目管理知识和运用方法,并结合万千项目实例,指导管理人员梳理和优化现有项目管理流程,建立有效的项目运行和控制体系。学会运用国际先进项目管理思想,熟练使用项目管理模版工具,进行实际项目练习,有效提高可操作性。 【课程价值】

全面认识项目管理,理解并掌握项目管理思维。 掌握项目管理工具及方法使用。 提高项目规划及管理能力。 提高项目计划能力,加强对项目的实施和控制能力。减少项目成本,提升管理效率。 【培训内容】 导入: 目管理的好处 第一单元:项目管理概论 有关项目活动的知识、技能、工具和技术的运用 视频案例: PMI与PMP PMI在项目管理的经验教训有哪些 第二单元:项目管理五大流程及项目流程之间的关系 1、启动流程 2、项目文件的展开 3、项目任务书 4、目标确定的标准 5、项目范围管理

项目管理讲义第五章项目范围管理

第五章项目范围管理 项目范围管理包括的程序,要求能确保该项目所覆盖的整体工作要求和单项工作要求,从而促使项目工作成功地完成。它首先涉及到界定和控制项目包括的内容。图表5-1提供了主要项目范围管理程序的总述: 5.1启动阶段--督促项目管理组织开始着手项目下一阶段的工作。 5.2范围规划报告--写出一份书面报告,作为未来项目决策基础。 5.3范围界定--把主要的项目工作细目分解成更小、更易管理操作的单元。 5.4范围核实--正式认可这个项目范围。 5.5范围变化控制--对项目范围的变化进行控制。

同其他理论体系中的程序一样,这些程序彼此互相影响。根据项目计划的需要,每个程序可能会需要一个或多个个体或团体的努力。在每个项目阶段,每个程序通常至少发生一次。 尽管这里提到的这些程序是作为各自独立的因素给予了明确的界定,但是,在实践中它们是以各种形式重迭和影响的。这里就不详细论述了。程序的互相影响在第3章中作了详细的讨论。 根据项目中的上下文关系,"范围"这个词涉及到两方面内容: 产品范围界定--产品范围的特征和功能包含在产品或服务中。 工作范围界定--项目工作的完成为的是能交付一个有特殊的特征和功能的产品。 本章的核心是阐述用于管理项目的程序、工具和技术。用于管理项目产品范围变化的程序、工具和技术,在不同应用领域中会有所不同,通常它们被认为是项目生命周期的一部分(项目的生命周期在2.1中阐述)。 一般情况下,一个项目是由一个单个产品组成的,但是,这个产品可能包括几个子要素,每个子要素都彼此分离,但是在产品活动范围中又相互依存。例如:一个新的电话系统,通常包括四个子要素--硬件、软件、试运行和完成。 产品范围的完成情况是参照客户的要求来衡量的,而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性,以确保项目的具体工作成果,能按特定的产品要求准时交付。 5.1启动阶段 启动阶段是正式认可一个新项目的存在,或者是对一个已经存的项目让其继续进行下一阶段工作的过程(看2.1,对项目阶段有详细的阐述)。在一些组织中,一个项目计划的正式启动,是在必要的学习、初步的计划和其他相当于划分项目开始阶段的工作完成后才进行的。有些项目形式,如特殊的内部服务项目和新产品开发项目,它们的启动不是很正规,要受到所做的工作数量的制约,目的是为项目正式启动时,

项目范围管理案例最新版本

项目范围管理 一、项目范围说明书 该项目具体分为5个小部分:1、歌唱校园比赛2、校庆游园活动3、校园一角图片书法展4、校庆拔河比赛5、校庆文艺晚会。宣传活动将会统一进行。总成本要控制在75000元内。虽然校园一角图片书法展是首先开始展览,但是以歌唱校园的决赛为一系列校庆活动的开幕式,以校庆文艺晚会为圆满结束。各小项目必须严格按照项目计划进行,在一个月内顺利完成。目标全校师生参与,在校师生提供交流平台和展示自己能力和魅力的机会和舞台,此外要引起社会关注,产生对学校未来发展、就业、招生等工作提供积极影响。 校园一角项目要求筛选足够质量和数量的作品。场地布置以简洁明快为主,将作品突出化,艺术化。也需要足够人手负责安全,投票工作。以作品200以上,成本1500以下为标准。 歌唱校园歌唱比赛要求邀请校外人员作灯光音响等场地布置工作,需要作品最好为原创,以健康向上积极为主要歌曲内容。预选全程监督,严格筛选,正赛邀请校领导及有关老师参加观看。邀请全校各院学生会主席观看。总成本25000左右为标准。 游园活动要求专门布置适宜场地,邀请一定表演团体,提供饮用水、小吃、等,游戏环节以安全健康为标准。总成本不超过4000元为宜。

拔河活动要求各院积极参与,并邀请老师代表队进行友谊赛。做好医疗后勤保障工作。总成本控制在2000元左右。 校庆晚会作为核心项目要求各人员负责各自工作,节目招聘以原为单位,取最好节目作为筛选名单,邀请校外表演团体,明星等为校庆晚会添彩。节目彩排要求保密,安全。场地布置华丽精彩突出喜庆气氛。总成本要求视情况而定。总最好不超过42000元。 二、项目范围管理计划 具体管理安排 1、将游园活动,拔河比赛作为一组管理,最为室外项目,可以考虑天气问题提前或者延后举行,原则上不占用晚会和歌唱比赛时间。 2、将校园一角单独一组管理,作为弹性最大的活动,其管理相对轻松,范围宽松,可视其他项目成本多寡,时间松紧作为调整项目缓冲。 3、将歌唱比赛作为一组,可视作品多寡取消或添加预选赛时间和次数,可以直接为晚会作为筛选。 4、将校庆晚会作为一组,作为核心内容,校庆晚会要做到高质量节目,高精度管理。一切其他项目为校庆晚会服务和提供帮助。 三、项目范围定义 根据各小项目的具体内容和计划,编制下面的各个项目的具体工作分解图

工程项目管理案例分析(汇编)

工程项目管理案例分析 澳大利亚悉尼港海底隧道工程 澳大利亚悉尼港海底隧道工程是典型的BOT项目融资模式,首先理解BOT融资模式的意义:BOT项目融资(即Build—Operate—Transfer建设~经营~移交)是项目融资的诸多方式中的一种,在我国又被称作”特许权投融资方式。一般有东道国政府或地方政府通过特许权协议,将项目授予项目发起人为此专设的项目公司(Project company),由项目公司负责基础设施(或基础产业)项目的投融资、建造、经营和维护;在规定的特许期内,项目公司拥有投资建造设施的所有权(但不是完整意义上的所有权),允许向设施的使用者收取适当的费用,并以此回收项目投融资、建造、经营和维护的成本费用,偿还贷款;特许期满后,项目公司将设施无偿移交给东道国政府。 悉尼港海底隧道工程的项目背景 针对悉尼港湾大桥车流量逐年增多并己超过大桥设计能力的现状,澳大利亚新南维尔州政府在1979年就向社会公开发出邀请,就解决悉尼港湾的交通问题请私人企业提出建议,最初提出的建议(主要是修建悉尼港湾第二大桥)由于种种原因均未被政府所接受。1986年,澳大利亚最大的私人建设公司Gransfield和日本的大型建设公司之一Kumagai Gumi Co Ltd(熊谷组)联合向州政府提出了建设海底隧道作为悉尼港湾第二通道的建议。州政府在经全面研究后,认为这个建议是可以接受的,于是摇权这两个公司用自有资金对该项目的筹

资方式,建设和经营隧道进行全面的可行性研究。主要包括:技术可行性研究,环境影响研究,资金筹措方案。其中就资金筹措方面聘请了澳大利亚WESTPAL银行为财务咨询单位,对筹资方式进行了咨询并提出了初步方案。 该项目的可行性研究报告历时18个月投入400万澳元并在1987年被州政府批准,这两家私人公司为保证该项目的实施正式成立悉尼港隧道有限公司与州政府签订了特许权合同。该项目在经济上是可行的,最终要达到以下目标:政府的财政预算内不承担提供资金的义务,隧道收费要保持在最低水平上,政府承受的风险限制在最低限度上,政府能影响项目的设计、建设和经营,以保证项目的财政能力;长期性的解决悉尼港大桥的的交通问题,政府仅承担项目实际收入与设计收入之间的差额风险,保证项目有足够的收入归还贷款。 资金筹措方面 该项目总投资7.56亿澳元。最后确认的资金安排方案是:政府无息贷款2.23亿澳元(占29%);这部分资金来源于隧道建设期间悉尼大桥的纯收入,澳大利亚最大的私人建筑公司GRANSFIELD与日本的大型建设公司熊谷组的共同项目贷款为4000万澳币元(各2000万,共占5%)和共同项目资本金分700万澳币元(各350万,共占1%)、;西太平洋银行和德意志银行认购债券2.66亿澳元(占35%);Cheunug Kong Infrastructure 出资1.1亿(占15%);DB Capital Partners 出资6600万(占9%);Bilfinger Beeger 出资4400万

IT 项目管理经典案例

1、拯救项目团队 徐家龙最近被公司任命为项目经理,负责一个重要但不紧急的项目实施。公司项目管理部为其配备了七位项目成员,这些项目成员来自不同部门,大家都不太熟悉。徐家龙召集大家开启动会议时,说了很多谦虚的话,也请大家一起为做好项目出主意。一起来承担责任,会议开得比较沉闷。 项目开始以后,项目成员一有问题就去找项目经理,请徐经理给出意见,徐经理为了树立自己的权威、表现自己的能力,总是身体力行;其实,有些问题项目成员之间就可以互相帮助,但是他们怕自己的弱点被别人发现,作为以后攻击的借口,所以他们一有问题就找项目经理,其实徐经理的做法也不全对,成员发现了也不吭声,因为他们认为我是按你说得作的,有问题你经理负责。 团队成员之间一团和气,“找徐经理去!我们听你的;成为了该项目团队的口头禅,但是随着时间的推移,这个貌似祥和团结的团队,在进度上很快就出了问题。该项目由重要但不紧急的项目变成了重要还紧急的项目! 项目管理部意识到问题的严重性,派高级项目经理张一峰指导该项目的实施。 1.1问题 问题出在哪儿? 张一峰怎么做?

2、C公司的变更管理 C 公司是一家主要为交通部门从事系统集成业务的公司。 2007 年 3 月底该公司承接了 L 市数字指挥系统的建设工作,公司任命王莽为项目经理。合同金额 300 万交付日期为 7 月 1 日。 王莽组建完团队后,召开了内部的项目启动会议,宣布 4 月 1 日正式开工;大家干劲很高;王莽带领项目团队绘制了项目的生命期模板,分解得到了项目的 WBS ,在此基础上得到了项目计划,然后团队严格按照项目计划执行。a 很遗憾的是:很快项目团队就发现所需的采购设备的项目资金,被公司挪作它用不能及时供给资金。另外这时交付给客户X 模块,虽然用户签收了,但是客户认为项目团队没有领会好他们最急需的需求,希望他们在 4 月底前尽快完成 Y 模块的工作。而项目团队的计划是在 5 月底完成 Y 模块,王莽认为这是客户的变更,需要填写客户变更申请书,客户不承认这是变更,于是引起争执也未填写变更申请书。b 项目团队努力按照计划继续执行,但发现计划越来越难执行;交通部门的意见越来越多,王莽底下的成员看见项目经理已经与客户闹矛盾了,为了缓和关系底下的几个成员;开始不情愿地接受客户的意见,认为能随手改的就改了。公司认为这样作是对的,有助于提高客户满意度,这样到 5 月初时项目计划已经形同虚设。c 随着项目的进行,王莽和项目成员变成了救火队,用交通部们的话说是很好指哪打哪;但是王莽和项目成员发现:自己已经疲于奔命,客户的需求追加了不少,随意的变动也很多。甚至交通部门有的用户上旬说这么改,中旬说那么改,到了下旬说还是上旬作的对,改回去吧!王莽认为这样做下去,自己累死不算,利润率肯定为负数,结局是不讨好的。于是王莽和几个骨干在 5 月底,宁愿不要当月薪水,先后辞职离开了公司。 2.1问题 怎么回事?王莽、管理者各有哪些错误?分步骤的应对措施是什么? A、启动阶段 B、矛盾初起(争执未起) C、计划形同虚设。

软件项目管理案例分析题

软件工程管理案例分析 案例分析一 问题1: 本工程申请国家技术创新基金100万元,但国家实际批准基金额度很可能会低于100万元,“工程投资来源”中应当说明:当国家实际批准基金低于申请额度时,如何补足二者之间的差额以及由此所引起的地方匹配基金的差额。 应重新召开股东大会并讨论以下议题:当国家实际批准基金低于申请额度时,公司是否愿意补足二者之间的差额以及由此引起的地方匹配基金的差额。 如果能够通过,应在“工程投资来源”中加注:当国家实际批准基金低于申请额度时,公司承诺补足二者之间的差额以及由此引起的地方匹配基金的差额(附新的公司股东大会决议)。 问题2: A,B双方以B方现有技术成果为基础进一步合作开发,应明确以下几个主要问题: (1)B方是以现有技术成果折价入股,还是将现有技术成果转让给A方; (2)如果是“技术转让”,应明确是“专利权转让”、“专利实施许可”、还是“技术秘密转让”? (3)双方是否已就合作开发的新技术成果的所有权、使用权以及利益分成问题达成一致意见? 双方是否已正式签订“合作开发合同”或“技术转让合同”? 问题3: 应主要从以下几方面分析工程技术的成熟性: (1)关键技术成熟性分析(包括采用的现有成熟关键技术、已攻克的关键技术、待研究的关键技术等); (2)工程采用的关键技术是否获得国家、部门或地方科技计划的支持(已获得、尚未获得)及计划的名称、获得支持的时间; (3)工程采用的关键技术是否通过技术鉴定(已鉴定、尚未鉴定)及鉴定单位、鉴定意见、鉴定时间。 案例分析二 问题1: 由工程执行偏差导致工程计划变更的各种诱发因素称为工程变更的内部因素。由工程目标变化导致工程计划变更的各种诱发因素称为工程变更的外部因素。 问题2: “B方首付资金未能按时交付”、“A方盲目确定进度目标”、“A方的前期设计有疏漏”、“A方编制的需求分析说明书未能准确、全面地表达B方的实际需求”、“B方自行负责的机房装修误期”、“A方开发人员跳槽”,属于工程变更的内部因素。 “证监会要求上市公司执行新的会计制度”、“B方因机构重组改变了业务流程”、“B方提出增加合同审计功能”、“B方行业主管部门发布了新的行业ERP实施规范”,属于变更的外部因素。 问题3: “A方盲目确定进度目标”、“A方的前期设计有疏漏”、“A方开发人员跳槽”,属于A方责任。由此而增加的工程经费,由A方承担。“需求分析时,B方表达不清,A 方理解有误,双方沟通不够,A方编制的需求分析说明了书未能准确、全面地表达B方的

项目范围管理案例

项目围管理 一、项目围说明书 该项目具体分为5个小部分:1、歌唱校园比赛2、校庆游园活动3、校园一角图片书法展4、校庆拔河比赛5、校庆文艺晚会。宣传活动将会统一进行。总成本要控制在75000元。虽然校园一角图片书法展是首先开始展览,但是以歌唱校园的决赛为一系列校庆活动的开幕式,以校庆文艺晚会为圆满结束。各小项目必须格按照项目计划进行,在一个月顺利完成。目标全校师生参与,在校师生提供交流平台和展示自己能力和魅力的机会和舞台,此外要引起社会关注,产生对学校未来发展、就业、招生等工作提供积极影响。 校园一角项目要求筛选足够质量和数量的作品。场地布置以简洁明快为主,将作品突出化,艺术化。也需要足够人手负责安全,投票工作。以作品200以上,成本1500以下为标准。 歌唱校园歌唱比赛要求邀请校外人员作灯光音响等场地布置工作,需要作品最好为原创,以健康向上积极为主要歌曲容。预选全程监督,格筛选,正赛邀请校领导及有关老师参加观看。邀请全校各院学生会主席观看。总成本25000左右为标准。 游园活动要求专门布置适宜场地,邀请一定表演团体,提供饮用水、小吃、等,游戏环节以安全健康为标准。总成本不超过4000元为宜。

拔河活动要求各院积极参与,并邀请老师代表队进行友谊赛。做好医疗后勤保障工作。总成本控制在2000元左右。 校庆晚会作为核心项目要求各人员负责各自工作,节目招聘以原为单位,取最好节目作为筛选,邀请校外表演团体,明星等为校庆晚会添彩。节目彩排要求保密,安全。场地布置华丽精彩突出喜庆气氛。总成本要求视情况而定。总最好不超过42000元。 二、项目围管理计划 具体管理安排 1、将游园活动,拔河比赛作为一组管理,最为室外项目,可以考虑天气问题提前或者延后举行,原则上不占用晚会和歌唱比赛时间。 2、将校园一角单独一组管理,作为弹性最大的活动,其管理相对轻松,围宽松,可视其他项目成本多寡,时间松紧作为调整项目缓冲。 3、将歌唱比赛作为一组,可视作品多寡取消或添加预选赛时间和次数,可以直接为晚会作为筛选。 4、将校庆晚会作为一组,作为核心容,校庆晚会要做到高质量节目,高精度管理。一切其他项目为校庆晚会服务和提供帮助。 三、项目围定义 根据各小项目的具体容和计划,编制下面的各个项目的具体工作分解图

工程项目管理经典案例分析

背景: 某钢厂改造其烧结车间,由于工期紧,刚确定施工单位的第二天,施工单位还未来得及任命项目经理和组建项目经理部,业主就要求施工单位提供项目管理规划,施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计,其内容深度满足管理规划要求,但业主不接受,一定还要求施工单位提供项目管理规划。 问题: ①项目经理未任命和项目经理部还未建立,就正式发表了施工组织设计,其程序是否正确? ②业主一定要求施工单位提供项目管理规划,其要求是否一定正确? ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及内涵。 ④试说明施工项目管理规划的控制原则。 答:①程序不正确,公司还未任命项目经理,项目经理部还未建立,施工组织设计无人审核和批准,不能发表。 ②施工组织设计可以代替施工项目管理规划,但施工组织设计的内容深度应能满足施工项目管理规划的要求;冶金建设工程中,实际上一直使用施工组织设计代替项目管理规划;施工单位可以向业主说明提供的施工组织设计的内容深度已达到项目管理规划的深度要求,不必再编制项目管理规划。 ③施工项目管理规划的规划目标及内涵有: a.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他内容等; b.内涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为:实现最优化控制;动态控制;主动控制;全过程控制;全要素控制;建立大控制系统的观念;要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进,进一步进行总结。 2、背景: 华北某厂1260m3级高炉扩容改造工程。根据招标文件要求,为了实现快速、高效、优质、低耗地完成扩容改建任务,该扩容改造,应采用高炉整体平移新技术。高炉分两段安装:第一段为移送;第二段为悬吊,高炉本体工程拟定在拼装平台上基本完成,尽量缩短停炉后施工工期,保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合,标高与原设计标高相符,误差控制在5~8m”。高炉本体移送重量约4500t。推移高度约为36m,推移距离约42m。高炉本体在液压缸推动下,分步向炉基平移。

企业如何进行项目管理——最经典项目管理案例纪实

企业如何进行项目管理——最经典项目管理案例纪实 引言: 随着企业的发展壮大,项目遍及全国各地。由于项目越来越多,在项目管理中的问题也开始逐步显现,各地项目延期现象严重,进度不能有效保证,总是不能按时完成工程任务,而追究其原因时,客观理由总是很多,让管理人员很头疼。那么在项目管理上企业该如何分配资源和规划调整,在整个过程中又会出现什么问题,这些都是企业管理人员应该注意和解决的问题。人力资源专家——华恒智信在项目管理方面有着多年的关注与研究,本文是华恒智信为某企业实施的项目管理的案例纪实。 客户评价 项目管理,一直是我们企业所重点关注的问题。如何规避项目管理过程中的各种问题,将项目管理的计划、进度、过程监督有效把控好,也 是我们所头疼的。华恒智信所提出的解决思路为我们指明了方向,使得项 目效率提高、成本降低,非常具有实践指导意义。 ——某建筑公司总经理 【客户行业】建筑行业 【问题类型】项目管理 【客户背景及现状问题】 某建筑集团有限公司成立于1898年,拥有国家房屋建筑工程施工总承包一级、建筑装修装饰工程专业承包一级、市政公用工程施工总承包一级资质。是一家集建筑施工、设备安装、装饰装潢、仿古建筑、房地产开发、建材试验为一体的具有综合生产能力的建筑企业。 随着企业的发展壮大,项目遍及全国各地。由于项目越来越多,在项目管理中的问题也开始逐步显现,各地项目延期现象严重,进度不能有效保证,总是不能按时完成工程任务,而追究其原因时,有的说是项目计划不合理,有的说是外单位配合不力导致,有的说是人员不到位……总之客观理由总是很多,让总经理很头疼,对于未完成项目的人员,处罚不合适、不处罚也不合理。同时,项目质量也并不能完全让人省心,有时候会出现漏水现象,有时候出现裂缝现象……总是由于一些质量问题而不断地进行返工,

(项目管理)项目范围管理

项目范围管理 【本章知识重点】 ★项目范围和产品范围:(两者之间的定义与区别); ★产品描述 ★项目选择方法 ★项目章程:(它的作用、内容、指派项目经理的时机和批准人) ★范围说明、范围管理计划 ★WBS:(PMP考试的重点之一,需要理解它的各种用途) ★账目编码Code of accounts / 会计科目表Chart of accounts(两者间的定义与区别) ★工作包/ WBS字典 ★WBS与其他分解结构的区别 ★范围核实/ 质量控制:(两者之间的定义与区别) ★范围变更的原因 【电子笔记】 项目范围管理:确保项目包括成功完成项目所需的全部工作,但又只包括成功完成项目所必需的工作过程。它主要关心的是确定与控制哪些应该与哪些不应该包括在项目之内。 上述定义表明了PMI的政策,PMI提倡:“不做额外的工作(no extra),不要镀金(no gold-plating)”。 5.1 启动:批准项目或阶段的开始。 5.2 范围规划:制订书面范围说明,作为今后项目决策的基础。 5.3 范围定义:将主要的项目可交付成果划分为较小,更易管理的组成部分。 5.4 范围核实:正式认可项目的范围。 5.5 范围变更控制:控制项目范围的变更。 就项目而言,范围(Scope):“项目所提供的产品或服务的总和”。这个术语可指: ?产品范围(Product Scope):产品或服务的典型特征与功能。 ?项目范围(Project Scope):为提供具有典型特征与功能的产品或服务所需完 成的工作。 项目所产生的通常是单项产品,单该项产品却可包括若干个从属部分,每个部分都具备其单独,却又相互依存的产品范围。例如一个新电话系统通常包括四个从属部门:硬件、软件、培训和实施。 项目范围是否完成以项目计划作为衡量标准;产品范围是否完成以产品要求作为衡量标准。

项目范围管理案例25268

第2章项目范围管理案例 项目的范围管理影响到信息系统项目的成功。在实践中,需求蔓延”是信息系统失败最常见的 原因之一,信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能,无论是客户 的要求还是项目实现人员对新技术的试验,都可能导致信息系统项目范围的失控,从而使得信息系 统项目无论在时间、资源和质量上都受到严重影响。 2.1 案例一:范围定义 阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述,回答问题1至问题3。案例场景 希赛信息技术有限公司(CSAI 原本是一家专注于企业信息化的公司,在电子政务如火如荼的时候,开始进军电子政务行业。在电子政务的市场中,接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求,该系统涉及到两个互不联通的子网:政务内网和政务外网。政务内网中储存着全部信息,其中包括部分机密信息;政务外网可以对公众开放,开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须是一致可靠,政务内网的信息可以发布到政务外网,政务外网的信息在经过审批后可以进入政务内网系统。 张工是该项目的项目经理,在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同,有其自身的特殊性,若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型,并专门招聘了熟悉网络互通互联的技术人员设计了解决方案,在经过严格评审后实施。在项目交付时,虽然系统完全满足了保密性的要求,但用户对系统用户界面提出了较大的异议,认为不符合政务信息系统的风格,操作也不够便捷,要求彻底更换。由于最初设计的缺陷,系统表现层和逻辑层紧密耦合,导致70%的代码重写,而第二版的用户界面仍不能满足最终用户的要求,最终又重写的部分代码才通过验收。由于系统的反复变更,项目组成员产生了强烈的挫折感,士气低落,项目工期也超出原计划的100%。 【问题1】请不超过300 字,对张工的行为进行点评 【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题不超过200字回答。 【问题3】请结合你本人实际项目经验,指出应如何避免类似问题不超过200字回答。案例分析 这是一个失败的项目,张工在项目管理中既有闪光点,也有失败的地方。但项目管理中的任何差错都会影响项目的结果,而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。 张工对项目范围有一定的把握。在范围定义中,张工发现了不同行业间具有不同的特点,电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求,政务内网与政务外网是该行业一致的标准,这与企业信息化是完全不同的。张工捕获到该需求,并对这个

相关主题
文本预览
相关文档 最新文档