Effective Project Methodology = Successful Business Intelligence Projects

By Peter Keers
  Tuesday, September 23, 2008

Business Intelligence (BI) projects are notoriously difficult to complete on time and on budget. Like all projects, project overruns are caused by risks that are not properly mitigated. Why are there so many more risks inherent in a BI project? There are the typical project risks such as resource constraints and unrealistic scheduling. BI projects also suffer from lack of clarity about data at the outset of a project.

The only BI projects where this data risk is reduced (not eliminated) is when the source data has been used for a previous project. In these cases the development team is more aware of the data issues.

Nevertheless, the best way to mitigate data risks in a BI project is to execute an effective project process methodology. The six phase process used by OnApproach have proven effective in implementing BI projects to deliver the expected results on time and on budget. The phases are treated as “gates”, each of which must be completed before a subsequent gate can officially begin.

The Six Phases Are:

1. Discovery
2. Requirements
3. Design
4. Development
5. Deployment
6. Support and Knowledge Transfer

Each phase his its own:

Objectives
What is the intent of the phase?

Activities
What specific actions are performed to meet the objectives?

Artifacts
Artifacts are documentation used in that phase. These documents capture theessential information output of each activity. Artifacts from one phase are typically expanded and enhanced in subsequent phases. All artifacts should be stored in a location that all stakeholders can access at any time. However, permissions to edit the documentation needs to be tightly controlled. Two key artifacts that are commonly used in a BI project are as follows:

1. Business Requirement Document (BRD)
A summary of the business requirements; often referred to as a Scope-Of-Work document.

2. Technical Requirements Document (TRD)
A summary of the technical requirements; it addresses items such as cardinality, schema design etc...

Phase Milestones
An event that signifies the “gate” of the phase is completed and the project can move forward to the next phase. This project process will appear familiar to many experienced project practitioners. The crucial difference is that it is “tuned” to particular nuances of BI projects.

The Phases:

1. Discovery

A notable difference from conventional project processes is the Discovery phase. Many projects launch into requirements gathering once the project charter and scope have been approved. For BI projects, the Discovery phase is the first iteration of requirements gathering. The results of the requirements gathering activities will be expanded and enhanced in the Requirements phase.

Successful BI projects are naturally iterative, particularly when it comes to data. Thoroughly understanding the data in the project is essential. Comprehensive data knowledge by the development team is the number one success factor for  ompleting the project as intended.

2. Requirements
Solid requirements gathering is the heart of meeting project expectations. The requirements are simply the detailed deliverables for the project. The Requirements phase is not substantially different between a BI project and a conventional project except that it is iterative by design. These iterations help mitigate the risk of missing the desired BI deliverables as outlined initially in the Discovery phase version of the BRD and TRD.

3. Design
The Design phase is the blueprint of how the data in source and in existing data warehouse structures will be used to produce the desired result as spelled out in the BRD and TRD. The objective of this phase is to design the architecture and underlying processes for the project; success is dependent on the accuracy and
thoroughness of the preceding stages. All activities in this phase are aimed at creating comprehensive, clear, and accurate artifacts that can be used in the development phase. Peer review is especially important here to prevent the design from proceeding down “blind alleys” that will cause delays due to redesign in the Development phase.

4. Development
In an ideal scenario, the Development phase should progress smoothly based in the design artifacts. However, even the best design fails to uncover every issue, particularly with regard to data. The artifacts from the Design phase will typically be modified as these issues arise. The objective is, however, that these changes be minimal so the project stays on schedule. The objective of this phase is to complete the ETL and report development according to the design such that users will test and approve the final outcome. The efficient progress of this phase will be a reflection of how well the prior stages were completed. Another issue is, however, the performance of development tools and infrastructure. Even the best designed architecture can be difficult to implement if the ETL and/or report design tools are not working at maximum efficiency.

The Development artifacts include those from the Design phase simply to allow for changes (hopefully minimal). The most important new document, however, is the User Acceptance sign off. This is the formal acknowledgement that what was promised was delivered. Final signoff on deliverables is the reward of an effective project process. However, the work is not done until the finished product is in the hands of the customer.

5. Deployment
Deployment involves putting the finished product into production. Close planning and coordination with the organization’s infrastructure team is critical to completing this phase successfully. The objective of this phase is simple: roll out the new system and train the users. Individuals involved only peripherally up to this point now take center stage. The activities of infrastructure personnel and trainers must be coordinated. Also, unexpected differences between the development and production environments sometime crop up so contingency planning for such risks is important. Successful completed migration is signified by approval that users are effectively using the finished product to meet the expected business objectives.

6. Support and Knowledge Transfer
Support and Knowledge Transfer truly closes the project. Users should be gaining the value added with their new reporting capabilities. This phase is to tie up all the loose ends to ensure the new project is completely integrated as a part of normal business processes. The objective of this phase is to ensure the organization possesses and understands the complete documentation of the project such that it can be supported as a part of normal business operations. The development team ends its activities once it makes sure all the appropriate people in the organization have knowledge about how the new processes work and where all documentation is stored.

Finally, a Lessons Learned meeting of key stakeholders is a best practice that will ensure that information about what worked well and what could have been done better is carried forward to benefit future projects. The project is done when the development team moves on knowing the output of the project is working as expected and fully supported as a standard business process.