可打印系统集成项目管理工程师案例分析.doc

第4章 项目管理一般知识
4.1 项目经理选择
阅读下列说明，回答问题1至问题3，将解答填入答题纸对应栏内。
【说明】
D公司是一家系统集成商，章某是D公司一名高级项目经理，现正在负责某市开发区办公网络项目管理工作，该项目划分为综合布线、网络工程和软件开发三个子项目，需要3个项目经理分别负责。章某很快找到了负责综合布线、网络工程项目经理，而负责软件开发项目经理一直没有合适人选。原来由于D公司近年业务快速发展，承揽项目逐年增多，现有项目经理人手不够。章某建议从在公司工作2年以上业务骨干中选拔项目经理。结果李某被章某选中负责该项目软件开发子项目。在项目初期，依照公司管理规定，李某带领几名项目团队成员刻苦工作，项目进展顺利。 随着项目进一步展开，项目成员逐步增加，李某在项目团队管理方面遇到很多困难。他领导团队因经常返工而效率低下、团队成员对发生错误互相推诿、开会时人员从来没有到齐过，甚至李某因忙于自己负责模块开会时都迟到过。大家向李某汇报项目实际进度、成本时往言过其实，直到李某对自己负责模块进行接口调试时才发现这些问题。
【问题1】（5分） 请分析项目中出现这些情况可能原因（100字以内）。
【问题2】（5分） 你认为高级项目经理章某应该如何指导和帮助李某（200字以内）。
【问题3】（5分） 请说明李某作为项目经理要承担哪些角色？要成为一名合格项目经理要具备哪些知识及技能？（200字以内）
[问题1]（10分） 请分析项目中出现这些情况可能原因（200字以内）。
答：（1）李某缺乏担任项目经理所需足够能力和经验
（2）公司对项目经理培养不重视，对项目经理选拔任命不规范；
（3）章某对李某“传帮带”做不够好；
（4）公司对项目经理工作缺乏指导和监督；
（5）项目工作中沟通没有建立有效机制和方式方法；
（6）缺乏有效项目绩效管理机制；
[问题2]（10分） 你认为高级项目经理章某应该如何指导和帮助李某（300字以内）。
答：（1）章某应明确李某工作职责，帮助其实现向项目经理角色转变；
（2）参加小李组织周例会，以及时发现问题，予以指导；
（3）对李某提供相关工作指导或培训，尤其是在项目管理方面；
（4）从整体项目层面对各子项目进行协调和计划，对子项目提出具体工作要求；
（5）加强对子项目日常监督，要项目经理以身作则；
（6）针对子项目中出现问题，及时提出纠正和预防措施；
[问题3]（5分） 请说明李某作为项目经理要承担哪些角色？要成为一名合格项目经理要具备哪些知识及技能？（300字以内）
答：参加书上147－148页内容
承担角色：项目管理者，项目领导者，项目接口人等角色
4.2 项目组织结构
阅读下面叙述，回答问题1至问题3，将解答填入答题纸对应栏内。
【说明】
某系统集成商B最近正在争取某钢铁公司A办公网络迁移到外地项目。李某是系统集成商B负责捕捉项目机会销售经理，鲍某是系统集成商B负责实施项目经理。由于以往项目销售经理过度承诺给后继实施工作带来了很大困难，此次鲍某主动为该项目做售前支持。该办公网络迁移项目工作包括钢铁公司A新办公楼综合布线、局域网络系统升级、机房建设、远程视频会议系统、生产现场闭路监控系统等5个子系统。钢铁公司A对该项目招标工作在2006年8月4日开始。该项目要求在2006 年12月29日完成，否则将严重影响钢铁公司A业务。 时间已到2006年8月8日，钢铁公司A希望系统集成商B能在8月15日前能够提交项目建议书。钢铁公司A对项目进度非常关注，这是他们选择集成商重要指标之一。根据经验、钢铁公司A实际情况和现有资源，鲍某组织制定了一个初步项目计划，通过对该计划中项目进度分析预测，鲍某认为按正常流程很难达到客户对进度要求。拟订合同中将规定对进度延误要处以罚款。但是销售经理李某则急于赢得合同，希望能在项目建议书中对客户做出明确进度保证，首先赢得合同再说。鲍某和李某在对项目进度承诺问题上产生了分歧，李某认为鲍某不帮助销售拿合同，鲍某认为李某乱承诺对以后项目实施不负责任。本着支持销售原则，鲍某采取了多种措施， 组织制订了一个切实可行进度计划，虽然其报价比竞争对手略高，但评标委员会认为该方案有保证，是可行，于是系统集成商B中标。系统集成商B中标后，由其实施部负责项目实施。
【问题1】（7分） 在制订进度计划时，鲍某可能会采取哪些措施使制订进度计划满足客户要求？
【问题2】（5分）实施项目系统集成商B目前组织类型是什么？如何改进其项目
组织方式？如何改进其项目管理流程？如何降低管理外地项目成本？
【问题3】（3分） 在项目实施过程中，负责售前工作李某应继续承担哪些工作？
【问题 1】
1） 沟通，强调该项目对系统集成商B重要意义，提高项目优先级。使用开会方式争取相关部门建议、支持和承诺。
2） 从现有资源和实际情况出发，优化网络图，如重新安排活动之间顺序，压缩关键路径长度。
3） 增加资源，引入经验丰富员工
4） 并行，在现有资源下，子任务并行，内部流程优化。
5） 赶工，项目员工通过加班来加快项目进度
6） 尽可能地调配非关键路径上资源用于关键路径上任务
7） 优化外包，采购等环境并全程监控
【问题 2】
（1） 系统集成商B组织方式是职能式。
（2） 系统集成商B组织方式应该改为矩阵型。
（3） 最好办法是项目下阶段人员提前介入到前一阶段，如在项目售前阶段，负责项目实施项目经理正式参及售前工作。
（4） 另外，做好项目实施流程间交接工作，如建立一套完整项目售前和项目实施阶段之间交接规范和要求－包括文档、培训、合同等内容。
（5） 委托、分包给当地有资质集成商，或在当地招人。如果材料和服务在当地采购可降低成本。压低人员差旅费，事宜虚拟远程沟通和售后服务手段。

