Within the software industry there has been a movement to separate what should be a single product into modules to be implemented at different times. Software providers claim that this provides benefits to wider variety of users by offering them only the functionality they desire rather than offering more than they need. Users are given the option of adding on additional modules at a later date if they decide they might need them. We must ask two separate questions when determining if this provides a benefit:

   Does this modularizing strategy truly provide a benefit to users by giving them just what they need?

   Often times users have an idea of what they want in the beginning without being aware of the full functionality of the software. They learn later that they should have purchased an all-inclusive software package from the beginning but now must pay a premium for those modules they were not aware might help them before. For each additional module the user has to restart the implementation process which puts a strain on the budgeting department for testing and the IT department to provide data.
   Often a user thinks the software module will include everything they need but later find they need to have to pay more to add on smaller additional functions not included in their module. Variable costs for data storage, per user fees, travel charges, per-call service charges or software bug fixes can quickly add up over time. Many companies will charge variable implementation rates which end up costing more than the software itself. This will drive the cost of the software up above what was previously budgeted causing serious monetary problems in future years. You may get the software you want however you will get zero customer service included.

  

Does modularizing software provide time and cost efficiencies to users?
 

    There is a fundamental perspective problem which causes users to think having modularized software is a good idea. Many times a budget is created in separate parts (operating, capital and personnel) and consolidated when all the parts are completed. Users believe since a budget can be created this way that it is alright to implement budgeting software in the same manner. 

   Despite the fact that it may be more efficient to create a budget this way, this is an incredibly inefficient and expensive way to implement software. The implementation time for one module is nearly the same as it is for an entire budget system. Splitting up the implementation into separate modules just lengthens the amount of time spent implementing and the time required from your employees for testing. This in turn increases the cost of the system as a whole since the company must charge more to account for the increased labor costs.