Why Prioritizing Between Good, Cheap or Fast is a Must • Slash

Life as we know it, is more akin to that box of chocolates than we often want to admit to ourselves. We all want the chocolate that we like the most with our preferred filling, but not knowing leaves it to chance and it doesn’t always work out. Dark or milk chocolate, soft or hard center, chewy or creamy and so on.

In the world of software development, there is a similar game of chance played between good, cheap or fast. We can seem to reliably get two, but the third eludes our grasp. Therefore, prioritizing which combination is important to your project will lead you to selecting the best combo option. The goal here is to help you evaluate the combo options and details therein to make the best selection.

Cheap & Fast
Fast & Good
Good & Cheap

First off let’s acknowledge the lack of a roadmap strategy, sadly an all too often occurrence that can be avoided. The roadmap strategy is knowing all or at least 2~3 steps in advance of how the product is going to evolve. the first step is often referred to as the minimum viable product, or MVP. Therefore, you should know MVP1, MVP2 & MVP3 before you even begin. Knowing what you need in the foreseeable project future enables you to start planning what is important to you.

For example, if quality is not a key component for MVP1 because you’re just aiming for a concept and feedback therein, then perhaps selecting cheap & fast is most suitable at this stage. Now fast forward to say MVP5, you find yourself launching a new feature which is quite pricey and quality is suddenly an important factor. Hence having a roadmap, knowing what you’re doing and what your priority is between good, cheap or fast is a must. Naturally your priorities may change as the product evolves and therefore, the focus from cheap & fast may shift to fast & good.

The communication between you and your vendor is, as you rightly figured, quite important. If you feel that your vendor is a yes-man, this should be an immediate red flag moment. A vendor who simply answers yes to all your requests while taking zero notes, seemingly ignoring the fact that your budget is $20k while you’ve requested a product that will cost $200k… all we can say is, good luck. That product will never come, and what you will get will be of hopelessly poor quality to name only a single problem.

Do your research, find where the balance is between the three points rather than over focusing on the negotiation to get the best deal. Do that and you may please your superior, but ultimately the project will crash and burn spectacularly. Find the sweet spot between cheap, good or fast and you will manage to develop the product that you need.

Table of Contents

How do you do fast and well?

Ah yes, the holy grail of development. We challenge you to answer this, but beware as the answer is more elusive than you may think. Naturally here at Slash we know how software works; that is, it’s not about fast starts. Remember the tortoise and the hare? If so, surely you recall the adage “slow and steady wins the race.” This is software in a nutshell. You start slow, you storm, you fight to find your velocity and then you reach your maximum speed. However, that speed does not translate to fast.

Ultimately no one understands or knows how long projects take therefore, making it all about a negotiation of cost. Also keep in mind, you cannot have it paired with deadlines. You may negotiate for something to be delivered in two months and find that three or four months later you’re still waiting. Why? Well often the product evolved into something much bigger than originally negotiated.

If your tech vendor is extremely optimized and specialized for developing a specific type of product which you conveniently need, then perhaps fast and well is on the menu. It’s like if we hire a guy to change a light bulb in the office and his one job is “bulb changer,” then yes it’ll be fast cause it’s all he does. Though in the software field, this simply doesn’t exist.

Coming back then, how do you do fast and well? We have yet to answer this enigma. We can confidently prepare our development teams to be efficient, but this does not translate to fast and well. It’s just simply not that easy. So we invite you to answer, if you can!

The Killer “… right?”

We cannot recall the number of times a client has asked us something to the tune of, “You can make this simple change, right?” Or, “This shouldn’t take long, right?” This little “right?” though innocuously innocent, causes more problems that you can imagine. If you ask your vendor a question, please don’t already have the answer, the answer you are wanting to hear. Is the intent to ask a genuine question, or simply for the other party to agree with you? This is not the way to communicate; every tech vendor and client knows this, but somehow this merry-go-round continues.

Why do we mention this? Well for one, it’s killing a lot in the development process. Especially taking into account when you have vendors and clients from opposite ends of the globe; the cultural gap is wide. The typical developer, when asked, “This is easy, right?”, will always give the same answer… “Yes!” Naturally there are exceptions, but we’re addressing the standard. It’s a killer because it destroys the ability to truly understand how much needs to be done which in turn impairs your roadmap strategy simultaneously throwing your selection of good, cheap or fast into disarray. So let’s check “right?” at the door and have an honest conversation with genuine questions!

Fixed scope vs Changing scope, your choice… BIG Choice!

The fact is, nowadays a good 90% of people who engage in software projects have no clue what the end product will look like. It’s a situation which presents the mother of all unknown unknowns; in comes Agile with a flexible roadmap strategy no doubt.

If you go into a fixed scope looking for an estimate and there’s an 80% chance that it’s going to change, well let’s just say you’ll likely find yourself up a certain river minus a paddle. You’ll end up spending countless hours discussing with your vendor, “This is equal to that, right?” and so on. The killer “right?” comes in for the death blow. Your project will naturally pivot and it will lead you into vast amounts of wasted time via conversations that seem to go in circles.

To put a pin in this, it’s not about trying to get the cheapest project estimate because you have a fixed scope, rather the cheapest is actually the changing scope. Nice curveball, right? It’s a fact that it’s cheaper to budget for a pivoting project rather than a fixed project. Yes, we know, the ironies abound herein. If you buy a fixed scope and decide to change, good and fast go down the drain!

Success Depends on Relationships

A final point to make here is the success of your software project does not hang on your negotiation skill, but rather on the relationship you build with your vendor. There’s power in being friendly with your neighbors, no? We jest, but you see the point; when you need that cup of sugar, you know you can get it when you have good relationships. If you build a quality relationship with your vendor, there is no doubt they will do whatever it takes to get you what you need whether it’s good, cheap or fast.

And the final irony herein is that at the end of the day it’s not about selecting only two of the three good, cheap or fast. It’s actually about finding a compromise between the three and investing everything into the relationship.