经了解发现，项目在双方更换负责人时没有做到很好的交接过渡；项目日常管理也不规范；最重要的是，项目定位出现严重错误，误把项目干系人理解成单一的客户关系，即把信息中心当成了直接用户。而实际上，信息中心仅充当客户（或者说业务发起人）和运营部门的角色，无法在项目验收阶段充当拍板人；办公室才是强势的最终用户的典型代表。也就是说，项目干系人是：信息中心（客户&运营人员）+办公室（最终用户代表）。那么，前期以信息中心为对象的需求调研结果，注定了在需求实现后系统投入使用时无法一步到位得到最终用户的认可。所谓“执旧方以医变症，药既不对，病必加危”，在这种情况下，扭转项目形势的首要问题是：重新诊断项目症状，定位问题后再对症施“药”。受项目干系人定位错误的影响，当前最大的问题表现为：
² 现场客户关系紧张
² 前期需求调研结果被否定
² 最终验收时将找不到对应的目标负责人
当然，软件产品不够成熟、项目开发人员不在现场等问题也是阻碍项目进展的因素，只是相比之下，最严峻的问题还是以上三个。在加强项目内部管理的同时，必须把这几个与客户相关的影响因素放在重要位置，于是，“沟通”便成了项目至关重要的工作。
经过三个月的磨合，现场客户关系已得到缓解，借助办公室秘书科人员的话来说，就是“在斗争中建立了友谊”；为了保证系统能真正推广使用，在上线期间对公文流程甚至是系统优化功能都做了重新的调研，调研对象是最终用户代表——秘书科，从而解决了 “前期需求调研被否定”的问题；而目前仍未得到解决的问题是：验收时找不到对应的目标负责人，无法按照合同界定验收条件，系统优化需求不断增加，项目变得不可控。
如果在前期清楚项目干系人是“客户+最终用户”这种模式，则应在项目建设过程中，建议客户方设立一个项目小组，客户和最终用户都派出代表作为项目小组成员，定时开会汇报项目进展，让验收条款对应的目标负责人更早的参与到项目中来，避免出现如：在本项目问题改进到90%时，我方领导跟办公室主任面谈时，办公室主任说还有好多问题没修改……目前，项目中的目标负责人已明确，如何让目标负责人真正负起验收的责任是关键也是难题。
l 产品管理的问题：
在各个项目中，存在一些共性的需要修改或优化的问题，其实可以归纳到标准产品或行业应用中去，以减少在不同项目中需要由各项目组再去发掘、修改问题，从而提高项目实施效率，让用户感觉我们的产品是成熟的、为他们量身度做的。
由此可见，如果我们把产品以行业应用进行整版，既能最大限度地吸引新客户，又可减少项实施成本，何乐而不为呢？
l 加强项目管理规范
在我接管***项目期间，发现文档不齐全、需求说明不清晰且没有用户确认签字，导致后期需求被否认时牵扯不清。办公室人员说：“需求实现前并没有征求过我们的意见，你们是在凭空想像设计系统……把你们确认过的需求拿出来看……”。需求文档是有了，由于不清晰且没签字确认，结果，在系统上线后，最终用户对系统不满的前提下，我们只能花费大量的人力物力，对整个系统24流程及相关功能进行重新调研、实现及优化。
目前项目管理规范相对完善了，建议继续加强监控与管理，在某些重要里程碑未按规范完成时，限制越过相关工作执行下个里程碑，比如：在需求说明文档没有签字确认前，坚决不做需求实现，以防止实现需求后被否定而白费工作。
l 配置管理问题：
由于项目开发人员不在现场，且项目问题由多个人进行修改优化，同时，各个开发人员又对多个项目问题进行修改。在此前提下，大部分项目的配置管理工作只能按目前的状况：集中在公司的CVS库中进行管理。配置管理的工作无法由项目组进行监控，目前频繁出现每次打包更新到项目现场的程序总是有缺漏，每次更新都必须进行全面的测试调整再投入使用，无形中增加了大量的工作量，有时因测试疏漏，问题暴露到最终用户才发现，造成用户感觉“系统不稳定”的影响。
因此，必须提高对配置管理的重视程度，如果目前状况决定仍只能集中管理，建议设立一名专职的配置管理员加强日常配置管理工作。
l 团队工作：
由于JAVA开发人员的紧缺，一般项目中都不配备开发人员到现场工作，目前问题的修改通过邮件、TD、QQ、MSN、电话等方式进行沟通，总的来说，对修改结果影响不大。但是，沟通效率极低。从问题的沟通、修改到更新投入使用，所花费的时间比在现场修改更新要慢好几倍。
建议考虑解决开发资源调配问题，以提高工作效率。
l 人个对项目管理中的关键环节——与客户沟通的一些体会：
缓解现场客户关系——
用心服务，争取相对平等地位；把握需求的度，有所让步，有所坚持。
场景1：（第一天去秘书科）
秘书科五个人，站着以吵的方式向我投诉系统问题，没让我发话的余地。当时的处境只能用两个字形容：郁闷！
场景2：（一个星期后，仍在秘书科）
郑秘书搬来“专座”，吴秘书端上茶水点心，付秘书维持秩序“一个个来，我们坐下来慢慢谈（需求）”…… 用他们开玩笑的话：小林现在是秘书科的OA小秘书。
是什么让他们的态度有180度的转变？我没有很好的方法，我只能用心。用心去聆听他们的抱怨；用心去理解他们的抱怨；最后用心去化解他们的抱怨——尽可能协助解决他们想解决的问题：
Ø 对需求进行分析提炼，避免提一个改一个、跟着用户发散的思维乱改功能；进而体现出以专业的角度为其考虑问题。如：用户提出在收文新建界面上增加一个[新建]按钮，以实现快速连续新建收文的功能；结果我们交付给用户的功能是：点击[新建]按钮时，系统自动把当前的公文保存、关闭，再刷新一个新建界面出来，每建一份文减少两次鼠标点击率。实现这么一些小小的功能，给用户的感觉是专业、体贴；同时，也为项目组在需求实现中掌握一定的自主权奠定了基础。如公文附件的功能按用户一个个的需求更改下来，浏览界面变得面目全非，连我们自己都觉得难用，后来我提出，别在这个基础上再改了，由项目组提供更好的解决办法，最后，我们把附件的功能还原为产品自带的功能，用户竟然没再抱怨；
Ø 在系统问题还没得到解决前，主动用手工方式协助他们完成工作。如在领导活动表数据导出不正确前，每周一早上帮忙手工做好领导日程报表；
Ø 因临时文件出错丢失正文时，先想办法找相关人员拿到原始文件令其正常运作下去，再解决问题，给相关人员解释问题情况，减少因“丢文”现象进而说系统不稳定的影响范围；
Ø 秘书科的人有吃零食的习惯，在关系紧张的时刻，送上一袋苹果，带着微笑跟大家开玩笑说“来，大家吃个苹果下下火……”气氛一下就缓解下来；需要他们协助整理需求，呈上一大叠文件同时捎上一盒饼，微笑着说“干活了~大家补充一下能量先……”。当然并不是非这么做不可，只是有时他们也会与我分享食物，仅是礼尚往来、增进友谊的做法。
……
服务重在沟通，沟通与其动之以口，倒不如动之以心！