目前BIDW项目纷纷上马，但所谓外行看热闹，内行看门道。失败的，或者说客户不满意的项目实在不少。总体说来有两点表现：一是未能按时完工；二是数据质量很差，或者不少功能未能满足客户需求。

从乙方来看，潜在风险就是项目牵头的管理者DWBI资历不够，而我们的有些BI公司们往往更看重IT经验，而不是专业经验。二是公司自己人力资源的安排和与客户的沟通。

那么我想说几点总体规则：

1. 领头者如果只是IT经验多，面向一个比较综合的项目，比如EDW或者多个数据集市的项目，那么项目里必须配备资深DWBI技术人员，同时技术上一定要真求DWBI资深人员。

2. 项目需求分析和设计，一定要切合实际地制定计划，否则到时延期就会是自己的原因，对困难和风险的估计一定得充足。对于客户总体需求都在经常变化的情况，唯一的希望就是要规定好项目范围以及服务范围，如果变化又将如何如何。

3. 用文档和规则管理团队，这样的团队才能更有凝聚力、说服力和可操作性，才能避免有的人工作多，有的人工作闲，还能避免走一个人后项目就没人接手了。我想，设计开发文档、Data Model、ETL Mapping、测试文档甚至会议纪要，这些很多公司的团队都觉得是小事，没有在意，所以除了写文档，作为项目负责人一定要浏览几乎所有文档，这样才能保证文档质量，也才能保证项目质量。

4. 还是老规则，用人勿疑，疑人勿用。这点说起来容易，其实很多人做不到的。我想每个项目的人员配置都不会太过充裕的，如果你对别人不放心，就会造成有重复工作产生，同时也会大大减低凝聚力。如果真的不能胜任，管理者可以换人，而不是疑人而不用或者少用。我在所管理的项目中始终坚持这个原则，而实际中有的却不是，结果就是：重复劳动，信息不一致，管理难度大

5. 项目最终要拿技术说话。如果管理者不够懂技术，而强制按照自己的想法去做，那么后果可想而知的。但作为技术人员，你想说服管理者唯一的法宝就是拿事实说话。比如我碰到一个客户的PM，说要做一个大CUBE，就那么几个事实表和10多个维表直接去做。那么我就用数据集市理论从头到尾描述下，做成星型模型的优点等等。虽然多费些口舌，那也没办法，很多人做DWBI确实连基本的都不懂也做管理，这就是前面说到的，人家IT经验多。

6. 项目快上线的时候，一定要注意实际情况，不能花太多时间放在改善某些代码上。比如一个项目里，有个印度人快上线了，他还忙于改善某些代码上，我就说既然之前是按照规范开发的，现在优先考虑的应该是如何把剩下的事情做完，而不是去优化。