Nivlong's Observation of the Inverse Relationship Between Physical Size of the Software Licensing Unit and Total Cost™
I admit that I once balked at the cost of software and services for businesses (at the same time I was helping create solutions that had similarly high prices for other companies).
I've since developed the perspective that expensive business-focused software and services that solve business problems can be worth the cost (and not just because I work in software).So let me undo the risk to my reputation and career from the above graphic with three points on software for businesses for the average corporate software user. Developers or employees in general aren't typically aware of their employer's employee-related expenses. Big software can have bigger benefits. But buying isn't always a good idea.
I Wouldn't Pay That MuchAn individual developer might find it hard to purchase an MSDN license out-of-pocket (wow, I didn't realize they were that high). Then again, individual developers don't pay developer salaries plus medical benefits (take your payroll deduction for medical insurance and multiply by about 5) and employer paid employee taxes.
Maybe that $349 refactoring tool that increases developer productivity and morale isn't such a bad deal in comparison to the costs for the actual developer?
Big Software. Bigger Benefits?Scale this idea out to large-scale enterprise-level software and I imagine the average corporate worker couldn't imagine the amount companies pay for software. I've seen three justifications for very-expensive-software-packages.
- Benefits (not simply features, which are check boxes on a request for proposal)
- Competitive advantage through speed of development or ability to offer something unique
- Leverage existing resources (reducing a workforce is a bad form when it's simply easier to focus on doing more with the same)
When Not to Buy!Despite benefits from larger software packages, there are a few situations where you don't want to buy or outsource a given feature or service.
- Core competency. If something is mission critical to your business, it might be a good idea to build it yourself.
- (Lack of) familiarity with software procurement. If the terms SOW, license agreement, and annual support costs are unfamiliar, you still might want to buy, but maybe get help or advice along the way from a method like PMBOK or PRINCE2 or a consulting/research firm.
- Confusion on the product or market space and/or business need. I'll have to save it for another blog post, but I once researched a type of software solution where each team, individual, and seller I spoke with defined the business need, terminology, license arrangements, and expectations differently.
Update Nov 20, 2012: changed the PRINCE2 link to the official site. Thanks to reader Alison for pointing it out.