Project Management

On the Cost of Quality: Build or Buy

By idfive \ May 25, 2006

OK, so your client comes to you and says “I need a system that does this and that, as well as A, B, and C.” You talk budget, and the client gives you a very small number. You nod knowingly, and promise to give them an estimate. Handshakes happen, the client goes home, and you wander back to your desk.

And you start scratching your head.

You know how to build this system. You’ve built things like this before. Nothing so close to this that you might be able to re-use it, but you’re confident that you can build this one just as easily as the last. The problem is this: the client’s budget just won’t let it happen. You know what it will take to build it, and it’s more than what the client wants to pay. A lot more.

So you start hunting. Shopping, really. You need to find out what products are out there that might satisfy the client’s needs. Off-the-shelf products are bound to be cheaper, but you’re skeptical about their ability to fulfill the requirements of this project. And even if they do, what if the client wants to expand the system beyond the means of the product you’ve chosen?

That right there is the problem: How does one build a system that is customized for a client’s needs, but at the low price generally associated with off-the-shelf software? How does one handle the ever-expanding needs of a client, without blowing their entire budget on just the first feature in the system?

As a small company, we are often faced with the small budgets of small clients. We scale our offerings in design, IA, and production to meet budgets all the time. The amount of work we put into a project can go up or down, based on what the client would like to pay for. By setting expectations properly, we can usually create a product at a price that clients are happy with.

Development costs can scale too, and when building a system, it’s important to talk with the client about how the scope of the system affects the price they’ll pay. But there is a point at which the cost gets too high, or the scope too small, and building the system just makes no sense.
At that point we shift from being developers to being integrators. We hunt for the product that will best serve our client’s needs, and we present the best solution to the client. It is our responsibility to help the client understand the limits of off-the-shelf software, including the limited customization that most products offer, as well as the specific limits of the specific packages we’re considering.

If the client asks for features A, B, and C, but the available products offer A, B, and D, the client needs to understand two things: First, that C is out of the picture. This can be a bitter pill to swallow, but the client needs to understand that with a buy-it budget, C isn’t going to happen, whereas with a build-it budget C would be available (at a different price). Secondly, don’t let the client miss out on D, the feature they were not looking for, but that is available in the products they are considering. It may be that it can be useful in the client’s business. And it turns out that off-the-shelf products, which are often built for a wider audience than custom software, tend to have bonus features that clients don’t bother asking for, but that will make clients very happy.

As integrators, we have to be agile. We have to look at software with an eye for features and flexibility. We bring our customers what they want, and try to bring them what they will want. That’s not necessarily how we build things: building for an imagined future can be a waste of time. But buying for that imagined future is a key part of selecting software to integrate.

We also have to be versatile. We have to be able to work with new products all the time. We can’t expect every new project to use the same off-the-shelf software, so we have to have smart people on hand who are ready to learn a new product, gain expertise, and really make it their own.

Lastly, we have to have a full toolbox. More often than not, our clients come to us for solutions to problems we’ve seen before. If we’re going to solve those problems with off-the-shelf software, it helps to use software we’ve used in the past. We can be more efficient, make smarter decisions, and hit budgets more effectively if we’re using tools with which we have some measure of expertise. We’re always evaluating new products, and we’re always open to new solutions, but having solutions ready at hand can go a long way.

Strong integration skills can really make the difference for clients big and small. The choice between build and buy doesn’t have to mean choosing between good and bad. Whereas building can mean custom features, buying can mean more features, more support, and a better price. We need to be prepared to succeed with either option.