【问题 3】
（1） 及客户高层沟通，了解客户对项目实施情况反映，维护客户关系，发掘新项目机会。
（2） 参加周例会，或至少每周首一次周报以了解项目进展和问题。
（3） 参及可能发生变更前期评审工作。
（4）负责或者协助收款。
4.3 项目组织结构
阅读下面叙述，回答问题1至问题3，将解答填入答题纸对应栏内。
【说明】
《系统集成项目管理工程师》教程 第23章-案例分析 23.1.7

答题思路：
1、强矩阵型组织结构特点是：它具有很多项目型组织特征，具有拥有很大职权专职项目经理和专职项目行政管理人员。　　
2、 在强矩阵组织中，为协调项目经理和职能部门经理权责，应：
2.1 在公司管理思想和原则上，明确矩阵型组织特征：
★ 能够以项目为导向
　 　★ 有了客户问题处理中心
　 　★ 协调工作由项目管理队伍承担
　　 ★ 能够明确责任
　 　★ 资源来自各职能部门，并且这些资源可在不同项目中共享
　 　★ 专业人员在技术上可相互支持
★ 各专业员工组织上仍归属其职能部门，因此项目结束后，员工“有家可归”
2.2 在公司制度上，明确职能部门和项目经理之间权责分配关系：
－－资源、人员日常归职能部门经理管理和考核；
－－在项目实施期间人员、资源由项目经理全权管理和考核；
2.3 建立一个清晰项目管理流程，明确项目经理在项目实施期间权力和责任；定义了相关人员和相关部门在项目活动中工作范围、工作过程和职责。这个流程一般由项目管理部门起草，经过相关部门讨论修改，最终由项目管理部门、相关职能部门审批，最后由公司管理层终批生效。例如：
－－严格加强项目章程规范性和严肃性，任命项目经理必要性
－－项目所需资源，由项目经理提出申请，职能经理负责委派人员；
－－项目实施期间考核由项目经理负责，项目结束后，人员回到职能部门，考核
内容也转交给职能经理，最终由职能经理负责全部考核
－－项目管理部经理和资源部门经理对等处理项目过程中项目目标和资源提供决策问题；

