So back when I proposed a multi-project Critical Chain solution for software engineering, I wrote a paper - based on real experience - that a good shared resource to select as the synchronizing drum would be the user experience (or interface design) group. This met the first criteria for a good drum resource. It was close to the front end of the system and therefore the rope (back to the start) would be short. [For those not deeply familiar with Critical Chain, the synchronizing resource is actually operated using the Theory of Constraints Drum-Buffer-Rope solution commonly associated with manufacturing plants].

The second criteria for a good drum resource is that it have low variation. The reason for this is pretty obvious. If a drum synchronizer had high degrees of variation then there would be times when it wasn't the constraint and the unknown and unmanaged alternative constraint would throw the system into chaos. Equally, at times when the drum was severely under performing due to wide variation, it would mean very low productivity from the whole system. Everything would be dragged down by the wide variation in the constraint.

So it was argued, the user experience group with its artsy types would not be a good choice because artists are too unreliable. Hmmm. That could be true? So, I was left with two choices, persuade the organization to invest the user experience group to relieve it of its bottleneck status or solve the problem. The answer was to introduce the use of Visual Vocabulary modeling as an analog to the domain modeling in FDD. The VV model is used to identify all the work items for the design team. For each box on the model, the team has to design a screen or web page. We then measured the design effort typically associated with this and it exhibited remarkable low variation.

So, that just leaves the modeling effort itself, which is also conducted by the same capacity constrained user experience designer resources. This has the ability to eat into their time for designing and hence is a variable of variation. The way to drive variation out of modeling is to strictly time box it, for example, one week per quarter, or no more than 7% of an iteration's calendar time. We had remarkable success with this technique. The theory was pretty closely reflected in the operational reality.

So as a general rule, organize a process to put the bottleneck close to the beginning - this requires investment elsewhere to provide slack capacity - then optimize the chosen drum resource and reduce its variation through the introduction of better analysis techniques.