Q. Identify the information needed for the project crashing. For a project with which you are familiar with, try to identify the various items of information.
Project Crashing:
Overview and Information Needed
Project crashing is a
time-cost trade-off technique in project management used to reduce the total
duration of a project by allocating additional resources to critical path
tasks. It involves identifying critical activities and applying resources or
strategies to shorten their durations while managing the additional costs and
risks involved. Below is an extensive discussion of the various items of
information required for project crashing, applied to a hypothetical project
scenario, such as developing a software application.
1. Project Schedule
and Activity Network
The first step in project
crashing is obtaining a comprehensive project schedule and activity network.
These documents illustrate all project activities, their durations,
dependencies, and critical paths. The critical path is especially important as
it identifies activities that directly impact the project's completion time.
For example, in a software project, tasks like requirement gathering, system
design, coding, testing, and deployment might be interdependent, and their
critical paths need to be meticulously analyzed.
2. Activity
Durations
The duration of each
activity is essential for assessing the scope of crashing. Activities on the
critical path that have a long duration are primary candidates for crashing.
Knowing the estimated time for tasks like developing specific modules of a
software application or testing them is critical for planning how much time can
be saved.
3. Crash Durations
Crash duration refers to
the shortest possible time an activity can take if additional resources or
strategies are applied. For example, a software module development phase
originally estimated to take 10 weeks may be reduced to 7 weeks by hiring
additional developers or using advanced development tools.
4. Crash Costs
For each critical path
activity, crash costs must be calculated. These are additional costs incurred
to reduce the time required for the task. Costs could include overtime pay for
developers, hiring contractors, purchasing new software tools, or renting
additional testing infrastructure. In the context of the software project, if
the testing phase costs $5,000/week to run normally, crashing it by adding more
testers might increase this to $8,000/week.
5. Cost-Time Slope
The cost-time slope helps
determine the cost-effectiveness of crashing activities. It is calculated by
dividing the additional cost of crashing an activity by the time saved. For
instance, if crashing the testing phase of a project reduces its duration by 3
weeks but increases costs by $9,000, the cost-time slope is $3,000 per week
saved.
6. Resource
Availability
Resource availability is
critical to determining which activities can realistically be crashed. This
includes human resources, equipment, and technology. If skilled personnel for
coding are limited, the activity cannot be effectively crashed without causing
bottlenecks in other areas.
7. Risk Assessment
Crashing increases risks
such as burnout, quality degradation, or unavailability of resources. A
thorough risk assessment is necessary to ensure that crashing activities do not
introduce more issues than they resolve. For instance, rushing software coding
might lead to poorly written code requiring more extensive debugging later.
8.
Impact on Quality
The impact of crashing on
quality should be evaluated, especially in industries like software
development, where errors can be costly. For example, reducing the duration of
user acceptance testing might expedite delivery but increase the chances of
releasing a product with critical bugs.
9.
Dependencies and Constraints
Understanding dependencies
and constraints between activities ensures that crashing one task does not
adversely affect others. In the software example, coding cannot begin until the
design phase is complete, and reducing design time might compromise coding
efficiency.
10.
Budget Constraints
The overall project
budget and its flexibility are critical in determining the extent to which
crashing can be implemented. A project with a tight budget might have limited
scope for investing in additional resources for crashing.
11.
Stakeholder Priorities
Stakeholders’ preferences
and priorities often guide decisions about crashing. If meeting the deadline is
a higher priority than minimizing costs, more aggressive crashing strategies
might be employed.
12.
Alternative Scenarios
Exploring alternative
scenarios allows project managers to evaluate different crashing strategies.
For instance, in software development, one strategy might involve parallel
processing of tasks, while another might focus on outsourcing specific
activities to third-party vendors.
13.
Monitoring and Control Mechanisms
Implementing monitoring
and control mechanisms ensures that the effects of crashing are tracked. Key
performance indicators (KPIs) and regular updates help in assessing whether the
crashing efforts are yielding the desired results.
14.
Documentation of Lessons Learned
0 comments:
Note: Only a member of this blog may post a comment.