案例一:
项目经理小李接手了一个前项目经理离职的电子商务平台项目进入项目后,小李立即着手查看了前项目经理交接的文档,然后在项目成员中调查发现:
小李面对这种情况,不知道如何是好?
这个案例大家看到了这是因为需求开发无效和需求管理失控造成的项目过程混乱,没有标准答案,但是处理这个案例的方式包括:
第一步,小李要迅速建立项目变更的管理机制,要赶紧分析项目干系人,识别决策项目变更的CCB(控制变更委员会)的成员,不管提10个需求也好,1000个也罢,分析完对项目进度、成本、资源、质量的影响后,都要通过CCB进行决策。
第二步,要安抚好项目的团队成员,询问他们离职和离开项目组的真正原因,然后把问题反馈给高层领导。
第三步,重新梳理需求状态。这一步比较麻烦,但是很关键和必须,列出需求清单,然后检查每个需求现在的状态(提出,已评审,已设计,已开发,已测试等)。
第四步,判断需求的稳定性。哪些需求比较稳定,哪些需求变化很快,哪些需求是新提出来的问题?分析造成这种局面的原因。大致会分成:
1.业务流程不成熟,需要流程再造。
2.新业务,客户了解的不多。
3.需求“镀金”(过度的开发需求)。
4.需求迁移。(客户不满足于功能有无,需要功能升级)。
5.干系人识别不全。
6.利益方需求冲突。
第五步,根据需求变化的原因,采取对应的措施,深度开发需求。
序号 | 需求变化原因 | 处理措施 | 责任人 |
1 | 业务不成熟 | 召集业务部门人员开会,讨论流程方案 | 业务部门代表、项目经理 |
2 | 新业务 | 对标标杆 培训与咨询 购书自学 | 业务顾问 |
3 | 需求镀金 | 编排需求优先级 | 项目经理 |
4 | 需求迁移 | 分析必要性,CCB决策 | 项目经理、CCB |
5 | 干系人识别不全 | 对利益大并且权力大的干系人重新识别 对利益大权利小的干系人识别出代表 | 项目组全体人员 |
6 | 利益方需求冲突 | 焦点小组会议,跨部门协调会议,引导式研讨会等 | 项目经理 |
第六步,做好需求的确认和版本管理工作。每一个提出的需求,应该都能追踪到是谁提出的,什么时间提出的,并且要和提出人进行沟通和确认,随口说的需求不能做为项目开发的依据。必须的,必要的,非做不可的需求才能写进需求说明书。需求说明书应该要标注版本,每次修订都应该有修订记录。设计和开发人员用的是哪一版需求,可以追溯。不仅是每次都给一个最新的版本给大家,而是需要正式通知大家目前应该遵循的标准是哪个版本。对于历史版本也要妥善保存,以备不时之需。
第七步,项目经理要积极和公司内部的商务人员进行沟通,讲需求变更的真实原因说清楚,整理好哪些原因的变更应该由客户承担责任,哪些原因应该内部承担,有理有据的公布状态。商务人员可能会走合同变更。
第八步,认真做好需求的评审工作,将评审的结果要及时通知各方,监控各人员的态度和反应。
案例二:
小陈是一个移动化软件开发项目的项目经理,他现在目前的项目状况是:
这时,公司领导询问小陈项目状态,小陈应该如何处理?
案例三:小黄做一名自动化生产项目的项目经理,项目3月份开始时,对项目工期和成本进行了估算,认为项目工期至少要6个月、7人、30个人月才能完成。
但是客户方提出项目必须在8月1号上线,小黄认为如果按照合同范围,这是不可能提前一个月完成的工作。
另外,小黄从人事部获悉,项目组要求的7个人,目前还有4个招聘任务没有完成,且不知道是否能够在4月份召齐小黄需要的项目人员。
但这时,公司领导对小黄下了行政命令,要求小黄加班也要提前上线。
小黄应该如何处理这种情况?
案例四:
小张原本是名技术人员,因为公司有一个临时紧急的项目而被任命为项目经理,公司领导认为小张技术扎实,客户需求并不复杂,小张完全可以胜任。
小张对用户进行了两轮调研后,发现情况和领导说的一样,顺利的通过了设计评审和内部测试,但是让小张万万没有想到的是进入用户验收测试时,发生了如下情况:
小张觉得非常委屈,请问小张项目的问题到底出在哪里?
案例五:
小王是名有3年工作经验的项目经理,在一次开发实施类的项目启动时,小王做了非常细致的计划,尤其是担心客户不配合项目工作产生拖延,制定了一套客户方和项目组临时的管理组织结构,并对每个角色都写了详细的工作责任说明。
小王在项目的执行过程中,发现客户并不是按照之前承诺的工作职责履行自己的工作,经常按照自我的理解完成工作任务,这给项目组带来了很多意想不到的麻烦,很多既定的计划不能按期完成。小王尽管重申了多次客户方的项目职责必须履行义务,但是遭到了客户方高层领导的批评,认为小王只要做好自己份内的事情就可以了。
小王觉得非常委屈,但是也不知道问题到底出在哪里,也不知道该如何解决。