(COST VS. PRICE) VS. (PRICE VS. COST) PART 1

by Jim Pantelas

This is presented as an exercise in reason. Think of it as another discourse on beauty, worth or goodness because it really is that obtuse. But it’s a discourse worth having.

In our industry, we are often grappling with a shortsighted focus on price: saving money up front by cutting corners versus developing with long-term sustainability—but at a higher front-end price tag. It’s an argument we’ve all heard—and probably all had. We’re charged with the development of a major application, we have a tight deadline, and we’ve just gotten approval of a budget that’s 20% lower than our plan.

Ours is a knowledge- and experience-based industry. So when time and price are an issue we can often get talked into taking the discount warehouse approach as the easiest alternative. We send the work to wherever in the world there’s an oversupply of developers because we can negotiate the best price. Or we go to the biggest vendor because they have the most people and are willing to give us the cheapest price. And we throw bodies at the effort. Cheap bodies, but lots of them!

Been there? Done that? If you’ve been in the software and IT business for a while you know the effects. Systems that often perform the tasks as originally specified, but are inordinately difficult to maintain—and even harder to adapt to new requirements. Systems that function well in an isolated setting but are extremely hard to integrate with new applications. These systems require a great deal of effort to do anything with beyond their original intent.

So Release One of the application works. It came in at or close to budget and is delivering most of what your organization wanted. But now it’s yours, and now you need to maintain it, enhance it and integrate it into your universe. And, now that it’s up and running, people are asking for some enhanced features no one ever mentioned before. Worse yet, they want to create interfaces to platforms that didn’t even exist when this system was initially designed. And suddenly you’re the one that has to start putting forward budget numbers to do all of that, and those numbers are not pretty!

This is one of those times when the conversation of Price versus Cost is very much a reality. If the system wasn’t developed and documented well, everything you do will take longer. And if it wasn’t developed by people with enough experience to know that things will need to change over time, every change will take hours and hours longer than it should need to. And if it was developed without the intuitive forethought of how it might someday need to fit into your changing universe—or if those needs were budgeted out of the initial development—your costs to make it do so will be infinitely higher.

I know I’m probably preaching to the choir here, but the shortcuts we take on the front end always make the ongoing cost of implementing, integrating, supporting and enhancing an application higher. And “higher” could be measured in magnitudes!

In a big enough company this can be ignored for a long time. The person who made the decision to design an application is often not the person that decides how or where it’s developed, and the person who makes those decisions is often not the one responsible for integrating, implementing or supporting the application long term. But if you’re in a mid-sized firm, you could be all of those people, and fingers will get aimed your way.

This is about building and supporting an argument in favor of spending less money over the cost of ownership of an application. This often means spending more money up front. It’s about framing your argument to ask for more money by showing real cost savings over time and by building a return on investment case that is supportable.

So build your case. Show how much the added 20% spent on the front end will pay off over the next 3, 5 or 7 years. Without pointing fingers cite how your approach would have changed some of your current costs if applied in previous applications. You’ll have done your job by pleading the case effectively.

Rest assured, there are ways to deliver on both cost and price, but it can sometimes feel like neither. You can’t allow yourself to get distracted by one over the other to get the disadvantages of both. And you can’t get either by shortchanging talent, experience or attitude.

The thought to leave you with here is to ask you to consider the long-term effects of what we all do, not just what we do today, and the overall effects it will have over time. Are the systems we’re developing today intuitive? Are they maintainable? Will they play well (integrate) with other systems as your organization grows? And, in 5 or 6 or 10 years, when people associate your name with the development of a given application, will they be cursing you, or praising your forethought?

This is the first in a series on this issue. Later I’ll touch on the arguments in favor of experience versus volume—that never ending discourse on bringing on great talent that costs 2-X but produce 3 times more in a month than anyone else on your team. I’ll also try to address the cost of intellectual attrition and understanding why keeping and motivating the talent you have can be more cost effective that letting them leave.

Jim Pantelas is a Business Growth and Business Development Specialist with Stout. Jim began his career as an Assembler and Machine Language programmer at the National Security Agency some 100 or so years ago.