Leading on from that, if your project manager is familiar with the Prince2 PM methodology, you can relatively easily demonstrate the problem in their own terms, using 'Product Breakdown Structure' and 'Product Flow' diagrams.

The PBS splits the overall project 'product' into individual components, which in turn are split into subcomponents etc. The product flow diagram shows the chain of dependencies of products - what has to be built before the next product.

If you can diagram software components in the same way as the (probably) less rigorously defined 'products' that the project plan contains, it might be easier for him/her to understand what you're getting at.

You can also explain with a PBS that once you break down the products to a certain point, it's impossible for two or more people to work simultaneously on the same product - two people simultaneously writing the same subroutine?

Another product based planning concept that's handy for this is the 'integration product' - that's a product where "one or more activities, such as assembly or testing, will need to be applied to that product after its sub-products have been produced" ('Managing successful projects with Prince2' - OGC), so for instance once all the subcomponents of a block of code have been written, someone has to compile them all together and test them.