Critical Chain Project Management

The Critical Chain project management methodology has some interesting ideas that are very relevant to games projects.

1. Time is not used to figure out the critical chain of a project. Instead, dependencies are used.
2. Buffers and padding are not placed at the end of each activity. Instead, they are placed, in aggregate, at the end of the project.

(1) is particularly salient for two reasons. Firstly, as is well known, software remains resolutely incredibly difficult to estimate accurately; what is the point, therefore, in using inherently inaccurate estimates to attempt to calculate your critical chain? Dependencies are a critical factor your ability to deploy resources. You cannot add resources to expediate a particular activity if dependent work is held up. Conversely, identifying those points in a project that have the maximal tasks dependent upon them highlights them as points in the project that need maximal resources to ensure their successful completion and enable dependent tasks to begin.

(2) is simply Parkinson's law. Adding padding to each task makes its timely completion far less critical, and therefore things begin to slip. Critical Chain instead calls for all activities to be begun and completed as quickly as possible (as doing so eliminates them as a dependency allowing further work to begin) and the padding is instead added at the end of the project. This change therefore means that the scheduling of a particular task is purely dependent on its input dependencies, not a function of the dependencies and the padding.

And furthermore, what sense does it make to add 20%, say, to an inherently inaccurate estimate anyway? Why not 10%? Why not 50%? Such a practice is meaningless.

Critical Chain is not a massively revolutionary technique, but its different perspective on some fundamentals of project management is quite insightful.