Good, fast, or cheap: Pick two. This is a paradigm many in the professional world know well. The Project Management Institute discusses it in terms of cost, time, and scope. In order to get something done, you have to be flexible in at least one of those regards—if you want something done fast and cheap, you can’t be too fixated on how well it turns out. In other words, the guiding question when it comes to setting out on any project is simple: “For this much money and this amount of time, what do I get?”
When I think about this paradigm in terms of software development, I think the factor of “scope” works well as a stand-in for “quality.” To be clear, however, I’m not talking about how “good” a piece of software ends up being. I’m talking about the reason we even develop software in the first place, and the major risks that come with assuming a rigid budget and deadline will result in software that does what it needs to do.
In software, cost and time mean nothing if the quality isn’t there.
Why Do We Settle for Less with Software?
Let me ask you a question: How many times have you used a piece of software that just doesn’t work? It could be something as small as a button failing to do what it’s supposed to on an app you use on your phone. Or something bigger like a password reset sending you in an endless loop with no real way to recover your credentials. It’s frustrating, sure, but it happens so often that most of us don’t really give it a second thought anymore. “Oh, well,” we think, and then we move on.
In other words, we’ve been programmed to accept a lower quality standard in software than we might with any other product.
And even the big players are guilty of feeding into this. How many Google products do you use every day that have been in “beta” for years with no end in sight? If we pretend that software is never really ready, then we might forgive developers for turning out defective products.
But what happens when you replace something like Google Hangouts with a product that a business relies on every day to function? The stakes suddenly become much higher when enterprise software doesn’t work as intended. Which leads to an even bigger question…
How Do You Measure Quality in Enterprise Software?
I think one of the major reasons quality is often left by the wayside in project management is because it’s just much harder for many to quantitatively measure than cost and time. How do you measure cost? Easy—you measure in dollars. The vast majority of software projects start like any other corporate project, with a set budget measured in a dollar amount. That’s the cost, and it’s as concrete as any measurement can be.
The same goes for time. You can measure how many hours a day you have available to you, how hard you can work your team, and how far you can break something down to small parts before you hit a point where development is simply going to take a certain minimum amount of time. And if my years in the Air Force working 6 am to 8 pm have taught me anything, it’s that you get diminishing returns the longer you work—you can only flex your time constraints so far before they break. In that regard, time quickly becomes as absolute a constraint as cost.
But what about quality? It’s more abstract. You can set a scope of work, but how do you know if that scope was met? More than that, if you come into a project with an arbitrary budget and timeline, how can you ever really be sure that you’ve given a project the budget and time it needs to deliver the scope you expect? You can’t ever take the notion of quality and make it absolute if you have no standard way of measuring it.
Let me clear something up right now: Quality might seem abstract, but it’s really not. It’s just as simple as the constraints of time and budget. Here’s an example. The other day I went into a McDonald’s—something I don’t do very often anymore—and had my first encounter with their self-service kiosks. I saw that there was a gentleman at the register trying to get an order in, so I went to the kiosk. It took me just a few seconds to punch in my own custom order and grab my receipt. My order was entered, paid for, and sitting for me at the counter before the guy ordering at the register had a chance to get his order in.
In this specific case, quality is a measure of how well the self-service kiosks solve the business problem of long wait times at McDonald’s. I’d say the kiosks did exactly that in my experience, and so I’d say that’s a quality solution.
Here’s the bottom line: The true measure of quality is whether or not something meets your business need. As quality professionals, we know exactly how to measure quality. We can both quantify it and qualify it. We don’t just hope for quality; we tie our quality measures back to the business needs you have. After all, what does it matter if the software “works” when you click on a drop-down if it doesn’t actually meet your business need?
Quality is the Only Real Constraint
If your business takes the time to think critically about why you’re developing software—what business need you have to fill—you now have three constraints. You have your budget, you have your time horizon, and you know how to measure whether or not your software solves your need. In other words, you know what quality means. But once you determine what quality means, I believe it’s the only constraint that matters in the long run. Five years from now, it won’t matter how much you spent or how long you worked on something if the quality isn’t there and it doesn’t work. In today’s social media world, you don’t get a second chance. Do you really want to leave quality to chance and wait to have a public failure out there for the world to see?