2.4 在项目工作安排方面，特别注意管理好各个接口，如项目成员之间或部门之间工作交接，技术交接、资源交接

2.5 加强项目沟通，适量增加项目信息收集、整理、分析和发布频次，这样能及时发现项目问题，利于及时采取纠正措施。可以通过电子邮件等手段，及时将项目进展情况、存在问题和纠正措施通报给全体项目成员、不要忘记抄送给项目成员所属部门经理，如果有必要，甚至抄送给公司管理层。
4.4 项目生命周期模型 2009上
阅读下列说明，回答问题1至问题3。将解答填入答题纸对应栏内。
【说明】
小赵是一位优秀软件设计师，负责过多项系统集成项目应用开发，现在公司因人手紧张，让他作为项目经理独自管理一个类似项目，他使用瀑布模型来管理该项目全生命周期，如下所示：

项目进行到实施阶段，小赵发现在系统定义阶段所制订项目计划估计不准，实施阶段有许多原先没有估计到任务现在都冒了出来。项目工期因而一再延期，成本也一直超出。
   【问题1】（6分）
    根据项目存在问题，请简要分析小赵在项目整体管理方面可能存在问题。
   【问题2】（6 分）
    （1）请简要叙述瀑布模型优缺点。
    （2）请简要叙述其他模型如何弥补瀑布模型不足。
   【问题3】（3分）
    针对本案例，请简要说明项目进入实施阶段时，项目经理小赵应该完成项目文档工作？

【问题 1】
1、 软件设计师小赵第一次担任项目经理，独立管理一个项目，缺乏项目整体管理经验和技能；
2、 小赵选取瀑布模型作为项目整体管理生命周期模式，缺乏科学论证和系统评估，开发模型选取没有进行可行性分析和论证；
3、 在系统论证阶段制定项目整体计划时，对进度计划没有采用科学方法，如类比估算法，专家判断，三点估算，应急时间等。
4、 对项目需求和功能没有进行严格需求分析、范围定义；
5、 在项目范围上没有制定WBS，规划项目实施范围；
6、 小赵没有对项目范围进行严格范围确认；导致项目范围界定不清
7、 实施阶段，没有对项目范围进行范围控制，遵循规范范围变更控制管理，导致范围蔓延
【问题 2】 书上162页
1、 瀑布模式优点是
2、 为弥补瀑布模型缺点，可采用快速原型法、螺旋模型和迭代模型
【问题 3】
小赵在项目实施阶段应完成文档，分两大类：
(1) 项目管理过程文档—项目进度计划（变更），项目绩效报告，项目会议记录，项目范围（变更）说明书、变更控制文档、质量分析报告，风险评估报告等等。
(2) 项目产品实现文档—概要设计说明书，详细设计说明书，代码规范，程序编码设计书，数据库模型及设计说明书，测试用例，测试报告等等。
第5章 立项管理
5.1 项目可行性分析—分析报告
阅读下列有关项目可行性分析说明，回答问题1至问题3。将解答填入答题纸对应栏内。

参考答案：

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
第6章 项目整体管理
6.1 项目整体（综合）管理
阅读下列说明，回答问题1至问题3。将解答填入答题纸对应栏内。
【说明】
A公司是一家中小型系统集成公司，在2006年3月份正在准备对京发证券公司数据大集中项目进行投标，A公司副总裁张某授权销售部林某为本次投标负责人，来组织和管理整个投标过程。 林某接到任务后，召集了由公司商务部、销售部、客服部和质管部等相关部门参加启动说明会，并把各自分工和进度计划进行了部署。
随后，在投标前3天进行投标文件评审时，发现技术方案中所配置设备在以前项目使用中是存在问题，必须更换，随后修改了技术方案。最后A公司中标并和客户签订了合同。
根据公司项目管理流程，林某把项目移交到了实施部门，由他们具体负责项目执行及验收。 实施部门接手项目后，鲍某被任命为实施项目经理，负责项目实施和验收工作。鲍某发现由于项目前期自己没有介入，许多项目前期事情都不是很清楚，而导致后续跟进速度较慢，影响项目进度。同时鲍某还发现设计方案中尚存在一些问题，主要有：方案遗漏一项基本需求，有多项无效需求，没有书面需求调研报告；在项目工期、系统功能和售后服务等方面，存在过度承诺现象。于是项目组重新调研用户需求，编制设计方案，这就增加了实施难度和成本。可是后来又发现采购部仍是按照最初方案采购设备，导致设备中模块配置功能不符合要求情况。 而在A集成公司中，类似现象已多次发生。

