所谓财务信息化，主要系运用信息技术提高财务作业效率。一个财务信息化项目，即是通过一个项目实施的形式实现该目标。ERP的实施、合并报表系统、全面预算系统、财务共享服务中心的组建等，都涉及在财务领域应用信息技术。本文主要以偏甲方的身份简要探讨财务信息化项目的项目管理。
在以前的项目实施工作中，后附链接的这篇文章给于了重要的启示，本文很多观点也是源自于此文。http://www.itpub.net/forum.php?mod=viewthread&tid=1889335
一、因地制宜、因势利导
项目管理，没有绝对的正确与错误，不同公司有自己的实施方法论，不过用别人总结的话来说，大致应该是“因地制宜、因势利导”。
（一）分轻重缓急，抓战略重点
切忌完美主义倾向，以及不分轻重缓急一把抓。所谓战略重点，是围绕项目目标展开的核心内容。作为项目经理，心中应当清楚，哪些部分是一定要做成并尽可能完善无可挑剔的，哪些做成后是项目的亮点加分点，哪些是需要做成能用就行了，哪些是无关紧要甚至在必要的时候需要战略放弃的。
在市场竞争中，时间是最宝贵的资源之一，公司能给项目组的时间也是有限甚至是短缺的。在多数项目中，按既定的时间完成项目所有方面的需求是很难实现的。将有限的资源倾斜到项目的重点、亮点，全面出击反而可能一无所获。
（二）管理项目利益相关方
1、你的合作伙伴
不论客户、员工还是供应商，笔者习惯都称之为“合作伙伴”。作为合作伙伴，双方应该互相尊重、互信合作。某些甲方出于对乙方不信任，认为在付款上用较大比例卡住对方，或者对其种种变相压迫，对方就能完全按照自己的意图开展项目工作了。但乙方通常面临着很强的回款考核压力，如果迟迟收不到项目款，乙方公司派驻优秀的顾问资源到项目组的动力也就越低，项目质量也难以满意。在某项目上，一个现场实施顾问甚至向笔者抱怨，我方高层向其公司投诉后，项目组成员感到努力工作的成果未受到尊重认可，反而被否定，后续实施动力和士气严重影响，同时乙方公司不会更替或者补充更优秀的顾问资源到项目组，投诉反而会导致实施质量的下降。
在一个专业的项目实施过程中，从项目实施的个体上看，笔者认为甲乙双方项目经理之间应该是最重要的合作伙伴了。项目经理之间的信任与合作，是项目成功的前提。
2、你的领导
项目经理是直接影响项目执行情况的角色，但领导往往是对项目评价的最重要人员。项目经理及时主动向领导汇报项目进展，而不是被动等待其过问。向领导汇报毋须详细描述具体的流程或者功能细节，除非他对这个细节感兴趣，只需要告诉他项目进展是否顺利，现在可能存在什么风险，你准备如何应对，可能需要他给于什么支持等等。和其他工作一样，领导一方面是你工作的指导者和决策者，也是你工作中的一项重要资源。
（1）领导是一个决策者。有时候领导的多变也是项目的重要风险，及时和领导沟通，可以逐渐深入了解领导对这个项目的看法，以及是如何变化的。在必要的时候，可以让他参会拍板或者签字确认，以免以后随意变更。
（2）领导是你项目一项重要资源。虽然项目经理是项目的负责人，但有的时候让领导出面沟通，或者仅仅是参会听取各方的意见，效果往往比项目经理独自沟通要好很多。领导也可以帮项目组协调到额外的资源。
让领导参与项目的具体形式有：
（1）听取工作汇报，了解项目日常进展。这时候你只需要告诉他你们做了啥些工作，有哪些重点或者有趣的事项，同时一切顺利就可以了
（2）有重大影响的事项，需要领导拍板。让领导拍板，不是直接把问题丢给他，而是要把可能的几种解决方案以及相应的影响列出来，让其选择。
（3）助威。当涉及跨部门沟通或者重要的事项，领导亲自出席会议可以表明其对该项目的重视。
（4）听喜讯。不仅仅告诉他项目进展顺利，同时有哪些亮点突出点。这不仅是项目经理个人和项目组的成绩，也是领导的成绩，有时候甚至是公司的成绩。
3、你的关键用户和组员
一个项目，不是项目经理自己的项目，而是参与项目的每个部门每个人的项目。各部门各分子公司的关键用户，也是项目的owner之一，是项目最重要的利益相关方之一。
对于关键用户，与其利益直接相关的事项，例如，需求报告、测试结果等，关键用户应当代表其所在部门或公司在要求的期限内用书面形式表达意见。对于关键用户和组员，除了其本身的应担的职责部分之外，“参与感”也是调动其项目积极性的一个重要的手段。项目经理及业务专家不是全能的，听取另外一个角度提的意见，很可能有意想不到的收获。如果有条件，可以划一块公共网络区域，用于存放分类整理好的项目文档。项目所有相关成员都可以自主随时访问，及时全面了解项目进展。同时，对于项目重要事项以及定期报告，所有成员都可以获知并且有机会表达合理意见。
（三）有所拒绝，有所担当
一个项目的实施，不是把线下的流程照搬到线上，必然有所改变。系统的上线会涉及到流程甚至组织的变革，动别人的利益，新的流程不可能满足所有人各方面的期望。作为项目经理应当明白，你是对项目整体负责，不是对某个细节应用负责。
财务部门关键用户大多对IT技术是既恐惧又崇拜的心理，普遍存在“IT技术万能”的心态，容易走入这样一个误区——我提的这个需求很清楚的啊，系统一定可以也必须要给我实现。项目经理应该评估：该需求具备普遍性吗？该需求对项目目标重要吗？实现该需求投入的项目资源值得吗？该需求的实现在系统上线后是否可维护性？
诚然，甲方项目经理某种程度上面临着比乙方项目经理更大的压力：项目结束后乙方就撤了，甲方项目组特别是项目经理将面临来自各方面用户的持续挑战。在某项目，甲方项目经理对乙方项目经理说，“XX，系统上线后是几万人使用，哪个地方不满意的话我压力很大啊。”
项目经理需要记住，你不是对项目某个关键用户负责，不是对某个特点模块负责，而是对项目整体负责。对于不合理、不现实甚至不重要的需求和要求，当其影响到项目整体实施，应当直截了当的拒绝。
后面两部分具体阐述项目实施过程中的一些特点和典型问题，套用价值链分析模型的框架，大概分为过程管理和管理规范要求。
二、项目过程管理
项目全过程管理一般包括前期工作、需求调研、方案设计、系统开发配置、系统测试、上线试运行、项目验收、运营维护等过程。项目启动前的前期工作以及结束后的运维工作，不属于项目实施过程中的事项，但是作为一套系统流程全生命周期中重要的阶段工作，本文也简要予以阐述。对于这一套流程，用定做西服来类比：
a. 前期工作，相当于客户准备定做一套西服，大概是准备在办公室穿，通常具体啥样的还没有概念。当然也有客户研究比较深刻，可能是从别人那里看到的方案，也可能是自己摸索过，要做成啥样自己心里也比较清楚了，只不过限于自己的能力和资源做不出来。
b. 需求调研，相当于裁缝给量尺寸，咨询其穿着偏好和习惯等。有多高，胖还是瘦，背驼不驼，日常穿还是在重要的场合穿，等等。
c. 方案设计，相当于根据量好的尺寸，挑选款式，选择细节，最终设计出详细的方案。
d. 系统测试，相当于在裁缝店里试穿，哪里不合适还好修改。
e. 上线试运行，相当于正式穿做好的衣服。
f．验收，相当于七天无条件退货已过（这个比喻不大恰当），衣服没啥大毛病，确认验收交货。
（一）前期工作
可以毫不夸张的说，许多失败的项目，在项目启动那一刻就已经决定了。与互联网行业快速迭代开发不同，财务信息化项目通常是一次性解决公司接下来5到10年的固定管理要求。三思而后行，谋定而后动。
一个失败的项目，在项目实施中后期，项目组通常有这样一个感觉：甲乙双方所有人都在不断的努力，但希望一个接着一个扑灭，一次又一次延期，项目看不到任何曙光，看不到尽头。
1、项目的目标是什么？
项目目标，概括的描述了项目实施的边界，表明了项目做成什么样子才算成功。甲方在设定目标时通常要考虑以下这些问题，乙方也应该对此予以关注。
（1）项目要达到的目标是什么？管理层或者项目Owner对该项目的预期是什么样的？
（2）这个目标符合公司的中长期战略规划吗？一套信息系统使用的年限通常在5到10年，在未来的这几年，公司的业务范围、经营模式、管理模式、组织结构等等预计会发生重大变化吗？系统的应用能够适应这种变化吗？
（3）项目分成几期实现？每一期实现什么内容？
（4）公司准备花几年、几个月甚至是几周时间来实现该目标？
一个项目成功与否，并不是以系统是否上线作为标准，而是以项目是否达到既定目标，符合既定预期效果为最终标准。当然，有的乙方公司认为，系统上线，收到项目款的项目才是成功的项目，因此我们可以看到许多带病上线的系统，甲方抱怨很大而乙方则宣称项目成功。
2、可投入项目的资源有多少？
投入的资源，主要包括人力资源和财务资源。财务资源主要针对甲方而言，公司准备多少预算来完成该项目？信息系统其实是很昂贵的，而且除了一次性投入外还有后续每年运维支出。有多家选项的时候，虽然贵不代表就好，但“便宜没好货”常常不会错。一般来说，乙方报价是和其人力成本直接相关，报什么样的价钱通常就派什么样的顾问。乙方公司也需要足够的薪酬才能够吸引和留住优秀的人才。
人力资源包括甲乙双方可投入的人力资源。除了必要的专业人士以外，领导的支持也是非常的一项资源。项目组通常由项目领导小组、项目经理、业务专家（如有）、业务顾问、技术顾问、关键用户等组成，这些人员的知识和技能能否胜任项目工作直接影响到项目产出。而领导的支持影响项目出现问题时，你能够得到多大程度的支持，特别是在涉及到组织变革时。
3、系统平台和供应商选型
在选型阶段，笔者习惯将系统平台和实施顾问厂商分开来看。选择的思路为在公司能够承受的费用范围内，系统平台能满足基本的要求之后，选择提供的顾问资源最优秀的实施厂商。会计，从自然属性看是信息系统，从社会属性看是管理活动。一套财务系统，在信息处理的过程中，将标准化的管理要求用系统固化下来，这充分阐释了信息系统属性和管理活动属性。顾问能否既懂系统技术，又理解管理理念称为项目能否成功实施的关键要素之一。
如果把实施一个财务信息化项目比作为定做一套西服，那么系统平台就是面料，实施顾问就是裁缝。如果面料劣质，再好的裁缝也无法弥补，但如果裁缝不合格，用最好的面料也做不出你想要的西服。很多实施SAP的企业反映效果不理想，究竟是SAP产品不适合该公司呢，还是实施顾问能力不足？
4、一些常见的风险
甲方通常缺乏既懂企业财务管理又懂信息化管理的复合型人才，也没有专门的PMO，不具备足够的管理项目能力。同时大量不成功的案例作为前车之鉴，缺乏安全感，对乙方多不信任。甲方倾向于不清晰约定项目边界，项目进行中想要什么就要什么，漫天要价。这种项目一个突出的迹象是，客户的主导部门及项目经理在公司很弱势，同时在付款比例上压价严重。
合同签订前乙方常常用以最好的顾问资源来营销，什么老总、合伙人、资深专家全来了，阵容非常豪华。但实际后面用于该项目的是另外一批资源，比如临时拉个人做项目经理、随便抓几个人来组成项目组。这种行为在“五大”也不少见。项目是人做出来的，顾问资源是最重要的资源。对此，建议甲方在合同签订以及招标前的沟通接触中，向乙方明确传达这样的意思：现在与我沟通的这些顾问，如果中标是会派来我的项目吗？我会在招标要求和合同中明确项目组成员（特别是项目经理和业务专家，我要求坐班签到），如果未经我许可私自换人或者长期不到岗，将视作为根本违约。如果这些人不能安排来我的项目，请换可以派来的顾问来交流，否则别浪费大家的时间。
（二）需求调研
需求调研通常由乙方业务顾问主导，主要是了解的三方面的问题：客户的现状是什么、客户认为有什么问题、客户想要什么。
1、客户的现状是什么？
需求调研的程序，包括查阅相关文档、观察实际操作、访谈相关人员等。调研现状，不仅仅是了解现有的工作流程、工作规范、操作手册、工作底稿等，还需要注意识别对项目有重大影响的潜在的利益相关方及其看法，注意识别项目可能存在哪些潜在的风险。例如，其他部门对本项目的态度如何？主数据是否有效管理，质量是否合格？客户的IT软硬件环境如何？操作人员的素质如何等等。这些内容不一定都会记录在调研文档中，但项目经理应该有意识去了解这些内容。在项目的前期，对项目了解的越充分，对项目掌控越牢，后续实施过程中“意外”也就越少。
2、客户认为有什么问题？
这个问题，某种程度上从微观上回答了为什么要上该项目这个问题。换句话说，项目的实施能解决他的什么问题，能够带来什么好处。这个问题对不同的调研对象答案自然不同，对于部分调研对象，或许其回答是，“现在挺好的啊，上个系统说不定还没有我现在好”。
3、客户想要什么？
调研对象通常很难准确表达出其想要的系统是什么样。在这个阶段，调研顾问可以适当介绍其他类似项目的实施结果，“稳定客户项目预期”。在ERP项目实施中，咨询顾问通常会组织专门的培训，宣贯项目实施的效果。客户不知道要什么，那么就应该对其“洗脑”，推动项目正常进行。客户的领导对项目的效果通常也比较模糊，甲乙双方项目经理也应该及时适时主动对其“洗脑”。
一个合格的业务顾问，在需求调研时，不仅仅是听客户自己讲，而且应当在客户不知道讲什么的时候，能够根据自己的专业知识框架进行适当的引导。能够自主的答复上述三个问题的客户，是相当难得的用户了。调研访谈的对象，有可能是某个流程中某个环节具体经办人员，也有可能是相关的负责人。调研对象有可能对调研内容有深刻的理解，也有可能并不理解背后的原理。调研对象可能思维清晰、谈吐层次分明，也可能无法清晰的表述其内在想法。调研对象还可能跳出项目实施范围高谈阔论。因此，需求调研应该是作为业务专家角色的资深业务顾问来主导。
（三）方案设计
方案设计，通常不是咨询顾问自说自话进行设计，而是在设计的同时也在不断同客户交流，根据客户的反馈进行修改。如有必要，应当组织专题会议进行讨论，最终形成一份几十页乃至几百页的蓝图。
方案设计也并非是在需求调研阶段结束才开始，部分设计工作是在调研的过程就已经开始进行。在前期的调研过程中，笔者建议技术顾问也应当适当的参与进来，根据调研结果初步估计技术实现可行性。系统底层框架通常具有全局性影响，一些影响到系统底层框架的必要需求，业务顾问通常不具备能力判断，需要资深的技术顾问全盘评估，尽早准备。
对于蓝图的写作，很多人不得要领，写的内容客户总觉得有所遗漏或者不全面，不放心不敢签字。笔者建议按这样的框架编写：
1、总论，对项目目标、边界等影响项目全局性的内容详述。
2、根据基本业务循环、业务流程等，按业务逻辑顺序逐项阐述基本解决方案。
3、对疑难杂症、重点需求、特色亮点等重点专题的单独分章节详述。
这一套框架是不是有点眼熟？对的，基础会计教材基本上都是按照这样一套框架进行表述的。
（四）系统开发配置
系统开发并不是完全等到前述蓝图已经审定完成以后才开始开发。从前述可以得知，在调研的过程中，部分相应的方案实际上就可以定下来了（客户已签字认可），时间就是金钱，可以适当提前进行开发了。关于具体系统的开发和配置，属于笔者能力范围之外，在此不做特别阐述。
（五）系统测试
关于系统测试，笔者习惯分成三部分：乙方内部测试、项目组内部测试和UAT测试。乙方应当内部自行测试通过，然后再让甲方参与测试。系统功能层面的测试是乙方内部测试要完成的。甲方参与的测试，应该是针对蓝图和需求的测试，不是毫无计划的盲目测试或者对系统功能的测试。UAT测试的详细测试用例、测试计划、测试策略，应该在项目组内部共同测试通过，测试环境不存在重大的、明显的缺陷的情况下一同讨论通过后开展。笔者曾经经历一个项目，乙方内部管理混乱，为赶进度，在自己内部尚未完全测试通过的情况下就强行召开UAT测试，结果用户一测试系统直接爆各种乱码，到测试第三天就已没有任何关键用户反馈测试结果，所有人士气极其低落，项目组的信誉和权威一败涂地。
UAT测试阶段，接收到每个对方认为是“问题”的反馈都应该无遗漏如实记录下来，未能当场回复的，在测试日例会讨论分析后给于反馈。
测试及上线试运行过程中接收的反馈，切忌不予回复或者迟迟未给于回复。
（六）上线试运行
本节命名为上线“试”运行，而非上线运行。试运行可以视作一个过渡时期，每天结束后及时解决和总结当天的问题。在上线前，上线策略通常需要考虑以下几个方面：
1、直接上线，还是旧流程并行？双方对上线有把握吗、自信吗、准备好了吗？
2、综合项目风险和难度，分步分批上线，还是一次性上线？一个牵涉面广的项目，如果可能，还是分批上线吧，这样刚上线发现的问题可以在影响扩大之前迅速解决掉。一个小问题但是影响面广，那就是大问题甚至是事故了。
3、上线前的培训场次和形式安排。培训应当提前通知到相关的各个部门，培训时要求签到。如果工作程序不到位，上线后用户由于自己的原因出错，把原因归咎于没有得到培训，项目组（特别是甲方）应该如何怼回去呢？
4、上线时的运维支持如何安排。上线时可以设置运维热线，指导用户的使用，记录用户反馈的系统问题。
（七）验收
有的厂商会用到这个概念——阶段验收。项目的验收，并不是在最后的验收报告签字才叫验收，而是在各个阶段对乙方的工作成果认可即是为验收的一部分。各阶段的工作完成到位，最终的项目验收报告是水到渠成的事情。如果项目执行过程中处处敷衍，最后拖到被迫上线，又如何能指望客户能放心的签字呢？
同时，验收并不要求所有的问题都已经完全解决。系统没有重大缺陷，不影响正常使用，仅剩下少量不重要的问题，可以作为项目上线遗留问题，限期解决。后续还有运维服务，项目还有质保金没有支付，乙方公司是有动力去解决的。
（八）运维
在前期的设计和开发过程中，“可维护性”也是一个重要的判断标准。系统主要是解决标准化的、固定的管理需求。标准化意味着具有普遍意义，固定意味着不会经常变化。
在签订项目实施合同的同时，通常会对后续的运维服务框架有初步的沟通。甲方应该想清楚，让乙方运维的是什么内容。举个例子，同样是在系统中新增一家公司，ERP项目很可能是需要新起项目单独实施，报表系统可能只需要在系统中简单设置即可。在项目结束之前就应该考虑清楚，乙方运维什么内容，IT部门维护什么内容，用户部门维护什么内容。
运维人员可能来自项目组，也可能是有专门的运维团队。即便前者，公司人员也会变动，也涉及到运维的移交工作。在正常的公司常规工作中，应该是没有人是不可取代的。项目组应当及时将项目文档整理归档，完备有序的项目文档能有效帮助项目移交。
三、项目管理规范
（一）项目经理负责制
项目经理是整个项目的灵魂人物，对项目进行全局性把控。项目经理对项目的理解、对项目执行的掌控，直接关系项目的执行效果。项目经理应当从始至终集中精力在项目上，原则上双方中途均不得换人，更不允许长期不在岗。因此，从项目前期的沟通到最终验收都不可轻易更换。在施工工程领域，一个典型对乙方项目经理要求的条件通常为：项目经理应当具备***资质，每个月***天坐班生产，非经不可抗力因素未经甲方许可不得更换。
甲乙双方项目经理分别代表双方公司执行项目合同。项目经理制，意味着项目经理是日常项目事务的决策权威，是项目正常推进的决策枢纽。项目经理就是项目的“牛鼻子”，抓住项目经理，才能牵住项目这头蛮牛。项目经理应当树立自己在项目的权威，未经项目经理允许的行为及产出，可以不予认可。组员及专家的意见仅供参考，项目经理认可后才能作为项目意见。
项目经理负责制，还意味着项目组是公司的一个独立的组织存在，与脱离了日常的汇报关系。特别是在甲方，涉及到多个部门时，不论各个部门的领导级别多高，最终均应当以项目经理的意见为准。当然甲方项目经理可以直接认可对方部门的意见，也可以考虑后合理变通或者拒绝。（这也是甲方项目经理面临压力最大的时候之一）
（二）项目会议制
项目会议分为定期会议和不定期会议。通常定期会议是关于项目计划、策略、重点事项等项目管理方向内容，一般不专门针对具体细节。不定期会议主要讨论项目中的具体流程、功能等具体细节。
1、定期会议
定期会议，主要包括里程碑会议、月会、周会或双周会等。会议主要讨论本期项目执行情况（即主要成果）、发现的风险、重大项目争议以及下期计划。项目周会、月会，侧重点在项目计划及执行。有的项目，项目组有时无所事事有时又突击高强度加班，而且项目推进缓慢，很明显项目计划制定与执行有问题。项目计划不是制定后一成不变，而是根据项目实施情况不断调整。
里程碑会议侧重总结，应当尽可能邀请对项目能直接影响的最高领导听取项目组汇报。一方面告诉管理层项目进展顺利，毋庸担忧，另一方面查探管理层对项目的最新态度。
部分人习惯将周会定在周一早上召开，但笔者习惯将周会定于周五上午召开，如果实在有冲突，那么定为周四下午。定于周五早上开的好处有：
（1）今日事今日毕，同理本周事也应当本周毕，避免将工作拖到周末完成。工作日大家辛苦一些，周末就好好休息。
（2）周会的一个重要事项是确定下周工作内容。如果下周有会议，需要提前预约和通知。在笔者前东家，通常到周三，CFO下一周的时间全都已经预约完了。周一定下计划再去预约，如何预约得到？或者周一定下来，周二访谈项目的某BU负责人，结果周会结束后才得知其早已休假或者出差去了又或者对方所在国家是法定节假日，那么项目计划是不是得马上修改？一周的工作日只有五天，下一周的重要的会议和事项，需要提前在上半周就开始筹划，周五下午也算是最后一个修改的时间窗口。
2、不定期会议
召集会议之前，告知参会各方会议主题、会议目标、会议开始时间、预计持续时长以及提前提供会议辅助材料等等以便参会方能提前安排自己的工作计划，是对各参会方的基本尊重，也是提高会议效率的重要手段。工作中，时不时遇到这样的情况：突然接到消息，马上参加一个会议，会议主题未知，参会人员未知，会议预计持续多久未知，一切都未知，这种情况笔者在公司内部和对外都遇到过，非常让人恼火。
主持会议时，注意聚焦会议主题，不可漫无边际发散。会议尽量达成一致共识，但不一定必须以各方一致同意结束，未达成共识也是会议成果。会议纪要应当如实记录会议成果，以及重要的指示意见或反对意见。
（三）书面沟通
及时全面的书面沟通、书面存档，能够在很大程度上避免甲方漫天要价，以及乙方消极怠工以至于最终项目被绑架带病上线。项目实施合同、会议纪要、部分邮件沟通记录、项目报告等等书面材料，都是重要的项目文档，需要整理归档。
网上看到，有应届生抱怨，工作主要是写会议纪要、做记录等，毫无意义。当然，在其他领域，例如党政部门的文字工作，笔者不了解，但笔者认为在项目实施过程中的文字记录工作还是很锻炼人的。一份文档不是记流水账，一次沟通也不是直白口水话，怎么样组织的、措辞是如何选择的，都值得思考。（举个例子，一周中，子公司项目任务完成情况参差不齐，应该如何表扬及批评？）
1、沟通的内容
在每个阶段，乙方应该就完成的阶段性工作成果以书面的形式提交甲方，用书面的形式将本阶段“关门”，后续原则上不应当对前述成果进行变更。在需求调研结束，以需求报告的形式总结客户的需求，意味着项目的需求边界已经限定；项目设计的蓝图，供客户审核，意味着项目实现的方向和内容也进行了限定；系统测试报告，意味着客户已认同测试结果，基本符合蓝图设计、满足需求要求、可以达到项目目标，符合上线条件；系统上线报告，意味着系统上线初始效果良好，无重大偏差；验收报告，意味着项目达到了既定项目目标。
对工作成果的书面确认，既是对项目边界的限定，也是项目共识的体现，更是对甲乙双方的保护。
除了阶段性成果，日常的工作成果，也应该书面记录供各方审阅。项目计划、会议纪要、各种报告、汇报材料等所有材料都应该专门留存归档。
2、沟通的形式
工作中，发现很多人不会适当的使用电子邮件进行沟通，甚至某些几千亿规模的企业集团连统一的电子邮件系统也没有。电子邮件实际上一种非常高效的“正式的书面沟通”方式。
（1）和电话沟通相比，电子邮件有书面记录留存；
（2）和面谈及会议沟通相比，电子邮件不需要预约，不需要单独记录事后确认；
（3）和微信及QQ沟通相比，许多公司并不鼓励员工使用外部IM，不会为员工注册专门的公司账户。微信及QQ都是个人账户，相关权利归属员工个人而非公司所有，法律效力存疑。同时，IM的优势是及时，但并不具备电子邮件便捷的分类、待办等操作功能。
（4）此外，电子邮件不需要立刻反馈，可以同时知会多个对象，这也是上述工具不具备的优点，这在跨部门沟通时非常突出。
根据事项的重要紧急程度，笔者习惯的沟通顺序如下：
（1）重要的关键事项，会邮件将相关材料发送各方，并电话告知其查收，必要的需要召开会议讨论。例如，蓝图。
（2）一般重要的事项，会邮件发送相关材料至相关方，供参考。例如，项目周报。
（3）一般事项，所有文档存在放一块公共文件夹，各方随时自行查阅，不再另行通知。
（4）不重要的事项，电话简单沟通
书面沟通，建议按照金字塔原理。例如，在邮件主题一句话简要写明你的目的（包括时间地点等），正文详细描述，需要长篇大论的请作为附件附上。
（四）争议及变更管理
在工程领域，通常有一套国家公认的施工标准供各方遵守。乙方的工作成果在监理的见证下，每月定量确认。但与工程领域比，咨询项目一个很重要的特点，就是没有明确公认的“标准”可以用于对实施成果的仲裁。也不像一次性交付一套标准化的产品，例如电脑。
如前文所述，明确知道自己想要什么的客户已经是很好的客户了。同时，目前的多数IT咨询公司的顾问培养机制中，咨询顾问通常是技术出身或者一毕业就一直在乙方工作，而能理解客户的管理要求的顾问也并不多见。项目不成功、推进缓慢等，通常是由于双方对一些重要事项的看法不一致。可能确实是双方理解不一致，也可能是多次变更导致延期。项目启动就应该明确争议和变更管理机制，在不能达成共识的情况下如何决策升级。