信管网案例分析

导航

南方移动项目案例解析(范围管理)-系统集成项目管理工程师知识点

2019年02月28日来源:信管网 作者:cnitpm

系统集成项目管理工程师知识点:南方移动项目案例解析(范围管理)

1)规划项目范围管理过程

“这个项目的工作范围应该是明确的、固定的(《技术规范》我还没看过呢)”一一王东对范围管理没有给予应有的重视。

王东又打电话问负责这个合同的销售代表老杨:关于接入的准备工作当初跟局方是怎么定的、怎么交待的,老杨说:“哎呀小李,你不找我我还想找你呢,签完合同就不知道这个项目怎么样了。你说各地市的接入准备工作吗?他们说是他们负责的呀,我就没多管,你是不是该督促他们一下啊?”——实际上,项目的范围边界很不明确。

2)收集需求过程

“小凌和另外两位局方的人员针对未来的网管系统各个功能分别提出他们的想法,李鹏就跟他们谈并逐一作记录。虽然谈需求进行得不是很有规律,最后需求分析还是按时完成了,得到了一份关于该项目网管系统的需求说明。该说明对系统的各个功能、使用方法都提出了要求,有些要求非常具体”——需求不只是做记录,这是典型的被动式需求调研,或守株待兔式需求调研。

3)定义范围过程

“李鹏告诉王东说这份需求文挡的内容虽然有些方面提得比较细,但有不少地方跟《技术规范》不一致,想商量商量怎么处理。最后他们觉得这份需求有些地方是对《技术规范》的发展,有些地方是细化,体现了局方现在对网管系统的实现要求,与其到测试或验收时再处理,还不如现在就考虑”——不符合《技术规范》的内容,怎么能纳入需求呢,如果用户坚持,应启动变更程序,变更合同附件《技术规范》。

4)创建WBS过程

“项目工作铺开后大家才发现项目的工作没有原来计划的那么简单,有些工作在原WBS中是没有的,还有不少工作是计划外的,这都占用了项目成员的很多精力。王东习惯性地感叹:“意外太多了!怎么我们做的每一个项目都有这么多意外,原来做出来的计划就没有办法顺当地执行下去,计划没有变化快啊!”这样项目计划就没办法按原来的进度要求走下去了,原来每个人的正常工作节奏全都被打乱了,每个人都很忙”——WBS分解的一个重要原则就是不能遗漏任务,一个遗漏的任务会摧毁整个进度计划。项目中的意外通常有两个来源:一是遗漏的任务,二是未识别的风险。显然,案例中的意外主要来源于任务遗漏,比如:国外采购设备的到货时间问题,“郭处知道了设备到货时间的问题后问王东:你们公司没有去考虑过这个问题吗?”

5)确认范围过程

“系统演示出的功能与《技术规范》不一致,最后的验收将以《技术规范》为标准”一一项目经理要尽早搞清楚:谁负责验收、验收标准是什么、谁有验收表决权或评判权。

6)控制范围过程

“局方领导在观看软件演示时多次提出了修改意见。对于这些意见李鹏提出这属于项目范围变更,要求按变更来处理。但郭处说这不是范围变更,软件功能本来就该做成这样子,是开发组理解错了,不存在变更不变更的问题。为了能够说服郭处,李鹏和王东详细查阅了《技术规范》,结果悲观地发现在很多地方《技术规范》并没有清楚描述要做成什么样,所以很难判定局方的意见是不是属于变更。既然是这样就只有满足局方的要求了。”——需求是《技术规范》的细化,查《技术规范》当然没用了;需求收集完成后,应要求用户进行确认(是否是他们想要的软件功能),确认后的需求成为需求基线,若要变更就需要走变更控制流程了。

“局方提出的这些意见有的跟《技术规范》一致、有时不一致,一开始我和李鹏还想部分顶住,但因为局方领导层次较高,我觉得他要是震怒可能公司领导一定又会很紧张,同时也不希望因为我不同意满足局方的要求让局方向高层领导投诉,这样会让我很被动”——这是因为局方领导不知道他们的要求与技术规范相违背,有必要提醒他们;《技术规范》是验收标准,最终项目验收还是要按照《技术规范》来。

“这种对修改要求的满足一旦开始就很难停止,这样项目就陷入了很被动的循环,刚把上次的要求改好了,想回复正常的开发节奏,新的一轮又开始了。这让我觉得就像转轮里的小白鼠,自己永远不知道什么时候是尽头,直到累死为止,而外人觉得你在干你该干的事情。”——使用迭代模型或敏捷方法,每8天一个迭代周期,先开发优先级高、稳定性强的需求。


温馨提示:因考试政策、内容不断变化与调整,信管网提供的以上信息仅供参考,如有异议,请考生以权威部门公布的内容为准!

分享至:
请使用浏览器的分享功能,把好文章分享给更多的人

信管网 - 信息系统项目管理专业网站

下载APP-在线学习

培训课程

0元畅享

考试题库

免费资料

APP下载