【问题1】（5分） 针对说明中所描述现象，分析A公司在项目管理方面存在问题（150字以内）。
【问题2】（5分） 针对A公司在该项目管理方面存在问题，提出补救措施（150字以内）。
【问题3】（5分）针对A公司项目管理现状，结合你实际经验，就A公司项目管理工作持续改进提出意见和建议（150字以内）。

答题思路：
【问题 1】
1、投标前项目启动会议上，没有邀请技术和实施部门
2、没有把以往经验教训，归纳和积累，形成组织知识资产
3、没有建立完善内部评审机制，或虽有评审机制但为有效执行
4、项目中没有实现有效变更管理
5、公司级项目管理体系不健全，或执行不好

【问题 2】
1、改进项目组织形式，明确项目团队和职能部门之间协作关系和工作程序
2、做好项目当前经验教训收集、归纳工作
3、明确项目工作交付物，建立和实施项目质量评审机制
4、建立项目变更管理机制，识别变更中利益相关方并加强沟通
5、加强对项目团队成员和相关人员项目管理培训

【问题 3】
1、建立企业级项目管理体系和工作规范
2、加强对项目工作记录管理
3、加强项目质量和相应评审制度
4、加强项目经验教训收集、归纳、积累和分享工作
5、引入合适项目管理工具平台，提升项目管理工作效率
6.2 项目整体 2009上
阅读下面叙述，回答问题1至问题3，将解答填入答题纸对应栏内。
【说明】
某公司是一家专门从事ERP系统研发和实施IT企业，目前该公司正在进行一个项目是为某大型生产单位（甲方）研发ERP系统。
某公司同甲方关系比较密切，但也正因为如此，合同签较为简单，项目执行较为随意。同时甲方组织架构较为复杂，项目需求来源多样而且经常发生变化，项目范围和进度经常要进行临时调整。
经过项目组艰苦努力，系统总算能够进入试运行阶段，但是由于各种因素，甲方并不太愿意进行正式验收，至今项目也未能结项。
【问题 1】（6分）
请从项目管理角度，简要分析该项目“未能结项”可能原因。
【问题 2】（5分）
针对该项目现状，请简要说明为了促使该项目进行验收，可采取哪些措施。
【问题 3】（4分）
为了避免以后出现类似情况，请简要叙述公司应采取哪些有效管理手段。

答：【问题 1】
1、 签订合同很简单，没有在合同中明确甲乙双方职责，明确项目时间要求，范围界定以及合同违约等条款和内容，缺乏有效合同管理制度；
2、 项目执行较随意，表明其缺乏规范和严格项目管理制度和方法，规范项目管理流程，没有严格进度控制、成本控制和质量保证、风险分析等管理措施。
3、 针对甲方组织结构复杂，需求多变情况，没有进行事前风险分析和制定风险应对措施，对需求没有进行严格分析、管理措施，对项目范围也没有进行确定，
4、 针对项目范围、进度、成本变化，缺乏必要变更控制手段和规范变更控制流程。
5、 对应项目不验收，缺乏有效沟通管理制度，缺少和甲方必须沟通方法和措施，在合同中没有规定验收标准和程序；
6、 对应项目出现情况，缺少应急措施和有效针对性方法，来解决项目当前困难。

【问题 2】
1、 加强和甲方沟通，针对项目验收工作内容和方式，流程、时间等问题，积极和甲方进行沟通，争取和甲方就项目验收工作达成一致意见；
2、 针对合同中没有明确验收标准和流程等问题，可以采用备忘录或者补充协议形式，就项目验收标准、流程、时间和责任人等内容签署书面具有法律效力文件，以便指导项目验收工作。
3、 在项目组内部，加强项目管理工作力度，制定验收文档标准，积极准备验收工作，完善验收成果文档，明确项目验收工作标准和流程，以及团队成员职责。

