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.

Feature Creep

Is it fair to describe feature creep in videogames development as "feature creep"?

Is it more the case that it reflects videogames development as a creative process involving uncertainty and discovery?

It'd be interesting to measure how many features get added by "feature creep" at each stage of development of a game and feature, as a proxy measure of much uncertainty is present in the current project plans.

Games project management is interesting.

We focus so heavily on process. We focus on defining tasks, ordering them, estimating the time required and achieving a smooth production with balanced resources.

Yet we never take explicit account of the nature of our industry in our management methodologies. We work in a creative industry, yet none of our current management methodologies address this explicitly, usually only indirectly or tangentially.

Creativity is not a mystical process. There is a big body of literature out there discussing its origins, various models for it, how to encourage it and how to manage it.

Consider some of the main concepts in creativity:

* Divergence

* Convergence

* Incubation

Divergence and convergence are complementary processes. Divergence consists of generating new approaches, alternatives, ideas and plans of action. Convergence involves evaluating those options to select the most appropriate to achieve a solution.

So, to use creativity to solve a problem, we need to identify and define the problem, consider it from many perspectives and reframe it so that we fully understand it. We then diverge to generate many possible solutions, then converge on a sensible solution. And implement it.

The candidate solutions may not be immediately apparent. We may require time to consider the data before we can offer a solution. This is incubation. This is the idea that we need to allow our unconscious thought processes time to work on a problem, before an idea for a solution bubbles to the surface. Our unconscious thought processes are capable of solving far more complex problems that rational thought alone can solve.

So, returning to the idea of games project management, it's strange that we don't manage our projects in a way that supports these concepts. Typically, when a task is begun that requires creativity to solve or implement it, a developer may struggle to make real progress for the first few days, either "spinning his wheels", or attempting solutions that may turn out to be ineffective. What is happening here?

Our management methodologies haven't facilitated the creative process. When a developer "spins his wheels" for the first few days on a task, that is because we haven't given him time for incubation; we haven't allowed time for his mind to chew over the task and to produce ideas for solutions. Instead, he spends the first few days of a task gathering data and incubating solutions. How much time could we save if we factored in some time for incubation? Instead of simply assigning a task to a developer, we can have a phased commencement, where before implementation is begun, we give the developer the opportunity to fully explore the problem before work begins so they can develop ideas ahead of time. The developer will then be likely to begin the task with clear plans for implementation in mind.

What of the process of attempting solutions, only to discard them? This could simply be an example of experimentation. Experimentation, and learning from the failure of those experiments are key to both creativity and learning. Alternatively, however, this could be an example of insufficient divergence or premature convergence.

If we fail to generate sufficient options for a solution (insufficient divergence), we clearly may overlook a more effective solution. When we reach development, we find none of our options suffice. We then have to either adapt our solution, which may or may not prove ultimately effective, or enter a new divergence and convergence iteration. If our management process had facilitated the divergence process, and given it sufficient time, perhaps we could save time down the line on repeating those processes at a more expensive stage of development.

Premature convergence is the selection of a solution before all solutions have been fully evaluated, with the consequence that a superior solution may be overlooked. Again, this may result in significant adaptation or rework of a solution that proves ineffective, typically at the expensive, implementation stage. Better, explicit management of the convergence stage, ensuring all perspectives are considered, all stakeholders' needs are addressed and the full feasibility of a solution is evaluated could save expensive implementation time.

Creativity offers a new, interesting and potentially productive perspective on the management of games projects.