软件需求管理只局限于软件工程范畴吗?——一个烂尾项目尾款回收案例的思考

近段时间公司在筹备CMMI 5级认证,主任评估师是一位我非常尊敬的是实战派资深人士,为国内很多大企业提供软件工程和管理咨询。应团队要求请老师做了一堂软件需求培训课,这是应老师需要,我分享的一个与需求有关的案例,同时也是从软件工程之外的角度对需求管理的重新思考。

项目情况

13年左右,公司业务重组,我接手了一个新部门,因此接手了一个已结束的烂尾项目,客户是国内一家著名的航空公司。

这是一个整包项目,客户提需求,我们交结果。因为需求变更过多,项目异常终止,留下未执行完的合同,项目成本未回收,处于亏损状态。

好在我方项目经理契约意识很强,每次有需求变更,无论客户的项目经理是否回复确认,都会给对方发邮件说明项目的变更情况,事后经统计的总体变更工作量达到60%。

处理方式

  • 确定目标:

和上级领导请示,最低目标是回收成本。

  • 客户谈判:

第一步,尝试性沟通:以充足的证据作为基础,先当面沟通,当面说的挺好,回复去努力推动,因为项目是异常终止,结果可以预见,后面就没回音了。

第二步,表明态度,穷追不舍:遇到这种情况,我先是表明有困难可以商量,没有回复我会一直骚扰你,还是没回复。

第三步,书面催款:进入下一阶段,发催款邮件,邮件一律抄送他的上级,还是没有得到解决。

第四步,法律恐吓:最后就是硬的一手,告知再得不到答复我们会发律师函。项目没做好可能也就是部门内知道,如果收到律师函,他的整个部门就在自己公司挂好了,坏事传千里,谁都不想名声在外,于是对方有了实质性响应。

经过半年多的拉锯,最后回款50多万,收回项目了成本。

事后思考

如果没有项目经理的有效证据,这笔款是否收得回来p>

为什么需求变更超过60%才以项目终止的方式结束,中途及时沟通是不是会有项目成功的可能其他更好的出口p>

其他项目如何避免这样的风险出现关键赌在项目经理一人身上,还是应该有个机制的机制能以最小的代价预防大部分风险p>

组织对项目是如何管理的汇 有没有个内容框架识别和管理项目风险和风险发生时,项目经理、客户经理/销售经理是否有配合,标准的最小行动计划是什么p>

需求管理仅限于狭义的软件工程范畴,还是应该与组织的其他管理相协同运营管理应如何与项目管理对接p>

 

只有想不到,没有做不到,意识到问题就能解决,关键是有没有相关的意识。

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年4月22日
下一篇 2021年4月22日

相关推荐