What we do is task-oriented, but sometimes — due to time and budget constraints — there isn’t an overarching project to contain them in, a situation that — for us here at the Octane HQ — often arises in the aftermath of completing a major project, where we make the incremental changes only to discover this weird hinterland between the doing and the planning, and it’s in this ad hoc wilderness of weirdness that we sometimes find a time vampyre lurking, swallowing up precious time.
I was reminded of this a few weeks ago when a friend had to explain to someone this exact problem, but it’s a pernicious problem in that it’s resilience is in part due to the perception that, in general:
“We’re moving the gain line forward and getting things done, so what’s the problem?”
When we spin up a new task we first need to open at least one application, either running native on a computer or something on the web, and then reappraise ourselves with the instructions and the requirements (sometimes in conflict with each other), and also what we did before — the list goes on.
Sometimes, this time spent preparing needn’t be replicated if we think more about what needs to be done and line the tasks up such that the initial preparation for one is applicable to those other tasks in the sequence.
What remains should be a production line of tasks with a slither of preparation in between (switching to a different set of instructions or files in the same project folder, as an example), where you then get on with the — uh — task at hand.
So, with this in mind, I conjured up an graphic to illustrate this approach, which — I hope — makes sense!