Many of our ProChain clients do significant R&D work, so people ask us from time to time whether critical chain is applicable in a research environment. The common wisdom is that it isn’t, because research is inherently unknowable. A particular discovery may be made in a week, maybe in a year, maybe never. How can you plan for that? What is the value in a methodology that helps improve predictability, when there clearly is no predictability? In this post I’ll talk about a critical chain approach to planning research projects.
To start with, it’s important to make a distinction between “pure” research, which is meant to increase understanding without necessarily being directly applicable to products; and “applied” research, which is research intended to reach a specific goal. Here I’m talking about applied research. For example, studying high-temperature superconductors may be pure research; determining how to adapt high-temperature superconductors for use in a new high-speed train would be applied research.
Let’s assume that these are important research projects, and that therefore we are truly constrained by our ability to innovate, to come up with breakthrough ideas that can be applied to products. That, in turn, suggests a number of ideas for making sure we get the most out of this constraint:
- Identify as clearly as possible the types of breakthroughs that are needed.
- Make sure key research people are focused on the important problems and have the resources and information they need to do the work.
- Have the pieces set up so that as knowledge is gained, you can capitalize on it quickly.
- Have regular communication between researchers and business people so that everyone can make the best possible decisions for the business. This kind of communication requires an unusual level of trust, which is only built through good communication.
Item 1 implies a clear charter for the work: what are we trying to achieve.
Items 2 and 3 suggest a strong project plan: to help define, set, and manage priorities; to capitalize on innovation when it occurs; and to spur ongoing communication.
Item 4 suggests an enterprise system that shows which research projects are in process and where they stand.
Research projects typically have a great deal of emergent work. Many ideas are tested over time, and you don’t know until an idea is tested what the downstream work will be. One way to approach planning and communication is to divide the project work into two pieces: work that you know about and unknown (emergent) work that you can only guess at. The work you know about is modeled with standard tasks and links. The unknown work can be represented as a long task (or a group of high-level tasks), with a checklist or notes describing what we think is likely to happen and why. As work emerges, the new tasks are added, and our estimate of the remaining unknown work may (or may not) change.
What about buffers? This is a difficult question, because a primary purpose of buffers is to protect the customer from fluctuations in how long things take. With research, we don’t generally know how long the breakthroughs will take. That means there is no size of buffer that will really protect the customer. The customer can’t be protected from the inherent variation in research by time buffers. If a particular innovation is not deemed likely to be ready in time for a particular product, either the product is deferred, or it must use some other technology.
The buffer can provide a useful target in this situation, as long as you don’t take its end date too seriously. It doesn’t mean “when are you likely to complete,” it means “what do you currently think is reasonable.” That may change. Its size is also a way to describe “what’s important,” because chances are you won’t want to spend a lot of time on details that are small relative to the size of the buffer.
With this kind of buffered project plan in place, the project and task notes should give a verbal picture of status. The fever chart shows visual status. On the horizontal axis, we have an estimate of what work has been accomplished so far, relative to what we were originally guessing. On the vertical axis, we have some sense of the perceived level of delays. I advise against showing red, yellow, and green regions, because those regions imply that you have some reason to believe that the target (the end date of the buffer) is realistic. Instead, the ProChain Enterprise portfolio views are a good mechanism for showing a combination of estimated value, risk, and buffer status.
Most important, remember that the greatest value of the schedule is credible communication. What are we planning? Where should we focus? What are we hoping for? What’s being done to make progress? We want to communicate an honest understanding in order to enable good decisions.