【问题 3】
1、 公司应该建立严格和规范合同管理制度，签订合同时必须在合同中明确项目范围、进度以及相关要求，建立完善合同文本；
2、 公司内部应该建立规范和完善项目管理制度，在项目管理上建立合规管理流程、方法和标准规范，推行科学项目管理方法，包括范围管理、时间管理、成本管理、质量管理、人力资源管理方面；
3、 在公司内部加强项目管理思想和方法培训，建立全员、全面、全过程项目管理体系和标准。
4、 在项目立项时，建立科学和严谨项目可行性分析和论证制度，进行风险分析和风险评估，规避项目风险。
第7章 项目范围管理
7.1 范围定义
《系统集成项目管理工程师》教程 第23章-案例分析 23.2.1
M公司原本是一家专注于企业信息化公司，在电子政务如火如荼时候，开始进军电子政务行业，在电子政务市场中，接到第一个项目是开发一套工商审批系统。由于电了政务保密要求，该系统涉及到两个互不联通子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放信息必须御到授权。系统要求在这两个了网中合法用户都可以访问到被授权信息.访问信息必须是一致可靠，政务内网信息可以发布到政务外网，政务外网信息在经过审批后可以进入政务内网系统。
张工是该项目项目经理，在捕获到这个需求后认为电子政务建设及企业信息化有很大不同，有其自身特殊性，若照搬企业信息化原有经验和方案必定会遭到惨败。因此采用了严格爆布模型，并专门招聘了熟悉网络互通互联技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性要求，但用户对系统用户界面提出了较大异议，认为不符合政务信息系统风格，操作也不够便捷，要求彻底更换，由于最初设计缺陷，系统表现层和逻辑层紧密耦合，导致70%代码重写，而第二版用户界面仍不能满足最终用户要求，最终又重写部分代码才通过驶收，由于系统反复变更，项目组成员产生了强烈挫折感，士气低落，项目工期也超出原计划100%。
【问题1】（5分）
请不超过150字，对张工行为进行点评?
【问题2】（5分）
请从项目范围管理角度找出该项目实施过程中主要管理问题？不超150字
【问题3】（5分）
请结合你本人实际项目经验，指出应如何避免类似问题?不超过150字
【问题1】请对张工行为进行点评？
工作优点：1、认识到电子政务建设及企业信息化建设不同，考虑到了项目独特性特征；
2、针对业务需求中对内网、外网互联互通要求，针对性招聘了网络互联互通技术人员；
3、满足了用户保密性要求；
工作缺点：
1、采用“瀑布模式”项目生命周期，没有进行论证，武断；
2、用户需求调研不全面，忽视了系统页面需求；并且，进行第二版修正时，没有针对页面需求修改进行确认。
3、设计方案没有进行验证；表现层内耦合业务逻辑，增加了修改代价；
4、团队管理措施不力，成员产生挫折感；

【问题 2】请从项目范围管理角度找出该项目实施过程中主要管理问题。
1、 没有建立规范项目范围管理流程和制度。
2、 范围定义和需求分析时，工作不细致，忽视了B/S架构下页面需求
3、 需求范围变更中，没有对页面变更进行“确认”，就修改代码

【问题 3】
答题思路和提纲，请将下列答题点细化
1、 针对甲方需求，制定实用项目范围管理计划；
2、 做好范围定义工作（详细列出方法）
3、 做好需求分析工作（方法、过程、工作步骤）
4、 重视范围确认（方法）
5、 严格范围变更（变更流程）
6、 建立完善项目范围管理制度和规范范围管理流程

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

