IT项目的失败率在商业环境中一直是偏高的。在失败的案例里，有的是因为超过预算，超过时间，有些是因为用户要求的变化，或用户要求的不切实际。BI作为IT的一个分支，自然也遇到了相似的问题。此文总结了五个需要关注的方面。通过对这五个方面的管理，BI项目可以有效的规避很多常见的困难，降低项目失败的几率。
项目范畴制定和管理 （Scope Development And Management）
很多人会自然地把这个步骤理解为用户需求的收集和制定。其实用户需求只是这个过程中的一个手段和结果。不管是自主开发，还是集成商为商业用户开放的项目，最终目的都是为用户解决工作中的问题，同时提高和改进工作的效果。
而技术人员最常犯的错误，是把用户当成软件设计专家。比如在BI项目里，技术人员往往会问用户，你们需要什么样的报表，什么格式，数据在哪里。而用户就拿出一叠纸面的报表说，就把这些弄到电脑上去吧。本来意在提高商业效率的BI项目，就变成了一个硬生生把纸面文件通过软件重新实现的低效率工作。
所以项目的范畴制定，不能只限于直接用户能够看到的。作为信息处理的专业人士，我们必须首先要了解用户的商业需求。现在在信息应用上遇到什么问题？决策者有没有必要的信息和工具？具体操作人员有没有能力最有效地进行他们的工作？所生成的信息是不是足够相关人员解决问题？用户是否可以主动地分析和发现问题及最佳方案？
对商业问题的解决应该是BI项目范畴的出发点。但即使在用户需求已经确定之后，对项目范畴的管理也是一个需要一直进行的工作。只有在一个明确的指导之下，才能把整个项目的工作和用户的需求完美地结合起来。
设立符合现实的预期（Set Realistic BI Expectations）
BI项目往往是一个涉及很广的工作。从数据的收集，清理，存储，到数据的计算，呈现，分析，和信息的发布和监控。根据企业不同的现状，BI的实现往往需要分成几个阶段来实现。假设一个企业还没有建立起一套相关的架构，一个BI项目就必须首先解决数据收集和存储，建立数据仓库。在数据得到了保障之后，再进行报表设计，Dashboard，及数据分析等工作。
在一些新引进BI概念的企业里，用户往往会产生一些过度乐观的想法。常常会把目标定得很高。这样不仅会对项目的预算和时间造成影响，在把范围扩大太多后，也常常不能有效地计划和利用人员和资源。
近年来敏捷（Agile）BI的概念开始被大家接受。这里的Agile和软件开发是同一个概念。但应用到BI领域，就包含了一些自己的概念。比如对数据仓库的必要与否，数据清理的方式等等，都有一些不同的理念。这些我们在下一个章节仔细描述。
了解架构和不同的技术选择（Understanding Architecture And Associated Options）
BI作为IT的一个分支，技术上的考虑也是一个很重要的方面。在这里我们讨论几个对项目成败影响最大的几个技术层面。
BI极少是一个独立的系统。首先，作为一个数据处理和信息呈现工具，任何BI的实现都是建立在其它系统的基础之上的。在计划一个BI项目时，我们必须对现有的软件架构有一个十分完整的理解。什么样的产品可以最好的嵌入到现有的架构里？什么接口可以最容易和高效地提取数据？BI工具是否提供了足够的集成功能？
在确定了架构的选择之后，第一个需要面临的是对数据仓库的选择和设计。数据的整合，清理，及存取是BI项目成功与否的决定性因素。传统上BI的最佳模式往往是建立在一个高度集中的大型数据仓库基础上的。在Agile BI的理念影响下，近年来也出现了一些其它的解