I find that naming projects after "functionality" instead of specific clients or technology etc is a big help in this regards. In the .NET world, it's almost customary to begin the name of each project after the owner of the code, for instance MyCompanyName."some_functionality".exe
As a developer, I find I often have a hard time choosing an appropriate term for some set of functions, but when we attempt early on to name something as close to function as possible, then it's not so difficult. It's part of the "clean code" development process.
There are times when it does make sense to name projects after a particular technology, if such a project name would create a definite boundary of understanding of what or where the project is used. For instance, ideally you would not group hardware related functionality into a vendor specific project, but rather perhaps by "function", which could be printers, scanners etc.
Really, we should use the basic principle of being consistent. If we are consistent in how we group and name projects, the barrior between clients are our products have lower learning curves and better adoption rates.
