项目综合案例分析.ppt

* * * * * * * * * * * * 案例三：范围确认 案例点评 这是一个失败的项目，和很多失败的软件项目一样，王强在项目范围（或软件需求）方面栽了跟头； 项目经理王强即重视需求，又没有控制好需求的案例 开发和定义软件系统的需求是整个项目过程的关键 管理项目范围是常识，但往往因为一时的疏忽而造成需求的重大缺陷 项目实施过程经历了波折，但未引起重视，最终失败！ 项目开局：充满光明 项目中期：出现乌云 项目交付：下雨了 案例三：范围确认 案例分析 王强在项目管理中成功的方面 找到合适的资源进行需求的定义 可以快速准确地把握新系统的需求 王强在范围确认和范围控制方面存在失误 认为紧逼客户确认需求不近人情，抱着侥幸心里进入开发阶段 未履行需求评审和确认过程，造成缺陷未及时发现 需求控制失去基准，导致重大变更 案例三：范围确认 案例分析 从项目管理的角度分析，项目范围直接决定了工作量和工作目标，项目范围管理中的关系 范围定义：管理的基础 范围确认：基线化已定义的范围 范围控制：减少变更，保持范围的稳定 项目范围确认的方法 客户代表确认需求说明书（需求报告） 召集客户的业务骨干对需求进行评审 详细记录原始的调研材料，让客户确认调研报告 迭代开发逐步确认需求 案例三：范围确认 案例分析 总结语 项目的闪光点在于认识到需求的重要性，资源合理 未履行范围评审和确认导致了项目的重大变更 范围控制成为无本之木，控制过程成为讨价还价，失去本身的意义，导致项目的失败！ 案例三：范围确认 问题解答 问题1：对王强在项目管理工作中的行为进行点评。 王强为了更明确地把握系统需求，聘请了原系统需求调研人员李伟，提高了需求定义的效率和质量； 王强没有对李伟提供的系统需求进行评审核复查，从而使需求的缺陷没有被及时发现； 王强没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差； 王强对需求缺乏有效控制，最终导致项目延期50% 案例三：范围确认 问题解答 问题2：从项目范围管理的角度找出项目实施过程中的管理问题？ 项目实施过程中的主要问题包括： 在范围定义过程中，王强没有对李伟定义的需求进行评审，造成需求中的质量缺陷没有被及时发现； 在范围确认过程中，王强没有主动要求用户对需求进行确认； 在范围控制过程中，王强无法进行有效的范围控制，最终造成了重大的需求变更。 案例三：范围确认 问题解答 问题3：从范围管理的角度出发，如何避免类似问题的发生？ 本案例说明项目范围管理中应采取以下规避措施： 项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求定义中存在的缺陷； 对已经定义的需求要及时与用户进行确认，保证双方理解的一致； 在发生需求变更时，应采取灵活手段，在满足用户需求的前提下，尽量减少需求变更得范围。 * * * * * * * * * * * * * * * * * * * * * * * * * 项目管理综合案例分析 －项目范围管理 岐兵 qib@ 案例一：范围定义 岐兵 qib@ 案例一：范围定义 项目背景 黎明信息技术有限公司原本是一家专著于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业。在电子政务的市场中，承接的第一个项目是开发一套工商审批系统。 由于电子政务保密要求（国家要求），该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包含部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。 系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。 案例一：范围定义 案例场景 丁伟是该项目的项目经理，在捕获到这个需求后认为电子政务项目建设和企业MIS项目有很大不同，有其特殊性，若照搬企业信息化项目原有的经验和方法必定失败。 丁伟在该项目中采用了严格的瀑布模型，并专门招聘了熟悉网络互联互通的技术人员参与设计了解决方案，在经过严格评审后开始实施项目。 在项目交付时，虽然系统完全满足了项目保密性要求，但用户对系统用户界面提出了较大异议，认为不符合政务信息系统的要求和风格，操作也不够便捷，要求彻底更换。 案例一：范围定义 案例场景 由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面仍然没有达到用户的要求，最终又重写了部分代码才勉强通过用户验收。由于整个项目反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也必原先的计划超出一倍，项目成本超出预算的100%，项目用户满意度较低。 该项目最终的结果与公司的期望偏差很大，黎明公司决定暂时放弃进军电子政务市场，并要求相应的事业部进行业务转型，