A reasonable cost-benefit analysis will have two components: an estimate of costs and an analysis of benefits (kind of obvious, I know). There are, however, some pretty significant limitations to any attempt to formalize both sides of such an analysis.
While you can plausibly estimate costs (hours * salary-per-hour + tools), there are limitations even there: an implementation that the team wants to do will result in an underestimation of time needed while a dreaded change will likely result in an overestimation. The cost end of things is generally pretty manageable though.
It is harder to come up with a plausible dollar estimate of benefits since a fair comparison will ultimately have to break benefits down to dollars earned if you want to do a real comparison. To help you along, here are four broad categories of benefits cases that we make in our organization:
- This feature will increase sales by X%, resulting in net profit increase of $Y
- Customer Z will not renew this year, at a cost of $Y, if we don't implement this feature
- This feature will decrease support requests by $Y (e.g. a help button)
- This feature will simplify development in the future, increasing productivity by X%
1) Market benefit analysis: It is largely a fantasy to believe that you can come up with a dollar figure for the first category (net profit increase). Market dynamics, marketing budgets, etc. all play such an important role that it is like trying to predict the landing spot of a frisbee in a hurricane. Still, a reasonable range of figures may not be out of the question.
2) Demand from a specific customer: Number 2 is really a special case of number 1 and is your easiest and most specific cost-benefit analysis. You can often use a specific customer who is putting a stake in the ground as a proxy for some percentage of your overall customer base: "If Customer X is demanding feature Y and willing to leave without it, what percentage of our customer base feels the same way but just isn't telling us?"
3) Technical support analysis: We do this one a lot and the benefit actually goes beyond the specific savings of technical support costs. By aggressively attending to these kinds of issues, our systems have gained a reputation for ease of use. The other thing is that the support documents are actually created by the support team so all development has to do is integrate it with the help system (in the web product, we don't even have to do that - they can do it).
4) Productivity enhancement analysis: Productivity enhancement analysis is also very hard to estimate but is also very common. Your plug-in idea is an example of this one. For us, the most recent instance was whether to adopt a new reporting tool after we realized that reports were a weakness for us because we were crafting them by hand as PDFs and this took too much time. The problem with estimating costs in this case is that you'll never have an estimate of productivity increase that is accurate enough to use in a dollar-benefit formula.
So, that gives you a few tools to use to gain at least a little formality to your process.
But it also brings me to the real way you figure these things out: judgment and leadership. In the end, your business' ability to thrive will be critically dependent on the leadership abilities and judgment of your senior team members. If they are always chasing some cool new technology just because it sounds fun to build (a lack of judgment) then you'll fail. If they always dig in their heels and refuse to build anything without a solid, complete and unassailable cost/benefit ratio (a lack of leadership) then you will fail. Success will follow only from a sober assessment of risks, a solid sense of where your market is going and what it will need, and an aggressive willingness to be out in front with tools that make an impact. This is true whether your market is "the market" or whether you are an internal IT group serving "customers" within your own organization.