【案例正文】
手里有个项目,项目已进行到一半,目前在软件对需求的修改阶段。
客户方面由两个大的部门组成,如下所示:
业务部门副总 建设部门副总
使用部门主任 建设部门主任
按照一般的规律,客户方应该有一个项目统一的接口人,我项目组只与该客户接口人交接。但本项目客户方没有统一的项目接口人,我项目组在涉及到需求确认或变更的时间,需从使用部门主任签字,到业务部门副总签字并盖章,再与建设部门主任沟通,然后建设部门主任向建设部门副总请求。
我已陷入多头沟通的泥潭。
其实楼主遇到的这个问题很普遍,尤其是大型的管理系统项目会遇到这些问题,政府机构、大型企业容易出现这种情况。这时项目经理的做法一般是:
1)制定沟通计划、提升沟通层次。这种项目需求阶段的工作一般是自上而下、然后再自下而上,怎么理解这个说法呢?这种涉及单位内部管理流程的系统,一般都会有单位高层领导牵头,领导对于上这种系统都会有个期望,比如提高部门协作效率、减少流程对接中的失误等等。因此,项目经理首先要提升沟通层次,与单位领导建立联系,深入领会领导的意图,然后按照领导的意图去与各个部门沟通;最后把各个部门的需求再整理、再加工,反馈给单位领导。
这么做的好处是,第一借领导的要求和关注可以让下属部门很好的与你配合;第二是完善沟通体系,避免部门间相互推诿,从而造成系统逻辑冲突。
2)项目经理要更加积极主动。尤其是与各个部门的单独沟通,让这个部门感觉其他部门都和配合,必要时可介绍其他部门的进展,让他知道自己在拖后腿。
3)建立客户方的项目沟通接口。这个方式已经有很多人说了,就不再赘述。
最后,提点个人的建议:项目经理不要怕麻烦,多跑腿、多沟通,关键节点的情况一定要让单位领导知道。
这种状态是很苦恼,如果能够及时解决,不但能够节省很多沟通成本,还可以使项目的高效运转。
按我的理解,客户方面的建设部门,主要是负责规划这个项目,而业务及使用部门则是软件开发完成之后真正的使用者。
从这个角度来看,建设部门是应该具有前瞻性的,应该是掌握大方向的;业务部门对自己那一部分的业务非常专业,详细的业务需求应该是他们来提出。
您不妨召集一个会议(但在会议之前一定要提前做好功课,即先要和各方面沟通好,会议只是一个做决定的地方),将上述观点阐明并得到大家认可,然后确定好主要接口人(最好是建设部门),以后凡是需要做决定的时候,就找那个部门,而关于业务细节上的讨论,则可以直接找业务及使用部门沟通。
从实质上看,这不是一个多头沟通,只是一个链条很长的沟通,即“一头”沟通。
你所做的项目是要就项目满足业主的需求。业主接收项目的方式很多,集中接是一种,分开接也是一种,不能说你习惯了什么方式就得用你的方式,你的目的是完成项目,满足业主的需要。
至于交接中沟通链条长的问题,是你在做项目之前就应该考虑的问题,因为这个工作程序尽管死板,但它已经在业主那里有效运行了那么多年,你必须遵从人家的规则,不能摸着石头过河走一步看一步。
最后,既然不好改变业主的沟通方式,那就改变自己,若你要提前全部交付,那就加派人手多部门齐头并进,这不失为一种办法。
联系客服