7.2 需求评审
《系统集成项目管理工程师》教程 第23章-案例分析 23.1.5
答：<软件需求定义>
1、软件需求是软件开发最重要一个输入，需求风险也常常是软件开发过程中最大一个风险，降低需求风险一个重要手段就是需求评审，但是需求评审是所有评审活动中最难一个，也是最容易被忽视一个评审。
<上述案例问题小结>
　　2 以上现象可以在很多项目中都可以看到。概括起来，在需求评审中常见问题是：
　　◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚；
　　◇ 没有作好前期准备工作，需求评审效率很低；
　　◇ 需求评审节奏无法控制；
　　◇ 找不到合格评审员，及会评审员无法提出深入问题；
……
<上述案例原因分析>
　　3 问题所在：
l 　评审缺乏有效依据和规范，不能保证评审覆盖率和有效性。
l 　产品经理没有把握好会议主题，评审变成了头脑风暴。
l 　目标性需求没有沟通好，后面需求变成空中楼阁。
l 　缺乏评审可操作依据，遗漏评审内容。
l 　没有作好前期准备工作，导致评审时间长，效率低。
l 　没有选择合适评审人员，无法获得有价值反馈。
l 　参加人员过多，容易陷入细枝末节讨论，会议演变成一场人人自由混战。
　　<针对以上问题，提出一些建议>
4 那么究竟如何做好需求评审呢？
建议一：分层次评审
我们知道用户需求是可以分层次，一般而言可以分成如下层次：
Ø 　目标性需求：定义了整个系统需要达到目标；
Ø 　功能性需求：定义了整个系统必须完成任务；
Ø 　操作性需求：定义了完成每个任务具体人机交互；
　　目标性需求是企业高层管理人员所关注，功能性需求是企业中层管理人员所关注，操作性需求是企业具体操作人员所关注。对不同层次需求，其描述形式是有区别，参及评审人员也是不同。如果让具体操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”现象，如果让高层管理人员也去评审那些操作性需求，无疑是一种资源浪费或者就会出现案例三情形。

建议二：正式评审及非正式评审结合
　　正式评审是指通过开评审会形式，组织多个专家，将需求涉及到人员集合在一起，并定义好参及评审人员角色和职责，对需求进行正规会议评审。而非正式评审并没有这种严格组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式评审比正式评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。

建议三：分阶段评审
　　应该在需求形成过程中进行分阶段评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行大规模评审拆分成各个小规模评审，降低了需求返工风险，提高了评审质量。比如可以在形成目标性需求后进行一次评审，在形成系统初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体需求进行评审。

建议四：精心挑选评审员
　　需求评审可能涉及人员包括：需方高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方领域专家等等。在这些人员中由于大家所处立场不同，对同一个问题看法是不相同，有些观点是和系统目标有关系，有些是关系不大，不同观点可能形成互补关系。为了保证评审质量和效率，需要精心挑选评审员。首先要保证使不同类型人员都要参及进来，否则很可能会漏掉了很重要需求。其次在不同类型人员中要选择那些真正和系统相关，对系统有足够了解人员参及进来，否则很可能使评审效率降低或者最终不切实际修改了系统范围。

建议五：对评审员进行培训
　　在很多情况下，评审员是领域专家而不是进行评审活动专家，他们没有掌握进行评审方法、技巧、过程等，因此需要对评审员进行，同样对于主持评审管理者也需要进行培训，以便于参及评审人员能够紧紧围绕评审目标来进行，能够控制评审活动节奏，提高评审效率，避免发生案例一和案例二中出现现象。对评审员培训也可以区分为简单培训及详细培训2种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中需要把握基本原则，需要注意常见问题说清楚。详细培训则可能要需要对评审方法、技巧、过程进行正式培训，需要花费较长时间，是一个独立活动。需要注意是被评审人员也要被培训。

建议六：充分利用需求评审检查单
　　需求检查单是很好评审工具，需求检查单可以分成2类：需求形式检查单和需求内容检查单。需求形式检查可以由QA人员负责，主要是针对需求文挡格式是否符合质量标准来提出，需求内容检查是由评审员负责，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审重点。检查单可以帮助评审员系统全面地发现需求中问题，检查单也是随着工程财富积累逐渐丰富和优化。

建议七：建立标准评审流程
　　对正规需求评审会需要建立正规需求评审流程，按照流程中定义活动进行规范评审过程。比如在评审流程定义中可能规定评审进入条件，评审需要提交资料，每次评审会议人员职责分配，评审具体步骤，评审通过条件等等。通过评审流程执行可能会避免出现案例五之类问题。

