作为系统的开发商和实施方，上线之前的项目周会经常是被批斗会，一则因为项目前期缺乏对项目范围的明确和共识，二则也因为双方项目组织混乱，项目人员的更换频繁，导致开发和实施的进度、质量都难以保证。经常周会上对于未完成的事项抱怨、发牢骚的多，而没有太多关注项目取得的进展，由此形成的负面认识非常容易在用户群体中扩散开来。所以，一个周会下来，双方的项目组成员大多情绪低落，态度消极。

　　系统上线使用一个多月来，系统缺陷、使用问题和业务差异等问题还是很多，所以经常要召集相关的关键用户、业务领导等参加会议，讨论和解决问题。与会的范围小了，同时也有了明确的目的，反而容易在短时间形成共识，即使是有负面的影响也没有马上扩散到其他项目相关人员。因为这种小会很多，所以一个多月来也就开了一次所有主要成员参加的阶段性的项目总结会议，不过作为补充，每周统计了系统中实际业务单据的数量，总结系统的使用和改善状况、存在问题等，形成书面报告，通过邮件发送给了双方的项目组成员和领导。总体看来，并没有因为没有召开项目周会而蒙蔽了项目信息，反而在一定避免了某些问题所造成的负面影响的扩大化，用户的信心逐渐开始恢复了，同时项目组成员的工作效率也有了提高。

　　其实回头来看，过去召开的项目周会并没有很明确的动机，如讨论某个问题的解决方案等，大多只是中断与会成员的工作，仅仅给大家通告一下项目的进展等，更像是完成例行的一个任务而已。其实这些周会的信息本来就可以通过公告、邮件等更高效的方式传递的，就算是在这种周会上要讨论某些问题，也会浪费问题无关人员的时间。当然，如果是为了鼓舞士气、激励大家，要求相关人员全部与会是必不可少，但绝大多数的周会等定期会议并不是如此。

　　所以我以为，即便是项目合作各方有必须召开周会的约定，如果失去了生产力的实际意义，项目周会是完全可以免掉的。