This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning the BI Project
Project planning is not a one-time activity. Since a project plan 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 on which estimates and milestones have never changed from the day they were first developed.
Here is the sequence of activities for preparing a project plan.
Create a work breakdown structure listing activities, tasks, and subtasks.
Estimate the effort hours for these activities, tasks, and subtasks.
Assign resources to the activities, tasks, and subtasks.
Determine the task dependencies.
Determine the resource dependencies.
Determine the critical path based on the dependencies.
Create the detailed project plan.
Activities and Tasks
BI projects are composed of many activities, each with a long checklist of tasks. Regardless of how experienced the project manager is, it is impossible for any person to remember all the tasks that need to be performed on a BI 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.
Table 3.3: Issues Log
|
Issue No. |
Issue Date |
Issue Description |
Assigned To |
Action Taken |
Action Date |
Resolution |
Closed Date |
|
001 |
7/23/2003 |
Delay of server installation expected. Problem with supplier. Impact on project deadline could be one month or more. |
Bill |
Met with Ron Leard from tech. support to discuss alternatives. He may be able to switch to another supplier. Follow-up in one week. |
7/24/2003 |
Switched suppliers. Delay to the project schedule: only three weeks. Delay accepted by Robert Black (sponsor). |
8/21/2003 |
|
|
|
|
|
Received call from Ron Leard. He will be able to get a server from another supplier. Delivery date is in one week. |
7/31/2003 |
|
|
|
|
|
|
|
Called Ron Leard. Server is installed and being tested. Expected to be available next week. |
8/14/2003 |
|
|
|
|
|
|
|
Received call from Ron Leard. Server is available. |
8/21/2003 |
|
|
The development approach in Business Intelligence Roadmap is neither as linear nor as rigorous as that followed in traditional methodologies. It is a much more dynamic approach to application development. When using our development approach, it may often look and feel like you are working on a prototype—but it is not a prototype. The same discipline applied under a traditional methodology must be applied to BI projects in terms of controlling scope, mitigating risks, and time-boxing weekly activities. (Time-boxing refers to planning, assigning, and managing activities on a detailed level in weekly increments.) Despite the discipline, you must expect constant rework during the development cycle and build time for it into the project plan. For example, analysis activities can show up on your project plan as early as Step 3, Project Planning, and as late as Step 12, Application Development. Or you may want to plan another short iteration through database design activities during Step 11: Extract/Transform/Load Development.
The project plan 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 project plan should anticipate that and reflect it on the schedule. The easiest way to plan for these internal iterations is to use the concept of "looping" or "refactoring" by dividing the project into multiple small subprojects, each with a deliverable, albeit not completed. Then revisit and revise each deliverable, adding more data and more functionality until the entire BI application is completed with the desired deliverable. This iterative refinement approach gives the project development effort the feeling of prototyping.
Estimating Techniques
Once you have selected the activities and tasks for the project and organized the project into subprojects, you can derive the base estimates by using one of three methods:
Historical, based on learned patterns (how long it took on the last project)
Intuitive, based on intuition and experience ("gut" estimating)
Formulaic, based on the average of possibilities (Figure 3.2)
Figure
3.2: Formula-Based Estimating
)
Figure
3.2:Estimating BI project activities is much more difficult than estimating traditional projects because no two BI projects are alike. For example, you may use a new tool, work with new team members, or have no experience with a new design method. All three estimating techniques listed above expect you to relate to some prior project experience.
The historical estimating technique expects you to have statistics on how long similar projects took in the past—but you may not have had a similar project before.
The intuitive estimating technique expects you to predict, or guess, based on prior experience how long it will take to complete a similar activity—but you may have never performed a similar activity.
The formula-based estimating technique expects you to know the longest time it may take to complete an activity, the shortest time, and the most probable time—but you would not know what the longest, shortest, and most probable times for an activity could be if you had never performed that activity before.
In all those cases, it is best to consult with other people (in-house staff or outside consultants) who have already developed a similar BI application because your own uneducated guesses may be gross underestimates. This also demonstrates how important it is to track actual time on BI projects. You will need that information for estimating your next BI project.
Resource Assignment
Effort estimates cannot be completed until the activities and tasks are assigned because the estimates must take into consideration each team member's skills and subject matter expertise as well as the environmental factors that affect him or her.
Skills—the ability to perform specific tasks. Has the team member done this type of work before?
Table 3.4: Environmental Factors That Can Affect Team Members' Availability
|
Administrative Factors |
Non-Work-Related Factors |
|
Lack of computer access |
Vacation |
|
Time required to troubleshoot other systems |
Illness |
|
Meetings |
Jury duty |
|
E-mails and in-baskets |
Personal time off |
|
Training seminars |
Medical appointments |
|
|
Religious holidays |
Subject matter expertise—the possession of facts or concepts about a specific subject matter. Is the team member an expert in this business area?
Environmental factors—administrative and non-work-related activities. Table 3.4 lists some examples.
Task Dependencies
Not all activities and tasks have to be performed serially—many can be performed in parallel as long as there is sufficient staff. The first step in determining which tasks can be performed in parallel is to identify task dependencies and develop the critical path. Most project-planning tools support the four types of task dependencies (Figure 3.3). Finish to Start and Start to Start are the most common task dependencies; Start to Finish is the most infrequent.
)
Figure
3.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.
The more tasks that can be performed simultaneously, the faster the project will get done. To take advantage of task dependencies, you need the right number of resources with the right skills at the right time.
Resource Dependencies
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 in sequence. Figure 3.4 shows how four tasks can be accomplished in 10 days with adequate staffing; Figure 3.5 shows that it will take 14 days to complete the same tasks if only one person is available to work on them. (Note that in Figure 3.5 the time required to compile the findings is reduced by one day because there is no longer a need for two analysts to collaborate.)
)
Figure
3.4: Elapsed Days When Two People Can Work on the Tasks
)
Figure
3.5: Elapsed Days When Only One Person Is Available
Critical Path Method
Once you have identified the task dependencies and leveled the resources (that is, assigned the tasks and adjusted the dependencies for the available resources), use the critical path method (CPM) to outline task duration, indicating any lag time for tasks not on the critical path (Figure 3.6). This provides the visibility needed to reassign resources or to renegotiate project constraints.
)
Figure
3.6: Critical Path Method
In this example, the task "Identify resources available" can be performed in parallel with the tasks "Analyze cost-benefit of new project" and "Determine critical success factors." Since the task "Identify resources available" is estimated to take 4 days, and the other two tasks combined are estimated to take only 3 days, the task "Identify resources available" is on the critical path. If this task were to take 5 days to complete instead of 4, it would delay the milestone "Project approval" by one day. However, if either of the other two tasks were delayed by one day, it would not affect the milestone "Project approval."
Project Schedules
Once you have determined all the tasks, resources, dependencies, and estimates, you can schedule the project on the calendar. The most common and most familiar representation of a project schedule is a Gantt chart. Figure 3.7 shows an example.
)
Figure
3.7: Example of a Gantt Chart
Creating a useful project plan requires some effort, but maintaining the project plan (adjusting it) is not as labor intensive as it used to be prior to the availability of project management tools. Becoming proficient on a sophisticated project management tool takes some time and requires a solid understanding of project management principles.
Once you key into the tool all the planning components (e.g., tasks, estimates, resources, dependencies), any adjustments you subsequently make to the components automatically cascade through the entire project plan, 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 planning activities.