谈到接到一个项目，我们必须了解到这个客户的特点。在我们过往的一些项目中，出现比较大的问题是在于客户对于你和你的公司的认可度很重要。
在国企来说，很多项目都会变成烂尾项目，一个重要的原因是在业务谈项目的时候如果缺乏一个顾问角色的人在场项目就会变成一个扯皮的项目。往往客户在初期来说项目需求往往很简单，结果会随着项目的跟进的时间越长，客户的需求就会越来越多。往往结果就超过了客户和业务定义的项目的范围。
就项目范围来说，如果在项目开始前没有定义清楚的话，对于后面项目结果往往是很灾难性的。我在协助一个朋友做过一个项目中调研，他们开始协助客户在初期做了测试，但是没有就范围进行明确的界定，他们开始认为项目不就是安装Exchange 而已，没有注意客户的具体需求。结果呢，客户提出的要求很过分：他要求将OUTLOOK 客户端设计成HOTMAIL的界面，我们知道这个需求能实现么？可以！但是会耗费过多的时间和人力才能达到这个目的。
在很多做的很差却没有烂尾的项目中，我们都发现一个特点，就是甲方接触项目的这个人要么就是在接受甲方的好处并且能够搞定内部人员，但是在很多时候IT部门处于公司的弱势地位，却接受了甲方提供的好处，结果又没有办法搞定其他用户的特殊需求，这样来说，就已经将乙方的地位降为一个尴尬的地位了。
因此在很多时候，我们的售前工程师要有一定的项目管理知识，也只有这样，我们才能了解我们目前项目的风险。同时能够界定出项目的边界，避免后期项目出现潜在需求浮现而出现烂尾的情况。
一般来说，我们的项目整个阶段过程如下：
一般来说，做出相关的建议规划书是基于售前支持到达现场后，依据客户需求定义出来出来后给出的基于产品符合企业本身的一个规划建议，一般来说，比较互动的客户会根据我们给出的第一版规划书再提出企业内具体的需求，相对来说，在这个阶段，客户的需求越具体越好。这样我们就为后期的制定SOW做出相应的准备。
因此来说建议规划书给出是我们整个项目的规划阶段，我们后期的范围能否确定就在于规划书是否能够写的很OK，但是往往目前很多基于客户架构的规划书都写的非常烂，客户往往都看不懂写的是什么。
真正优秀的规划书基本上都是客户的实际情况来写的，而且大部分的规划书往往在规划书就将权利和责任定义清楚了，这多少有点让人觉得很奇怪的感觉。我列一个基于桂花树的目录给大家参考一下：
不罗嗦，不写废话。依据客户定义的问题点来提出我们实际的建议，这个是我们期望在建议规划书中有一个很明确的提供。写完了规划书我们就进入到下一个阶段-POC阶段。
基本上我们在给客户的建议规划书之后，我们基本上要在我们的环境中搭建一套POC的环境来完成我们计划的测试，如果服务器数量不够，建议做个简易的POC计划，严格来说，如果客户希望做4台服务器，两台做DAG，两台做DNS Robin，我们不能只做出安装一台机器的POC，这和我们的预期出入太大，因此尽量的与实际环境契合起来。否则失去了POC的意义。
做完了POC，验证了整个POC 过程之后。我们基本上要和客户进入到合同阶段，合同阶段上我们有一个重要的文档，就是我们所说的SOW文档，SOW 文档与规划书不同，在于建议规划书的建立不会产生任何的法律效率，而SOW工作项目说明说则意味着合同双方已经对工作进度及合同达成了协议，进入到正式的项目实施阶段。同时SOW的工作说明书里面我们也可以看到我们项目的合同验收标准，项目成员及时间分配。和工作范围界定，因此在项目过程中SOW是一个重要的可以依靠的文档，大部分企业出现纠纷之后我们可以依据SOW 来分析对方是否履行了合同规定。项目团队成员是否符合了甲方对于整体项目的资质需求。
在做SOW的同时我们需要对项目的一个周期做一个预估，大概需要多少时间来完成相应的相应的时间来完成这个项目，最好的工具是什么呢？当然是Project.下面写一个范例：
当你预期一个项目估计就是很简单的几步，结果发现竟然会有140多步，因此采用思维导图同时利用Project 文件进行详细的规划，思维导图是细化步骤的一个好工具，而Project 是项目规划的辅助工具，利用好相关的工具，你会发现一切都不是难题！
当完成项目预期后，我们进入到实际执行阶段，而实际执行阶段介入的人包括项目经理-执行团队成员-项目协调人，三个角色的人选必须协作才能达到将项目做完做好。在很多时候项目的协调人是销售，因为在某种程度上项目经理和客户关系不如销售。所以销售这个时候绝对不能独善其身，作为项目经理和客户之间的协调中间人角色。
做项目的时候，执行人的角色很重要，执行人如果有太多的想法或者不按照项目经理或者主管执行相应的操作执行，结果就会导致项目越走越偏，所以项目的执行人也必须有一定的项目执行经理及和项目经理建立默认的回报制度。 只有项目的成员通力合作，我想，项目跑偏是迟早的事情了。
在项目中会有一个阶段，是项目的阶段性完成的测试，比如LOTUS 迁移用户后，将邮件迁移后是否能够正常收发邮件？这个测试过程就必须建立相应的测试用例，迁移后是否能够正常的用MAPI收发，用手机收发、用外网发送这些严格来说都是一些测试用例。比较建议的测试人员与执行人本人不同，否则容易造成项目的功能遗漏。
最后是项目收尾过程，项目收尾过程必须依靠我们初七编写的SOW作为依靠来进行验收的一个确定性文件。如果前期SOW没有写的很详细，或者范围确定的很不明确，这个时候如果你们项目本身做的有问题，客户会进行刁难的话，你项目可能很难进行收尾。
以下为我对项目的一点灼见，希望大家能够一起讨论！