In addition, there are a lot of other items in proc cache - the formula Mike was using I suspect only dealt with proc plan sizes. However the work plans, final execution plans for adhoc queries are also in proc cache, along with index stats during optimization, etc.
However, I suspect there is a different underlying cause. One possibility is someone was silly enough to set 'number of sort buffers' to some value >2500. If so, than any create index or update stats could cause proc cache to blow out (remember, the victim might not be the sort/stats - it could be a new prepared statement). There are other cases where views get some weird issues and they have plan on disk that causes proc cache to be exceeded - you drop/recreate the view to clear the problem.
I would be taking a closer look at when the problem happens and what is running at the time - or looking in monProcedureCacheMemoryUsage as well as monCachedProcedures/monCachedStatements to get an idea of where proc cache consumption is at. 9G of proc cache is a lot for 120 users....extending to 14G doesn't make sense.....it is possible - e.g. extremely large subquery caching (which is also in proc cache), but......my gut says it is something else.