Project management is unfortunately full of acronyms. From the world of task scheduling comes two that apply in other areas as well: ASAP and ALAP, as soon/late as possible.
ASAP has gone on to greater fame in the larger arena, so much so that it’s often pronounced as a word — EY-sap — rather than spelled out — ey ess ey PEE.
Technically, they refer to starting a task at the earliest and latest possible dates. I’m catching a ferry off Lopez Island (later today as I write this, but likely “yesterday” when I post it). Let’s say I go for the 1:40 ferry (which I know will not be full on a Thursday in early spring). ASAP would mean leaving as soon as all the necessary precursor tasks are complete at our island cabin — heat set to “away” mode, garbage collected, veggie scraps in the compost pile, bags in the car, etc. ALAP mean leaving such that I arrive at the ferry as cars are loading; they load 1:35 if the ferry’s on time, it’s a 12 minute drive, and so I should leave at 1:23 to maximize my time on the island.
The problem with leaving at 1:23 is that it doesn’t allow for the possibility of getting stuck behind a farm vehicle (happens occasionally, with limited places to pass) or wrestling the dog into the car (easy wrestle, but first I have to catch the dog, who’d rather play fetch with the ball lying on the lawn than attend to my priorities).
The problem with starting tasks ALAP is that it doesn’t allow for things going wrong. Sure, you can build buffer and such into the schedule, but that approach incurs its own costs and often unwarranted complexities. ALAP works in a world of certainty, but few project worlds — especially in the Legal space — can claim certainty as a defining characteristic.
The problem with starting tasks ASAP is more subtle. First, as Samuel Johnson put it, “nothing so concentrates the mind as the prospect of being hanged in the morning.” Some tasks — and those who perform them — simply work better when there’s some pressure around the outcome. Second, there’s the waste of “carrying inventory” — having stuff done before there’s a need for it. (In my ferry example, what the heck am I going to do if I get to the ferry 90 minutes early? It’s hard to use my laptop in the car, for example, doubly so when the dog also claims rights to my lap.) Third, there’s a real-world possibility that additional information will develop during the time in which you could have waited for the task to start, information that would benefit the project and improve the quality of the task’s output.
Thus I want to introduce the concept ATAP: as timely as possible. Let’s say you can begin a task any time between time X and time Y and still be reasonably sure of completing it by deadline, time X being ASAP and time Y being ALAP. When is ATAP?
There’s no clean rule for locating ATAP. I could devise a reasonable mathematical model, one that accounts for probabilities of mis-estimating task length, issues such as sudden resource unavailability (illness, being drafted onto a priority task), the increasing value of information developed between times X and Y, and so on. However, the map is not the terrain; the margin of error for such a model would be huge in the real world in “soft” areas such as legal projects (as opposed to “hard” or well known areas such as construction projects or manufacturing).
Rather, I urge you to think of ATAP as a concept. What’s the right time — or the “best” time — to begin a task that can start over a range of times? What works best considering the people doing the task, the flow of information, the communication needs of others involved, and a host of other data? ATAP is really a thought-experiment. When you’re managing a project, don’t get caught in the absolutism that all tasks must be ASAP, or ALAP, depending on your style. Be neither obsessive nor a procrastinator, so to speak. Rather, be timely. Do it ATAP.
I’ll probably leave for the 1:40 ferry around 1:15. Unless, of course, I decide to take the 4:55. I’ll decide not this morning, not at 1:15, but ATAP.