Please excuse the mess: as the old saw proclaims, the cobbler's children go barefoot. As an IT consultancy, Apotheonic Labs has somehow managed to neglect the necessity of creating a fancy Web presence for itself. Development is currently in progress.
title: Deadline Math
author: Chad Perrin
version: 1.0
date: 2008320-15:14:59
Project completion date estimation is something of a dark art. It is less science than mysticism and intuition. Some of us are quite good at it, and some not so much. One of the problems people often encounter with accurate project completion is specification creep. There is a simple answer to this problem, however: Deadline Math.
Deadline Math is not quite the same beast as normal mathematics because it makes use of some underlying assumptions that most people never notice. Once they are brought to one's attention, however, they may look like common sense. In the interests of making my life easier -- by helping my clients understand one of the most important factors in accurate project completion estimation -- as well as the interests of helping my fellow developers better practice the art of project completion estimation, I'll explain Deadline Math in brief, by way of an explanation of how I use it.
When I am first asked when I can finish a project, I get a general idea of what the specs are for that project. Based on this understanding, I give an estimated date based on my understanding of the problem that needs to be solved and the requirements for the solution. I also make it clear that this is just an estimate, and will almost certainly change when I receive more specific information about the requirements and the conditions under which those conditions must be met.
Next, I get more specific information about the conditions and solution requirements. Conditions might, for instance, involve a set of input files with known file formats. Requirements, on the other hand, might be for a specific set of output files, each containing predefined information in known file formats.
Once I have this in hand, I either confirm my initial estimate of a completion date or revise it with the new information. Anyone who has a problem with this doesn't understand the concept of "Garbage In, Garbage Out". If that lack of understanding causes that client to cease being a client, it's not a client I want anyway.
At this point, I declare the estimated project completion date, plus a margin for error, the Deadline. This is the date by which the project will be completed (or some other specified milestone will be met, as circumstances dictate).
I start working on the project. I make real progress. I get close to finishing ahead of schedule. Everyone is happy.
At this point, pretty much invariably, the conditions and/or solution requirements change. In the above example of conditions and requirements, such a change might involve the client suddenly saying "Oh, by the way, the file formats we gave you previously are wrong. These are the new formats." This is especially likely to be the case if the entire estimate was predicated upon an assumption that I possess the actual file formats that constitute the conditions of the project.
Now, I use Deadline Math. The Deadline is not, as one might think, an actual static number. It is in fact a function. Arguments are given to this function to produce a result. The apparently static number you probably thought was the real deadline is, in fact, merely the return value of the function for the arguments initially passed to the function. When those arguments change, so does the return value.
For instance, if the initial return value of the deadline function is start_date + 11, and ten days into the project you give me a whole new set of project conditions that invalidate all of the work I've done so far, the new return value of the function is prorated_date + 11, which is equivalent in this case to start_date + 10 + 11, for a grand total of start_date + 21.
There are other factors that may come into play, however. For instance, if the actual completion estimate was predicated upon the notion that there is a three day gap in the number of days I'll be able to work on the project, because I have a prior commitment, the actual function behind the scenes looks more like start_date + working_days + non_working_days, where non_working_days is the number 3 (for the days I won't be able to work on it) and working_days is the number 8, for a total of start_date + 11. Adding another ten days to that might cause the project to run across more days for which I have a prior commitment. For instance, if the new schedule intersects with the schedule for another project, I may have to say "There are nine more days in which I cannot work because I have already committed them to something else," in which case the value of non_working_days is now 11. The end result then becomes start_date + 11 + 10 + 8, for a total of start_date + 29.
If the start_date is 31 October, that means that the initial return value of the deadline function is 11 November, given the project conditions I was led to believe were finalized. Ten days into the project, I'm informed that the conditions have changed so much that the previous ten days' worth of work are now null and void, shifting the schedule forward ten additional days. This means that the new return value of the deadline function, given new project conditions (i.e. argument values for the deadline function), is actually 29 November.
Thus, a deadline of 11 November has become a deadline of 29 November thanks entirely to the poor planning of the client.
This is how Deadline Math works: your deadline is not, in fact, a date. It is, instead, a function. The client plugs arguments into the function, and a return value is generated. If the client changes his/her mind about the values of the arguments, the return value is almost certainly going to change. There is nothing we, the people who research the form of the deadline function itself, can do about this fact.
If the client is very lucky, I'll just prorate my schedule and get the work done according to the new return value of the deadline function. If not, the client can expect me to bill for the extra time spent, at a minimum of the same rate spent for the first chunk of time. The client will often not be able to get a discount for the work that was already done, at the client's insistence, that must now be thrown away. I still did the work for the client; the fact it wasn't what the client actually wanted is the client's fault. It is not mine.
Your lack of proper planning should never constitute my emergency.