In the previous entry of this series I made the case that agencies routinely underestimate project costs, commit to more than is possible within those constraints, and that clients expect them to do so. Wew, lad! That’s a pretty bold assertion. Why would clients expect this? Surely clients aren’t actively hoping for or expecting the project to go poorly? Surely not all clients are trying to pull one over on agencies?
Well, no. They aren’t. But what they are doing leads directly to fractured relationships and poor results. As discussed in previous entries, the very act of soliciting an estimate for a project before enough information is gathered for that estimate to be usefully accurate has two major consequences: it materially changes the end result into something different from the expected result while setting the expectation that the expected result can be achieved cheaper than it actually can. We can sum up this idea with the following principle:
You will always get less than you want for your budget.
This may seem obvious, but let me state it another way:
You can get what you want but not for the budget you want, or you can stick to your budget but not get everything you want.
This principle helps us to better understand why clients expect agencies to underestimate project costs and commit to more than they can possibly do for a given amount of time and money: because clients do not like to be told that they can’t get everything they want for their available time and budget. Meanwhile agencies, for fear of missing out on a lucrative contract, are willing to take the risk of telling clients what they want to hear in direct violation of the principle stated above. That’s not to say agencies never tell clients they can’t get everything they want. They very frequently do, but usually not until after they’ve already committed to doing more than they can with the resources on hand, either by producing an inaccurate estimate or by under-planning, or both.
So, if we accept this as true (which I think I’ve made a solid case for), then what does it mean for us in practice? It means that client-agency relationships based on these dysfunctional behaviors inevitably decay as trust is lost. Trust is lost because along each commonly measured axis of project success (timeline, budget, and feature-completeness), something unavoidably and unexpectedly falls severely short. Of course, something will always fall short in any project because nothing is ever perfect, but falling short becomes a real problem when it’s unexpected and when the severity is great. Misjudging the true costs of a project by overcommitting and overpromising results in both unexpected and severe shortfalls.
How do we stop overcommitting and overpromising? We start by paying the price to learn as much as possible about the project before we commit and before we discuss any numbers. That means we approach each new project from two angles: figure out how much we think it will cost to deliver the project feature-complete, and figure out how many features we think we can fit into the available budget and timeline. This process is much more involved than the superficial scoping exercises most agencies undertake as part of the bidding and sales process. It will take significant time and money, but avoiding it is burying our heads in the sand. Refusing to arm yourself with this knowledge is like taking $100 into the grocery store and then filling your cart with your eyes closed. We can do better. We must do better.
Am I saying that if we undertake an extensive, expensive scoping exercise before we commit to a project we’ll be able to achieve our desired results on time and on budget? Well, that’s a more complicated question, and one we’ll be discussing as we go. Right now, it suffices to say we will get much closer to doing so, and we’ll maintain much healthier relationships between clients and agencies in the process.
Now that we’ve set all that out, let’s discuss another principle that follows directly from the above:
On time, on budget, and feature-complete is impossible.
This might seem like a bit of an overstatement, but remember: what you can afford and what you need aren’t necessarily related (and in fact very probably aren’t). A simple diagram (you’ve probably seen this before, or a variation on the theme) illustrates this:
Your project is represented by a dot placed somewhere in the triangle. I don’t want to be too reductive as this hardly captures nuance, but it does show the essence of the idea, which is that moving toward one corner necessarily takes us further away from one or both of the others. For example, the closer we want to be to an on-time delivery, the further away we will be to coming in on budget and/or being feature-complete. Why is this? The lines of the triangle represent all available resources, and these resources are finite--that is, moving toward one corner necessarily takes us further away from the others.
This picture, however, is incomplete. There are more dimensions to project success--or what’s commonly referred to as the “win conditions”--than time, money, and features. This diagram revises the previous diagram and brings in one such added dimension I consider to be crucial to project success:
This diagram pairs up aspects of project success along the horizontal or vertical axes to depict the forces that work directly against each other. We see here again that being on time means we’re further away from being on budget, but now we’ve added the notion that prioritizing features directly takes us further away from “higher quality,” the new dimension. Of course, as before, adding features also takes us further away from being on time and on budget, but more obliquely--that is, we can’t readily quantify how much from each in comparable terms due to other factors (team size, project complexity, etc), so to simplify things we say adding features takes away from on time and on budget equally. On the other hand, we can more readily quantify the relationship between features and quality--we can say that adding more features has a direct adverse effect on quality, even when accounting for team size and project complexity. For completeness, here’s a diagram that tries to incorporate all those aspects of a project, which I proudly call “The Dismal Diamond of Project Perfection.”
Here we see that complexity increases as we add features, which reduces quality, and adding to team size gets us closer to being on time and/or allows us to add features but gets us further from being on budget and can affect quality by adding complexity. In the real world things are obviously more complex, but it gets closer to capturing reality, most importantly the reality that there are difficult tradeoffs in every project that we cannot avoid.
Most of these aspects are self-explanatory, but what about “quality”? Quality represents a software system that costs more or less money and time to maintain. Low quality code has the knock-on effect of consuming an outsized share of available resources the longer the project exists. It is often said that only 20% of the final cost of a software system is in implementation, with the remaining 80% in maintenance. Think of low quality code like rust on a car. Once it takes hold, it can spread and corrode everything around it, and the longer it’s left alone the more damage it does and the costlier it will be to fix, to the point where it can destroy the system (the point at which it becomes costlier to maintain or fix than the value it offers). Low quality code is unavoidable under any constraints of time, budget, and feature-completeness. It will happen, and we want to minimize it.
At this point you might be asking “Why can’t we just implement features with high quality from the start?” Unfortunately, software development simply doesn’t work that way. There is a concept in software development called “technical debt.” Technical debt is a cost incurred by the very act of creating software. It is, in essence, the sum total of deficiencies (bugs, poor optimization, poorly-documented code, poorly-written code, code resulting from inadequate understanding or planning, etc) in a software system that can only be ameliorated by extra effort above and beyond what it took to simply “get it to work.” Even the most talented software developers produce technical debt. Just like financial debt, we pay a steep price by imposing inadequate time and budgetary constraints on software development, a price that must eventually be paid back if the system is to work as intended indefinitely and without spiraling upkeep costs. You can think of technical debt as a function of the ratio of project complexity versus timeline: the more complex a piece of functionality is implemented in a relatively short time, the more technical debt there will be. Here’s an example of what happens when we neglect quality:
It was once reported on Hacker News that the Oracle Database source code consists of 25 million lines of code. Changing even one line of code breaks thousands of tests. It takes days to understand what a single line of code does. It takes weeks to implement the fix before submitting it for compilation. It takes, in many cases, months to see the fix through to production. It can take up to two years to add small new features. This code is the result of decades of work under difficult deadlines without, obviously, paying back nearly enough technical debt.
Imagine the explosive costs of such a system in terms of dollars and opportunity. Imagine how much time is wasted over the course of a year. This might be an extreme example, but quality is not optional if you want a functional, affordable software system. Striving for feature-completeness at the expense of quality (again, an unavoidable tradeoff) is an extremely dangerous game to play.
Well, this is a dire view of things, isn’t it? How do we fix it all? Can we fix it? I’ll discuss that in the next entry.