建议八：做好评审后跟踪工作
　　在需求评审后，需要根据评审人员提出问题进行评价，以确定哪些问题是必须纠正，哪些可以不纠正，并给出充分客观理由及证据。当确定需要纠正问题后，要形成书面需求变更申请，进入需求变更管理流程，并确保变更执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果落实，使前期评审努力付之东流。

建议九：充分准备评审
　　评审质量好坏很大程度上取决于在评审会议前准备活动。
常出现问题是，需求文档在评审会议前并没有提前下发给参及评审会议人员，没有留出更多更充分时间让参及评审人员阅读需求文档。更有甚者，没有执行需求评审进入条件，在评审文档中存在大量低级错误或者没有在评审前进行沟通，文档中存在方向性错误，从而导致评审效率很低，质量很差。对评审准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作

7.4 范围管理 2009下
阅读下列说明，针对项目范围管理，回答问题1至问题3，将解答填入答题纸对应栏内。
【说明】
C公司是一家从事电子商务外国公司，为了在中国开展业务，派出S主管和W翻译来中国寻找合适系统集成商，试图在中国建设一套业务系统。S主管精通软件开发，但是不懂汉语，而W翻译对计算机相关技术知之甚少。
W翻译通过中国朋友介绍，找到了从事系统集成H公司。H公司指派杨工为该业务系统建设项目经理，及C公司进行交流。经过需求调研，杨工认为，C公司想要建设一个视频聊天网站，并据此完成了系统方案。在W翻译下，S审阅并认可了H公司系统方案。经过进一步谈判，C公司和H公司签订了合同，并把该系统方案作为合同附件，作为将来项目验收标准。
合同签订后，杨工迅速组织人力投入系统开发。由于杨工系统集成经验丰富，开发过程进展顺利，对项目如期完工很有把握。系统开发期间，S主管和W翻译忙于在全国各地开拓市场，及H公司没有再进行接触。
就在系统开发行将结束之际，S主管和W翻译来到H公司查看开发进度。当看到杨工演示即将完工业务系统时，S主管却表示，视频聊天只是系统一个基本功能，系统核心功能则是通过视频聊天实现网上交易电子商务活动，要求H公司完善系统功能并如期交付。杨工拿出系统方案作为证据，据理力争。
W翻译承认此前他工作有误，导致双方对项目范围认识产生了偏差，并说服S主管将交付日期延后2个月。为了完成合同，杨工同意对系统功能进行扩充完善，并重新修订了系统方案。但是，此后C公司又多次提出范围变更要求。杨工发现，不断修订系统方案已经严重偏离了原始方案，系统如期交付已经是不可能任务了。
【问题1】（6分）
请结合案例简要说明，详细项目范围说明书应包含哪些内容，并指出C公司和H公司对哪些方面理解出现了重大偏差。
【问题2】（6分）
请指出S主管要求是否恰当？为什么？并请结合本案例简要分析导致C公司多次提出范围变更可能原因。
【问题3】（3分）
作为项目管理者，杨工此时应关注范围变更控制要点有哪些？

〔问题1〕
详细项目范围说明书应包含如下内容：
1、项目目标；
2、产品（或服务）范围描述；
3、项目可交付物；
4、项目边界；
5、产品验收标准；
6、项目约束条件；
7、项目假定。

C和H在如下几个方面出现了严重偏差：
1、项目目标：H以为是实现视频聊天网站，而C期望是通过视频聊天实现网上交易电子商务；
2、项目可交付物：同上；
3、验收标准：H把未经确认存在严重偏差“系统方案”作为验收标准。

〔问题2〕
S主管要求是恰当。
因为双方在需求（项目范围）理解上存在重大偏差，而H公司未把详细项目范围说明书（需求分析说明书），提交给C公司（S主管）确认签字。

导致C公司多次提出范围变更可能原因：
1、W翻译对计算机相关技术知之甚少，未能准确转达S主管需求；
2、杨工收集需求时，理解出现偏差，未能准确把握需求；
3、杨工编制需求分析说明书，未进行内部评审；
4、需求分析说明书（或项目范围说明书）未及C公司达成一致，未提交给S主管确认签字；
5、杨工在范围控制上做得不好。

