空洞的软件项目实施总结 wxh zt

wxhanshan

原作者：李会庄 由会员：项目管理者联盟 转载   
上个星期帮一个朋友看了一个项目实施方案，让我提出一下建议，我刚开始不是很感冒，后来觉得应该给人家意见把，才冒出来系统去整理一下项目实施的东西。简单回忆一下项目实施的一些东西，然后整理一点东西出来，比较乱，暂且就这样了。

1.  项目组组建

1.1多方项目组成员
给出多方项目组成员组成。很多吃过亏的客户，在搭建项目组的时候，甚至在招标书的时候，要求软件公司的项目组里面必须有项目管理专业人员，甚至持有pmp证书，或者有专业的需求分析人员，并持有系统分析证书。
1.2 多方项目小组成员的稳定性
多方项目小组成员的稳定性。人员流动通知对方，申请多方认可。特别是相关负
责人流动，需要多方确认。

2. 实施的进度日程表
给出系统上线日程表

3. 软件模块实施的先后顺序
先上哪些模块，后上哪些模块。新系统和老系统并行运行的机制处理方式。历史数据的处理方式。

4.进入新系统的数据截断日期。

5.实施中多方会晤机制
定期会晤机制？1周几次？还是每几天1次，每天1次？

6.监理方的立场说明
监理方代表的是甲方的利益，出现冲突的时候应该从维护甲方利益出发，考虑问题。

7. 问题诊断机制
实施出现问题时候，监理方应该要协助甲方诊断问题的类别，是来自于硬件提供商，
还是软件提供商，还是甲方的问题。如果不能诊断，应该主持召开多方会议确认问题的来源，类别。

8.问题的响应速度要求
当问题被诊断后，应该要求问题解决的时间，要求相关单位在规定时间内解决。如果问题不能在指定时间内解决，应该要考虑补救措施。

9.需求变更处理
当甲方提出需求变更后，监理方应该作出判断，这个需求是否合理，是否超出了实施前制定的需求基线，如果超出了需求基线，就有可能需要追加预算了。
当然软件需求变更存在一个工作量的问题，如果工作量较小，就不存在甲方追加预算。一般的项目实施都是有1个需求基线，然后免费的需求变更工作量有1个上限，当需求变更的工作量超出这个上限，就需要甲方追加成本了。

10. 甲方2次开发的难度控制 当在设计甲方业务处理流程的时候，应该要考虑到甲方业务流程 更改后，系统的
可配置性。这1点也是j2ee的主要特点体现。当然，如果系统使用了工作流产品的话，可以从工作流角度来考虑解决。

11. 财务核算处理方式的灵活能力
一般的企业单位，财务核算的方式是比较固定的，但是也会作变动，当这一块作出变动时候，应该要求软件系统能够比较好的能够实现。
例如：软件系统以前实行的是集中财务管理，后来改变成为半集中方式，或者分散方式。这写都要秋软件系统能够很好的实现能够很好的进行业务处理方式的平滑过渡。
12.甲方业务流程的整理

监理方作为甲方利益代表，应该和甲方一起协助亿方指定出甲方的业务相关流程，在甲方乙方有争论的地方进行协调，并且在流程指定时候应该就要考虑到流程的更改。监理方当然最好能够先帮助甲方进行流程改那就更好了。或者乙方能够提供工作流工具就好了，否则这部分工作会暂用监理方相当多的时间。另外需求搜集变更也会监理方需要高度关注的一件事情。