Scheduling Optimization & Crashing

This section delves into advanced scheduling techniques including activity relationships, lag, crashing for timeline compression, and overall activity network optimization within the CallDoc project.

Precedence Relationships in CallDoc

In CallDoc's activity network, we rely primarily on Finish-to-Start (FS) relationships. For example:

* "Design System Architecture" must finish before "Backend Development" can start.
* "GDPR Audit Simulation" must finish before "External Certification" begins.

However, advanced sequencing introduces other types:

Relationship Type	CallDoc Example	Real-World Application
Finish-to-Start	UI/UX → QA testing	Traditional task handoff
Start-to-Start	Backend + Frontend integration	Parallel Dev Streams
Finish-to-Finish	Backend + GDPR compliance wrap	Joint audit readiness
Start-to-Finish	Support onboarding + Beta ends	CallDoc doesn't use this often (rare use case)

Lag Example

A lag is a planned delay between activities. For instance, a 2-day lag is placed between backend testing and compliance validation in the CallDoc project. This allows for necessary documentation preparation and review before proceeding to the compliance validation stage, ensuring that all testing results are properly recorded and understood.

Crashing in CallDoc

Crashing is a schedule compression technique used to reduce the project timeline by adding resources, thereby increasing costs. This is typically applied to critical path activities where a reduction in duration directly impacts the overall project completion date. In the CallDoc project, crashing was strategically applied to activities such as:

Backend Development: Reduced from an original estimate of 20 days to 12 days by assigning additional senior developers and authorizing overtime.
GDPR Audit Preparation: Fast-tracked by engaging specialized GDPR consultants to accelerate documentation and process alignment.
Penetration Testing: Expedited to align with the compressed audit timeline, ensuring security validation did not become a bottleneck.

Crashing Calculation Example

The decision to crash an activity is often based on its crash slope, which quantifies the cost per unit of time saved. The formula is:

Crash Slope Formula:

Crash \, Slope = \frac{Crash \, Cost - Normal \, Cost}{Normal \, Time - Crash \, Time}

For CallDoc's GDPR Audit Preparation activity:

Normal Scenario: 3 days duration at a cost of €15,000.
Crashed Scenario: 2 days duration at a cost of €22,500 (due to consultant fees for expedited work).

Slope = (€22,500 – €15,000) / (3 days – 2 days) = €7,500 / 1 day = €7,500 per day saved.

Crashing Strategy

Only crash activities if they are on the critical path (or are likely to become critical).
Ensure there's sufficient room to compress the activity without causing new critical paths or insurmountable resource conflicts.
The cost of crashing must be justified by the business value of earlier completion (e.g., meeting a market window, regulatory deadline, or reducing a daily project overhead that exceeds the crash cost).

Activity Network Optimization

Beyond crashing individual activities, overall network optimization for the CallDoc project involves continuous management:

Slack Analysis: Regularly identifying tasks with float (e.g., certain UI design tasks or internal documentation efforts initially had some slack, allowing for resource flexibility).
Multiple Critical Paths: Recognizing that after crashing some activities, new critical paths can emerge, or the project might operate with multiple parallel critical paths requiring careful monitoring (e.g., one path through Backend → QA → Audit; and another through Compliance Documentation → Integration Testing → Certification).
Resource Reallocation: Dynamically reallocating resources to avoid overloads during crashed periods and to support newly critical activities. This involves careful resource leveling and smoothing where possible.