〔问题3〕
1、确定范围变更是否已经产生；
2、对造成范围变更因素施加影响，以确保这些变更得到一致认可。
3、当范围变更发生时，对实际变更进行管理。
（以上为书本上，me考试写是：
1、重新编制项目范围说明书，及C公司达成一致，并让S主管确认签字；
2、建立整体变更控制流程，做好范围控制。
第8章 项目进度管理
8.1 项目进度
【说明】
　　某系统集成公司现有员工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】（4分）
　　 请用150字以内文字，分析问题发生可能原因。
【问题2】（5分）
　　 请用150字以内文字，建议小丁应该如何做以保证项目整体进度不拖延。
【问题3】（6分）
　　 请用200字以内文字，概述典型信息系统集成项目进度／时间管理过程
和方法以及资源配置对进度制约。
答：
【问题1】
（1） 销售部没有及时让软件开发部参及项目早期工作，需求分析耗时过长；
（2） 项目经理首次担任，经验不足，进度估算不准确；
（3） 项目资源配置不足，项目经理兼任系统分析，缺乏专门系统分析和设计人员
（4） 工作安排没有充分利用分配项目资源，资源有闲置；
（5） 在安排进度时可能未考虑法定节假日因素

【问题 2】
（1）向职能经理申请增加特定资源，特别是增加系统分析设计人员；
（2）将部分阶段工作改为并行进行，以节约时间
（3）临时加班/赶工，尽可能补救耽误时间
（4）对后续工作工期重新进行估算，并考虑节假日问题，修订计划，尽量留有余地
（5）加强沟通，争取客户能够对项目范围以及需求、设计、验收标准进行确认，避免
后期频繁出现变更。
（6）加强对阶段性工作检查和控制，避免后期出现返工。
此外，如有可能还可采取外包和缩减范围等办法，不过不建议在本案例中采用

【问题 3】
1、进度管理过程
过程：活动定义，活动排序，活动资源估算，活动历时估算，制定进度表，进度控制
方法：制定进度管理计划
2、资源对进度影响
（1）一般情况下，项目活动历时及投入资源数量成反比，即投入资源数量越多，活动历时越短。但是，当针对某一活动资源投入数量达到一定规模时，再增加资源投入不会进一步缩短项目活动历时，也就是资源投入递减规律
（2）非关键路径上活动历时只对项目产生较小影响或不产生影响，而关键路径上活动历时延误，则会直接影响到项目工期。因此每当缩短项目工期时，应对首先考虑在关键路径活动上增加资源。
8.2 项目进度
阅读下列说明，回答问题1至问题3。将解答填入答题纸对应栏内。
【说明】
J公司2008年3月中标某市公安局人口管理系统开发项目，因该市要在2008年11月举办某大型国际会议，因此公安局要求人口管理系统一定要在2008年7月1日之前投入使用。强某是负责这个项目项目经理，虽然他进公司才不到3年，但他已成功地管理过2个类似项目，被大家称之为“救火队长”，而强某也对自己信心十足。但这次和以往不同是强某还同时管理着另外两个项目，而这个人口管理系统项目工期要求紧、他能调用人手少。 该人口管理系统项目属于升级项目。原来系统为J公司开发，是C/S结构，只能管理本地城区常住人口。新人口管理系统要求是B/S结构，要既能管理城区常住人口又能管理郊区常住人口、市辖县常住人口和流动人口，而公安局要求该新系统首先把流动人口管理起来。该项目从技术角度可分为网络改造和软件开发，而软件又分界面、业务流程和数据库三个子系统。他们团队有6人，其中有人做过类似C/S结构项目， 而公司刚结束一个网络项目及本次承担网络改造项目在技术架构方面几近相同， 只是规模不同。公安局要求新系统能够支持移动接入，而项目团队中没有一人接触过移动接入技术。强某凭直觉知道依现有人员在2008年7月1日之前完成项目是不可能。

【问题1】（5分） 请说明强某可以用什么方法和技术来估算项目工期（150字以内）？
【问题2】（5分） 请说明强某可以采取哪些方法来压缩工期，以使项目能够在2008
年7月1日之前交付（150字以内）？
【问题3】（5分） 请说明强某可以采用哪些方法来跟踪项目进度，以确保项目能够
按进度计划完成？

【问题1】