This article originally appeared on the BeyeNETWORK.
This is the second part of a two-part series discussing project and management.Part 1 of this series discussed management expectations, project scope, risks and change control procedures. This article provides suggested approaches for project and project management.
Project is not a one-time activity. Since a project is based on estimates, which are frequently no more than best guesses, project plans must be adjusted constantly. The number one telltale sign that a project is not being managed is a static project plan where estimates and milestones have never changed from the day they were developed.
Activities and Tasks
Operational business intelligence (OBI) projects are composed of many activities, with a long checklist of tasks. Regardless of the project manager’s experience, it is impossible for any person to remember all the tasks that need to be performed on an OBI project. At a minimum, the project manager must rely on some existing comprehensive list of the most necessary activities. Naturally, not all activities have to be performed on every project. Not even every step has to be performed on every project. The project manager selects the minimum number of steps and activities needed to produce an acceptable deliverable under the imposed constraints.
The development approach for an operational business intelligence application is not linear. It is a much more dynamic approach to application development. It often looks like and feels like a prototype – but it is not a prototype. The same rigor and discipline applied under a traditional methodology must be applied to OBI projects in terms of controlling scope, mitigating risks and time-boxing weekly activities. However, constant rework must be expected during the development cycle and should be built into the project . For example: analysis activities can show up as early as and as late as testing, and so can design or activities. These activities in any order keep any project manager on his or her toes!
The project must reflect this dynamic nature of application development. Since changes and setbacks are to be expected, certain “completed activities” will have to be revisited and reworked. The easiest way to for these internal iterations is to use the concept of “looping” or “refactoring” by dividing the project into multiple small sub-projects, each with a deliverable, albeit not completed. Then, revisit and revise each deliverable adding more data and more functionality until the entire operational business intelligence application is completed with the desired deliverable. This iterative refinement approach is what gives the project development effort the feeling of prototyping.
Once the activities and tasks have been selected for the project and the project has been organized into subprojects, the base estimates are derived using one of three methods:
Historical, based on learned patterns (e.g., how long it took on the last project)
Intuitive, based on one’s intuition and experience (“gut” estimating)
Formula-based, based on the average of possibilities, as shown in Figure 1
Figure 1: Formula-Based Estimating
Effort estimates cannot be completed until the activities and tasks are assigned to available resources because their skills and subject-matter expertise, as well as environmental factors affecting each team member, have to be taken into consideration.
Skills – The ability to perform specific tasks: Have they done this type of work before?
Subject-Matter Expertise – The possession of facts or concepts about a specific subject matter: Are they experts in this business ?
Environmental Factors – Administrative and non-work related activities. Some examples are listed in the table shown in Figure 2.
Figure 2: Environmental Factors
All activities and tasks do not have to be performed serially. Many activities and tasks can be performed in parallel as long as there is sufficient staff. The step in determining what tasks can be performed in parallel is to identify task dependencies and develop the critical path. Most project tools support the four types of task dependencies, as shown in Figure 3.
Figure 3: Task Dependencies
- Finish to Start – indicates that Task 2 cannot start until Task 1 finishes.
- Start to Start – indicates that Task 2 can start at the same time as Task 1.
- Finish to Finish – indicates that Task 2 cannot finish until Task 1 finishes.
- Start to Finish – indicates that Task 2 cannot finish until Task 1 starts.
A shortage of staff can quickly reverse the benefits of having few task dependencies. For example, tasks that could have been performed in parallel, but cannot be assigned to multiple staff members because of a staff shortage, must revert to being executed serially. Figure 4 shows how four tasks could be accomplished in 10 days with adequate staffing; Figure 5 shows that it will take 14 days to complete them because only one person could be assigned to do all tasks. Note that in Figure 5, the task of Compile Findings could be reduced by one day because there is no longer a need for two analysts to collaborate.
Figure 4: Elapsed Days with Task Dependencies
Figure 5: Elapsed Days with Resource Dependencies
Critical Path Method (CPM)
Once the task dependencies are identified and the resources are leveled, the critical path will show task duration, indicating any lag time for tasks not on the critical path, as illustrated in Figure 6. This will give the project manager the visibility he or she needs to reassign resources or to renegotiate the constraints of the project.
Figure 6: Critical Path Method (CPM)
Creating a useful project requires some effort, but maintaining the project (adjusting it) is not as labor-intensive as it was prior to the availability of project management tools. Becoming proficient on a sophisticated project management tool will take some time, and a solid understanding of project management principles is required.
Once the components (e.g., tasks, estimates, resources, dependencies) have been keyed into the tool, any adjustments subsequently made to the components automatically cascade through the entire project , updating all charts and reports. Although the results must still be reviewed and validated, an experienced project manager who is skilled on the project management tool does not need to become a slave to the tool or to the project activities.
The project activities do not need to be performed linearly. Figure 7 indicates which activities can be performed concurrently.
Figure 7: Project Activities
Determine project delivery requirements: The objectives for the project and some high-level requirements for the proposed scope may have already been prepared during the business case assessment step. However, most likely these are not of sufficient detail to start the process. As part of the scope definition, the following requirements will have to be reviewed and revised: data, functionality (reports and queries) and infrastructure (technical and non-technical).
Determine condition of source files and databases: The project schedule cannot be completed and a delivery date cannot be committed to without a good understanding of the condition of the source files and databases. Some time must be taken to review the data content of these operational files and databases. Although detailed source data analysis will be performed during the data analysis step, enough information must be gleaned during to make an educated guess about the necessary effort for data cleansing.
Determine or revise cost estimates: Detailed cost estimates must be prepared to include hardware and network costs as well as purchase price and annual maintenance fees for tools. In addition, the costs for contractors, consultants and training have to be ascertained. A more indirect cost is associated with the learning curve for the business staff and IT. It should be factored into the cost estimates as well as the time estimates.
Revise the risk assessment: A risk assessment must be performed, or reviewed and revised if one was performed during the business case assessment step. Risks should be ranked on a scale of 1 to 5 according to the severity of their impact on the OBI project, with 1 being low impact and 5 being high impact. The likelihood of the risks materializing should also be indicated on a scale of 1 to 5, with 1 being “will probably not happen” and 5 being “you can almost count on it.”
Identify critical success factors: A critical success factor is a condition that must exist for the project to have a high chance for success. Some common critical success factors are: a proactive and very supportive business sponsor, full-time involvement of a business representative, realistic budgets and schedules, realistic expectations and a core team with the right skill set.
Prepare the project charter: The project charter is similar to a scope agreement, a document of understanding, or a statement of work. However, the project charter is much more detailed than the usual 3- to 4-page general overview of the project that contains only a brief description of resources, cost and schedule. The project charter is 20- to 30-page document developed by the core team, which includes the business representative. The project charter and the project are presented to the business sponsor for approval.
Create high-level project : Project plans are usually presented in the form of a Gantt chart showing activities, tasks, resources, dependencies, and effort. Some project managers also create Pert charts, which show the graphic representation of the critical path method on the calendar.
Kick off the project: Once the project is planned, the resources are assigned and the training is scheduled, the project is ready to be kicked off. This is usually accomplished with an orientation meeting for the entire team – the core team members as well as the team members. Project kick-off should also include setting up communication channels (e.g., newsletters, e-mails, Web pages) to the rest of the organization to keep stakeholders and interested parties up to date on the progress of the project.
The following deliverables result from these activities:
Project Charter: This document represents the agreement between IT and the business about the definition, scope, constraints and schedule of the OBI project. It also serves as the baseline for all change requests. A project charter contains the following sections:
Goals and objectives (both strategic and OBI project specific)
Statement of the business problem
Proposed OBI solution
Results from cost-benefit analysis
Results from infrastructure gap analysis (technical and non-technical)
Functional project deliverables (reports, queries, portal)
Historical requirements (how many years of history to store)
Subject to be delivered
Entities (objects), significant attributes, relationships (high-level, or conceptual, logical data model)
Items not in scope (originally requested but subsequently excluded from scope)
Condition of source files and databases
Availability and security requirements
Access tool requirements
Roles and responsibilities
Team structure for core team and team members
Critical success factors
Project : A project may contain multiple graphs, such as critical path method (CPM) chart, Pert chart, or Gantt chart, detailing task estimates, task dependencies, and resource dependencies. Most project tools can also produce additional tabular reports on resources and schedule. The chance of success is directly proportional to the efforts expended in the project and management.
(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.