Tying Release Planning to the Critical Chain

Another conversation with my friend Tom Looy caused me to start thinking about project networks and how they relate to Release Planning. A project network is a construct of tasks or work products (which are groups of tasks) that link together to form a mathematical graph representing a logistical map of the project. Ok, what does this really mean and how do MMFs and IFMs work in to this (as you know they must or I would not have brought them up!)

Well, first a bit of background – a project network is used to identify a project’s Critical Chain. As initially defined by Eli Goldratt, a project’s critical chain is its manifestation of the Rope from the Theory of Constraints’ Drum-Buffer-Rope concept. It is what is tying all the operations centers together with their dependencies and precedences such that the “right thing” will pop out the back when the project is over.

In most undertakings where TOC or CCPM are utilized, the “right thing” is pretty well defined. In many of the projects where agile methods are used, the “right thing” is generally understood, but not defined. However, there are a couple of valuable things we can take from the project network, if we can figure out how to integrate it into our concept of Agile Planning. First, we get the concept of buffers for our schedules. The buffers provide us with the ability to project out our actual releases early on in the planning and give us some flexibility in statistically committing to firm dates. Second, we get the actual critical chain. The critical chain is valuable because it focuses us on everything we need to do to achieve the objective we are setting out with, it also offers us a view of all the dependencies that need to be completed so as to allow us to achieve our real goal. Though this sounds reasonable, it is somewhat striking to suggest because the only way to establish the critical chain is to identify all the tasks we believe we need to accomplish, which is rather antithetical in agile approaches.

True though, when we create a project network what we are actually doing is creating a future reality tree for the project: if the project were completed successfully, we would have …; therefore, in order have that, we need to have … and so on back to “today we start the project by doing …”. Now certainly this does not mean that we need to identify every single action we are going to take. When CCPMers talk of identifying tasks they typically do not mean the same low level tasks we refer to: i.e. those building blocks of stories or features that tend to be chunks of work no more than 1-3 days long. What they refer to are basic components of the project that must be completed to support the implementation of the next level of the tree.

The exercise of creating the tree is more than a planning exercise – it is designed to ensure the important dependents and precedences are identified and understood so that the complete book of work can be defined, the critical chain specified and the constraint(s) illuminated. Once done, ROIs and value props can be determined and project viability understood.

Clearly this is more ‘ahead’ work than we do in an agile project, but consider if you will, the opportunity that we create if we were to take a leaf from this book: During release planning, as part of my chartering exercise, let’s say we create a high level project network. In doing so, I identify a lot more detail about the entire project than I might other wise do. However, I also produce a dependency chart and identify a critical path such that should the customer desire a change later on, we can reference it back to the network and understand what it impacts, and if so, how far back in the tree we need to start accommodating it before it adversely affects the critical chain.

All of a sudden, we can do both cost/value derivations on features as well as put in place an incremental funding model for both features and the project. If I know that “A” is in my set of MMFs, then it is probably also in the critical chain. If my customer asks to reprioritize, deprioritize it or even eliminate it, we can quickly and clearly see how the value proposition for the entire project changes. Equally, if other features are added to or removed from either the project or the set of MMFs we can understand what the impact may be. Once we start seeing the project network as a future reality tree, then the project itself becomes less abstract and more concrete both as an entity and as part of the holistic value stream of the organization.