In the previous entry, we explored the inescapable tradeoffs we face in building any software system. For convenience, I’m going to re-insert the diagram that summarizes some of the major tradeoffs:
We see in this picture the unfortunate reality that we can’t have everything we want in a finite world. Never will there be a project that is delivered on time, on budget, feature complete and of high quality. It is, simply, not possible. Why is it not possible? Here’s why:
It is impossible to fully estimate feature complexity in objective terms.
I call this “Project Scope Axiom 1.” When considering the complexity of a given feature, the tools we have for estimating that complexity are very limited. We typically use estimates of hours or relative complexity, but producing those numbers is a haphazard process at best. Estimates of hours are dependent not only on the complexity of the task itself, but also on the skill of the team or individual implementing it. Relative complexity scores attempt to take this into account by measuring the complexity of a particular task vs other tasks, but this leaves us with determining what these numbers actually mean, and leave us with accounting for things we do not yet know. What actually makes a particular task more complex than another? We could say the time it takes, but that forces us back into judging developer skill, which is a whole other mess of uncertainty. I intend to go into this in more depth in a later series, but for now let’s concede that we don’t have a reliable, objective measure of feature (and therefore project) complexity, which leads us directly to a corollary of Axiom 1:
Because it is impossible to objectively estimate complexity fully and thus anticipate all contingencies, an estimate of project scope will, in practice, always be an underestimate.
This is Project Scope Axiom 2, which is another way of saying that we cannot account for what we don’t yet know. The effects of Axiom 2 can be limited with more knowledge as the better we understand a feature or a project’s goals, the less of an impact unknowns can have. Nevertheless, because knowledge is always limited we cannot avoid underestimating. What if we resort to artificially padding our estimates to account for these unknowns, as we usually do? Turns out that doesn’t really help either, for two reasons: said padding is almost always done with an eye toward the available budget, which means it still has nothing to do with the actual requirements of the project, and Project Scope Axiom 3:
Project scope will expand to consume available resources, time and budget.
I think we probably all recognize this as intuitively true. Another way of stating this would be: the more time we have to do something the more time it will take to do it. In practice, artificially padding an underestimate simply results in a larger-but-still-inadequate estimate. What happens is that by one method or another, the scope of the project will expand to meet the padding. People will take longer to make decisions, developers will take longer to get something done, more meetings will be scheduled and, most dangerous of all, features will be added.
(Before we go on, let’s quickly define what we mean by “project scope.” Project scope is used here both descriptively and prescriptively. That is, scope tells us both what the project requires in terms of time, budget, and features, and we can actively change the scope to better fit the available resources.)
The first three Project Scope Axioms seem to have put us in an odd position. I’ve just said that it’s impossible to correctly estimate project scope, but recommended we do it anyway. Then I said project scope will change to consume available resources, which would seem to render an estimate, no matter how accurate, potentially useless.
Yes, it’s true, we cannot perfectly estimate project scope, but we do it anyway, not just to give ourselves a reference point and an idea of cost and timeline, but also to uncover as much as possible about the project so that we can make more informed decisions and reduce the deleterious effect of unanticipated complications on timeline, budget and quality. And yes, it’s true, project scope has an insidious tendency to expand to consume available resources, but this is precisely why it’s so important to take as much time and expend as much effort as we can to accurately estimate the scope. The closer project scope matches available resources, the more likely it is that we will get what we want done with the resources we have available, and the more likely everyone involved is to consider the project a success in the end. That is therefore our goal.
So how do we accurately estimate project scope? The precise, technical methodology is a story for another day, but there are a number of strategic decisions we can make that will help us. Here are two straightforward ways we can help ourselves reach more accurate estimates:
reduce features
do more planning
These are deceptively simple ideas, but they are vastly underutilized. Clients rarely want to reduce features unless absolutely necessary, and agencies are eager to please. Clients are usually eager to get something in hand as quickly as possible, and agencies are champing at the bit to get usable software out the door. Reducing features means objectively less project complexity and a smaller number of things that we can’t anticipate, and more planning means we can better anticipate potential complications and lessen the impact of contingencies. Ideally, we would do both. We would more extensively plan fewer features, as our objective is to narrow what can go wrong as much as possible. These activities help us to limit scope and estimate scope, respectively.
Neither of these things will come naturally. The kind of planning I am talking about is far more extensive and involved than the typical scoping exercises agencies engage in, both in the bidding process and as part of the initial project planning stages. Clients and agencies would need to be willing to spend more time and money on understanding the true requirements and needs of a project before committing to anything, and this requires a fundamental change in expectations about how projects are proposed, bid, and planned.
Along with this comes a recommendation that we reduce features. This isn’t the same as realizing, halfway into the project, that we’re not going to make the deadline so we start desperately pushing features into a post-launch phase. I’m suggesting instead that one of the very first explicit exercises we undertake in any new project is to cut as many features as possible. This is rarely done because the implicit, default choice is to cut quality rather than features, which is exactly what happens at the outset of every project--but no one ever likes to actually bring it up! I’m suggesting, and firmly believe, that we will be better served overall with fewer features of higher quality.
I understand that it might sound a little crazy for anyone to engage with a new client or partner for a new initiative and immediately ask for money to put together an estimate and then suggest cutting things out, but here’s the thing: we’re going to end up doing it anyway! The advantage to this strange approach is that by doing it at the beginning we aren’t assuming the costs of research, scoping, and discovery of features that may not (need to) be implemented, nor the frustration of discovering months later that we’re going to lose something we wanted to have, and what we do have will be of higher quality, which will greatly reduce costs for adding features later on as we seek to reach feature-completeness.
This requires a major shift in thinking. We’ll talk more about that in the next entry. If you were wondering when I would finally break out the A-word (*gasp* Agile), wonder no more.