This article originally appeared on the BeyeNETWORK.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
My May and June articles discussed the role of infrastructure with operational business intelligence. This article, the first of a two-part series, will explore the project planning and management issues.
For an operational business intelligence (BI) application, infrastructure is the key to success. However, the best infrastructure in the world won’t deliver the desired results unless the very best planning and management of the project are in place and are practiced.
The purpose of an operational business intelligence environment is to provide cross-organizational business analysis capabilities to all businesspeople. In order to accomplish this, a hands-on project management approach is necessary.
Before starting any project, it is advisable to understand what resources business management plans to commit to the project and to completely understand management’s expectations. Some of the issues to look at are:
1. How much is the business community involved with this project?
- Is there a strong business sponsor? Is there a backup business sponsor?
- Are there stakeholders that need to be communicated with regularly?
- How much time is the business representative committing to this project? Is he or she assigned to this project full-time, or will he or she be available on request?
2. Project Scope and Deliverables
- Has a formal request for a BI project been submitted?
- Is the scope achievable given the schedule and the available resources?
- How well are the requirements stated?
- What deliverables are being requested?
3. Cost-Benefit Analysis
- Has a cost-benefit analysis been performed?
- What is the expected return on investment (ROI)?
- How soon is ROI expected to materialize?
- Have the technical and non-technical infrastructure components been reviewed?
- Are there any gaps in the infrastructure?
- Which infrastructure – technical and non-technical – components will need to be worked on and delivered as part of the BI project?
5. Staffing and Skills
- Have the team members already been identified?
- Do all team members have the skills to perform the responsibilities of their assigned roles?
- Should any training be scheduled before the project kick-off?
- Is the project manager assigned to this project full time? Or does he or she have other administrative responsibilities?
- Who will take over those other responsibilities for the duration of this project?
In most of the organizations, management tries to get several business intelligence applications up and running very quickly. As a result, attention to detailed project planning and hands-on daily project control is often minimized, if not completely ignored. In this shortsightedness, organizations forget that an extended planning activity often leads to shorter testing and implementation cycles. That results in a shorter delivery time in total, which is exactly what the business community desires.
To describe project management activities in the most simplistic terms would be to say that the goal is to answer four basic questions resulting in the four basic constraints as illustrated in Figure 1:
- How much will it cost? (budget)
- What will be delivered? (scope)
- When will it be done? (effort/time)
- Who will be doing it? (resources)
Figure 1: Project Constraints
Before the project manager can create a project plan to address budget, scope, effort and resources, the person must spend some time to clearly understand the requirements, risks, constraints and assumptions for the project. That means each project must be “defined.”
Part of project planning is to create a project charter, which defines the project. The project charter is the agreement between the business and IT for developing the BI application. If any component of the project charter changes, the entire project has to be reevaluated and the entire project charter has to be renegotiated.
The project charter defines the project in terms of the following:
Project Goals and Objectives
The first topic to address when defining a project is goals and objectives. What is the reason for building this BI application? What is the business pain (in hard currency)? What are the strategic business drivers? Are the BI project objectives in line with the strategic business objectives? Or is this someone’s pet project?
Project objectives should be measurable statements, such as: “In order to increase market share by 10% next year, the sales department must have access to month-end sales data as well as pipeline data merged with prospect data within 2 business days after the close of the weekly accounting cycle.” Project objectives must tie to the expected return on investment (ROI). They will have to be measured and reported on to determine if the project was successful or not.
An assumption is anything that is taken for granted; it is a supposition, or a presumption. Assumptions are important to document because a wrong assumption could very quickly turn into a risk. Here is an example of how two assumptions on a project backfired:
Assumption 1: A new database server will be delivered in May (vendor promise – this invariably means end of May), and a new DBMS product will be installed and tested on that server by the end of June (in plenty of time before the project deadline, which is fiscal year-end September 30th).
Assumption 2: Joe Bamberg will be the database administrator (DBA) on the project because he is the only one who has that particular DBMS skill, which is needed for the project. He has already joined the project team.
Problems: On June 20 (one month late), the new server finally arrives, and on July 1, Joe Bamberg quits the company. The new DBMS product does not get installed and tested on the new server until the end of September.
Impact: The project is delayed by three months at a budget overrun of $60,000 (a good portion of which were consulting fees for the high-priced consultant who had to fill in for Joe Bamberg).
Project Scope (Expected Project Deliverables)
It is impossible to create valid estimates for a project without a solid understanding of the scope. Traditionally, scope is measured by the number of functions the system will perform (function point analysis). For business intelligence projects, that is a sure way to underestimate effort, budget and resources. BI applications, in most of the cases, are data-intensive, not function-intensive. Therefore, scope must be measured by the number ofdata elements that have to be extracted from the source systems, transformed and cleansed, and loaded into the BI target databases. The main reason for concentrating on data rather than functions is because source data analysis and data preparation will take much longer than data access and data analysis (reports and queries). One may say the typical 80/20 rule applies: 80% effort for data and 20% effort for functionality.
Every project is subject to some risks – risks are unavoidable. Depending on the likelihood that the risks will materialize and on the impact they would have on the project, the project schedule as well as the project deliverables could be severely affected. Therefore, the risk assessment performed during the business case assessment step must be reviewed and expanded, if necessary. Triggers must be identified for each risk and a mitigation plan as well as a contingency plan must be incorporated into the project plan.
- Triggers – are situations that signal a potential, possibly imminent materialization of a risk. For example, management is reviewing the budget for the project for no apparent reason – indicating possible risk of losing management support for the business intelligence project.
- Mitigation plan – specifies what actions can be taken to mitigate or prevent the risk from materializing. For example, solicit support from the business sponsor and promote the business intelligence initiative to other key executives in the organization to keep management’s interest in the BI project. Should the project run into trouble, the risk of having it cancelled is mitigated or prevented.
- Contingency plan – specifies alternatives in case the risk does materialize. For example, if management support for the BI project is lost due to a long project schedule, plan to shorten the release cycles by delivering a smaller scope sooner. If management support is lost due to the sponsor leaving the organization, have an alternate sponsor ready to become the champion for the business intelligence project. (It is easier said than done!)
Some common risks are:
- Lack of management commitment
- Lost sponsor
- Lack of business participation
- Imposed unrealistic schedule
- Unrealistic scope of the schedule
- Unrealistic expectations
- Unrealistic budget
- Untrained or unavailable staff
- Constantly changing business priorities
- Poorly managed project
- Limited scalability
Project Constraints (Any Known Considerations)
All projects are subject to the same project constraints: budget, scope, effort (time) and resources (capable and available people). In reality, there is a fifth constraint: quality. Although quality is a measure of how well the deliverables meet the requirements, it can also be considered a constraint that must be balanced with the other four constraints discussed.
Change Control Procedures
One reason traditional waterfall methodologies became so popular was because the signed-off phased development approach was an attempt to curb scope creep. The mental model was change is bad – businesspeople must be held to their decisions. Because business intelligence applications are supposed to be catalysts for improved decision making, the mental model must change to change is good – businesspeople should refine and improve their decisions. However, uncontrolled change can still kill a project.
The solution is to manage the changes. Many organizations track their change requests by logging the date of the change request, the name of the requestor, the desired change, to whom it was assigned, and when it was implemented. That is good, but tracking changes is not the same thing as managing them.
To manage a change, it is necessary to start with a baseline. The baseline is the agreement between the business and IT, as documented in the project charter. Every change request, once logged, undergoes an impact analysis and a cost-benefit analysis to determine the effects of the change on the project. Changes, unless they are minute, always impact the other constraints of budget, effort (time), scope and quality. Some changes also impact the other two constraints of budget and resources. When one constraint changes, the remaining constraints will have to be renegotiated. Depending on how critical the change request is, the business representative has to decide whether to:
- Cut back from the current scope by eliminating some of the originally requested data and functionality
- Extend the deadline
- Declare the requested change as unfeasible at the present time and postpone it
- Incorporate the requested change in the next release
- Eliminate complicated transformations, edit checking and testing, which will impact the quality and, as a result, support of the project.
Frequently project teams are put under undue pressure to incorporate scope changes without slipping the schedule or compromising on quality.
Is it rational to request a significant scope change to a carefully deliberated and agreed-upon project plan without adjusting any of the other constraints? Of course not! The reason why it is not rational is because the business representative, the project manager and the core team members who developed the plan together, believed the plan to be doable under the agreed-upon constraints. Now the scope constraint has changed; therefore, the plan is no longer doable without changing some other constraints – namely, effort (time), budget, resources and quality – to absorb the impact of the scope change.
Issues Management Procedures
Issues, which always come up during projects, may be business related or be of a technical nature. Similar to change requests, issues must be tracked and managed. An example of an issue log is shown in Table 1.
Table 1: Issue Log
Some issues are minor and can be resolved without impact on the project. Other issues can turn into risks or change requests and have to be dealt with accordingly.
Part 2 of this series will address some of the basic challenges of project planning for an operational business intelligence environment.
(Source: Moss, Larissa and Atre, Shaku. Business Intelligence Roadmap – The Complete Project Lifecycle for Decision-Support Applications, Addison Wesley Professional, 2003.)
Author’s Note: The Business Intelligence Roadmap includes a set of all major activities and tasks that are appropriate for BI projects. Not every BI project will have to perform every single activity in every step. To receive a complimentary copy of the Business Intelligence Navigator, designed to help chart the business intelligence journey, please visithttp://www.atre.com/bi_navigator/navigator.html.