Watching Critical Path Dependencies
A critical path is the sequence of activities that set a lower limit on when a capability can be realized. It is the “long pole in the tent”. For example, consider the capability dependency graph that we showed in step 5:
Suppose that we have made a rough estimate of how long it will take to create each capability, as follows:
| Capability | Expected Days to Create (Educated Guess) |
|---|---|
| Walk | 2 |
| Run | 3 |
| Leap | 3 |
| Grasp | 1 |
| Carry | 2 |
| Tumble | 4 |
| Tumble While Carrying Something | 6 |
| Leap Off Cliff and Tumble Down Hill While Carrying Your Lunch | 4 |
Here’s a graphical version of that, for the visual thinkers:
If you add up the pathways leading up to the final capability, we end up wit these dependency pathways:
| Path | Min Duration (Days) | |
|---|---|---|
| 1 | Walk —> Run —> Leap | 8 |
| 2 | Grasp —> Carry | 3 |
| 3 | Walk —> Carry | 4 |
| 4 | Walk —> Tumble —> Tumble While Carrying Something | 12 |
| 5 | Walk —> Carry —> Tumble While Carrying Something | 10 |
The longest of these is path 4, Walk —> Tumble —> Tumble While Carrying Something. Thus, no matter how fast other capabilities are completed, the time to create the final usable or marketable capability, Leap Off Cliff and Tumble Down Hill While Carrying Your Lunch, is constrained to be no sooner than 12 days. That is the critical path.
This changes every day, so it is something to always be watching; because if time to market is important to you, then you want to focus on the areas that are having trouble and that impact the critical path.
Estimate Capability Time-to-Create
The estimates for completion time are educated guesses. Do not waste time trying to create detailed estimates. Experienced developers can usually estimate better than your most detailed estimate. Their brains have a sophisticated neural network that has been trained in estimation, and remember that development work is not deterministic: you cannot add up the tasks to get a time. It is creative work. Tasks cannot all be known up front.
Also, these estimates should be updated whenever something changes that might impact one of them. The estimates are a rolling guess, and its purpose is twofold:
To help to identify where the critical path is, and therefore where to focus; and,
To project the soonest time when a capability might be completed.
But again, these are guesses. If you have promised a capability to be available at the time predicted by these guesses, you have made a grave error: there should always be a comfortable margin added on, because when building something for the first time, it will always take longer because unforeseen issues arise.
Also, whenever possible, capabilities should be worked on in parallel. In engineering and software development, developers often use “mocks” for things that are not available yet. The capability estimates should take into account the way that the work will be done, including parallel development. But integration usually reveals new issues.