A software client asked an interesting question last week that got me thinking about managing the impact of uncertainty on product development. The gist of the question was, “How do you deal with projects that have elements of both discovery and well understood tasks?”
Project Planning
The first element of uncertainty in any new product project is basic schedule uncertainty. When is the project likely to be finished? Critical Chain is the most effective tool out there for managing schedule uncertainty with users reporting up to 95% of projects finishing on time.
One of the most important elements of Critical Chain is a project buffer that protects the due date from unexpected problems while also reducing the overall project duration. (click here for more on CC) Unfortunately, the basic methods for sizing the project buffer weren’t created for highly variable tasks like invention and discovery.
The primary way that CC buffers project is with time. You can compensate for highly uncertain tasks by adding more time buffer to the overall project. The problem I have with this is that tasks with widely varying degrees of uncertainty are protected by the same buffer while separating them could cause unwanted procrastination at the task level.
It’s also possible to buffer with scope. In fact, scope is a de facto buffer in almost all new product development projects. In software, if we aren’t going to meet the scheduled release date, the less important features or elements of features are pushed into the next release. The same thing happens with physical products. As long as it doesn’t compromise the overall product functionality, we relax the product requirements whenever the date approaches faster than we are progressing.
Unless you make the scope buffer (the features that are optional) explicit, this is really just complicity in pretending that the project finished on time. And if you do make it explicit as to which ones are optional, why wouldn’t you leave them for the next release and get to market sooner anyway. That has the best impact on cash flow and follows the approach of finding small wins. The scope buffer approach also doesn’t account for the economic costs of multiple releases which has more impact in physical products but isn’t free in software either.
That’s why I like the approach of buffering with iterations. If your discovery and invention could be done in as few as three experimental iterations, build a project plan that includes six (or whatever number the degree of uncertainty might call for). In this case, each iteration should be treated as a determinant task so that it is not buffered in the overall plan. Then when you have a solution mark all six complete.
However, it is also important to avoid so called apple polishing and make sure that further experimentation stops (at least for this project) when a solution is found. The temptation here is that if you give a researcher 6 iterations and it only takes 4, they may want to keep going to explore space beyond the solution because they know they are unlikely to get a chance to come back to it later.
Workflow Management
The question that inspired this post initially did so in the context of a Kanban visual workflow approach. (see more on Kanban here) The client wanted to know how to deal with dramatically different workflows depending the level of discovery or invention required for the feature being developed.
While separate groups to handle discovery vs. basic engineering projects can be helpful, it isn’t always practical. So using a Kanban visual workflow approach, you can manage projects that require discovery by using a separate “swim lane” on the Kanban board. These tasks move at a different pace and require iteration so a separate lane helps keep the issues from being tangled up with more straightforward engineering projects. It is also critically important to conduct feasibility and discovery work as early as possible. That way projects that aren’t feasible can be culled out early before constrained development resources are wasted.
