|Modular thinking may make you too rigid.|
In these frameworks, modules are published in a way that gives other users of the same CMF the ability to reuse them in other installations. The flexibility of this module-based approach is that it extends the functionality of a CMF towards your intended purposes, while keeping the base system generic enough that users with distinctly different purposes are free to follow the same process towards their own ends. An added bonus is that in almost every case you may do this for little financial outlay as most of these components are made available free of charge.
A powerful paradigm, however, module use, although free, is not entirely without cost
When you are using modules developed for other sites you are generally in a favorable situation. Someone else had a need, they had a module created to fulfill that need, they published it, gratis, and you get to benefit from their development time. In major CMFs there are modules for almost all needs.
As you work more and more with other people's modules you begin to develop a module mindset: "this does just about what I want, and it doesn't cost anything, therefore this is good enough."
Over time, this leads to an almost unconscious thought process comparing needs vs. what already exists in that solution space. Eventually it becomes easier to justify the adaption of exact needs to fit the existing solution (instead of a solution to fit the needs). This is an implicit application of the Ninety-ninety rule : the disproportionate amount of time it takes to accomplish the final details of a software solution. If someone has already gotten you 90% of the way there, isn't it better to adapt to the existing solution than to put forth full effort for a unique solution?
A customer hires a software solutions firm looking for answers to their problems. More often then not software solutions are being written for the web, and these content management frameworks have become a popular platform for this type of work. The customer generally does not care much about the technical implementation as the solution, they care about the technical implementation of the solution. What is used to make the features work is not nearly as important as the requested features working, and working as expected.
This is where we see the most room for misunderstanding in projects
The developer comes in with the module mindset; the customer wants their functional needs met. The developer and the customer begin talking past each other from the outset, but believing they have an understanding. "There is module that does that" takes two meanings when in effect there is a module that does almost that. The module mindset begins to discount functionality in favor of availability almost immediately. The customer, in the dark about the implementation details, believes that they have lucked into a solution: exactly what they want and already built. The developer is applying with own value system: it does 90% of what you needed, plus a bunch of other stuff you may need someday and is free... fortune smiles on us both!
There seems to be an implicit appreciation of the Ninety-ninety rule especially around module based software systems. Pre-developed software is always a tempting value proposition, even if there are required tradeoffs to make it fit. Sometimes it is easier to shave the square peg to fit it into round hole. Developers should understand that their customers may not understand this as intuitively, if at all. They come into the project with a set of requirements, and expect that list to be fully met, no matter how elegant or available the (almost) solutions.
How can this miscommunication be resolved?
Developers should increase their self-awareness in these conversations, to insure their words give off proper expectations around any module use. Customers should follow up to be sure that pre-built software truly meets their needs without gaps. Customers should also try to recognize the value in using existing modules, and appreciate the savings possible if areas of functionality may be negotiated. A proper conversation about project requirements, how those requirements are met by modules, and the trade-offs involved needs to occur and be fully understood by both parties.