You can make a .bsp file that can be run by quake with just the qbsp program. This is fine for developing small tests, but different methodologies are required for developing full size levels. This does not work for doors, triggers, etc that are composed of brushes. There are oportunities for network level parallization with some recoding. Qbsp uses fork level parallization to utilize up to three processors, and it would be trivial to change to allow it to be run on three computers.
Light is embarassingly parallel, and can be divided arbitrarily.
Vis is highly parallel, but it takes some advantage of order of completion in the serial case, so scaling is not quite linear. There are certainly major algorithmic optimzations that can be made to the code to improve the processing speed. The vis speed for bad cases could be improved dramatically by growing together leafs that have large numbers of portals into larger pseudo-leafs. The ray casting method I used in light is of debatable speed for the normal sampling level, but at the -extra sampling level it would almost certainly be faster to process an entire view from each light, rather than each light to each sample point. That would be a total rewrite, though, not a simple patch.