BI projects are cross-organizational in nature. Managing a business intelligence (BI) project is considerably different and more involved from managing a traditional software development and other types of IT projects. BI project management requires different techniques and methods to succeed due to the melding of wide-ranging business requirements with various software and hardware technologies. In addition, traditional software development projects adhere to a development methodology that logically progresses in a serial manner until completion, while BI projects require an iterative approach that begins in development and continues through implementation as new information requirements of the business users are addressed as the business evolves. BI projects also require the project team to have greater interaction with a broader constituency, ranging from other IT professionals who are responsible for the information systems that capture or create data to business analysts and executives who need to access it. BI project management includes managing daily tasks, reporting status and communicating to the extended project team, steering committee and affected business users. The project management team needs extensive business knowledge, BI expertise, data warehouse architecture background and people management, project management and communications skills. BI projects cover many of an organization’s departments, many different interests and, oftentimes, competing interests. The way to get to good agreements is to understand the difference between your interest and your position. Your position is something that you want. For example, a departmental representative at a BI project planning meeting may say, “I want to be the first to receive this BI report.” That is his position. His interest consists of all the reasons he took that position. It’s desires, fears, the influence of his constituency — everything that led him to take “position x” in the first place.
When new BI project teams are formed, it’s often because there is a business need for information that hasn’t been met by existing legacy teams.
Managing the BI Project
Project management in most organizations is treated as an administrative reporting function. Detailed project planning and hands-on daily project control are often minimized, if not ignored, especially when organizations try to get several BI applications up and running very quickly. In their shortsightedness, organizations forget that extended planning activities often lead to shorter testing and implementation cycles and thus a shorter delivery time—exactly what the business community wants.No BI project gets off the ground without a few “kinks and bends”; delays are common. For example, some products may not have enough capacity; others may not work well in a distributed environment. Switching vendors and products can prove costly in terms of time and money. Vendors often cannot offer the comprehensive solutions that businesses expect because the vendors are still struggling to integrate all the pieces of their BI products. This leaves integration up to the organizations’ information technology (IT) staffs.Many organizations do not adequately plan for these types of delays and setbacks, nor do they test their BI concepts and strategies adequately. Setbacks are inevitable on a project as resource intensive as a BI application—even under the best of circumstances. Planning for setbacks will help management set realistic rollout dates for the project.Describing project management activities in the most simplistic terms, the goal is to answer four basic questions.
- What will be delivered?
- When will it be done?
- How much will it cost?
- Who will do it?
These questions translate, respectively, into the four major project constraints of scope, effort (time), budget, and resources. Before the project manager can create a project plan to address these constraints, he or she must spend some time defining the project to clearly understand the related requirements, risks, constraints, and assumptions. Project planning includes creating a project charter, which defines the project in terms of:
- Goals and objectives
- Scope (the expected project deliverable)
- Risks
- Constraints
- Assumptions
- Change-control procedures
- Issues management procedures
The project charter is the agreement made between the business sponsor and the IT staff for developing the BI application. If any component of the project charter changes, the entire project has to be reevaluated and all project constraints have to be renegotiated.
Posted on June 9th, 2008 by Amit Mehendale
Filed under: Business Intelligence, View Points & Perspective
Most Commented Posts
I believe that today one of the biggest challenges on BI Projects is not related anymore to “IT” products. Big companies are going shopping, acquiring other companies with different cultures and different information sources (IT systems and worksheets!). The success of a BI project is getting more dependant from this company`s ability to define the which KPIs should be delivered, as well as align the concept of each KPIs along its areas and Business Units.