But! Breaking down tasks to small pieces is a huge task by itself! Many people can't ever use that framework because well they cannot get themselves to that point. Is there any framework you know which could help applying this framework?
Indeed; also, I must be doing something wrong, because when I start breaking tasks down to the point of triviality, I end up with a rather big pile of them, which becomes its own challenge to manage - and then two or three simple tasks in, some result invalidates most of the rest of the breakdown.
The key is to figure out what is the priority, break that down to a couple tasks you can do now and do them even before you break down anymore. That is you want to find the list of what you will do in the next few hours and get that done. Done means find a good stopping point, clean up and put the tools away. Sometimes you will ready to clean up and realize you have more time and so you break down one more task, that is fine so long as you leave things in a finished state - cleaned up and tools put away.
Ideally the project is complete and whatever isn't done will be a next phase you can do in the future. If a project must be over several days you need more planning and you need to get the whole thing done. For your daily driver car you have to complete each phase and have a drivable car at the end of each day, for a project car you can have 42 years (real number for a project car a friend of mine is working on) between starting and a drivable car - but phases are still things you complete in a few hours either way.
I recall GTD doesn't say break each task down into all the pieces.
I thought it said to define the "next action" for each task.
It makes sense to me - you really just want the next concrete action to get the task moving.
If you had to itemize every part of a project, I think that would lead to a procrastination-evoking roadblock.
If your task was "do your taxes", it would be easier to start with "get the tax form out", than "get the tax form, every other tax form, and list all your itemized deductions".. just to put "do your taxes" on your todo list.
For me this is a set of general strategies for breaking down problems. Here are some I use. (Apologies if these aren't all orthogonal to one another; they just feel different when I'm thinking of how to break a problem down.)
1. Break down the steps. Can you find a recipe of steps for achieving the thing? Then start with the first step. Maybe that's a small enough task. Maybe you don't have to perform all steps in order, and you can find a small-enough step to do next.
2. Isolate the fundamental challenges. There is often a tough nut to crack within the problem. Can you isolate that from the rest of the project, and turn it into its own thing (I like to cast this as a "toy" problem)? When I say "isolate," I mean to remove all unnecessary complexity to getting at the fundamental issue. Suppose I want to figure out how to create a robust messaging network. There might be user interfaces and caching and different kinds of messages and different networks and different failure mechanisms and performance issues and ... So just create a "toy" at each step: First, simply send & receive a message. Don't worry about performance or worry much about robustness. You now have a small task but whose completion achieves a fundamentally necessary part of the larger task. Finishing that will feel good--you have something that works!--and you've made real progress. You might find examples of others doing something similar to this basic task as well, so you can work on your own but then compare notes to others to gain insights on why others have solved similar problems differently than how you solved it (you might have come to something better, or not; either way, you now have understanding of the fundamental problems involved). Now you can grow that toy or take what you learned from the toy and apply it to the larger task.
3. Similar to 2, but maybe a different POV: The physics joke is approximating a cow as a perfect sphere to study its dynamics. Simply the hell out of a problem! Maybe it feels ridiculously simple. Fine; now you are working with something completely tractable. You can then add in complexity to your model one wrinkle at a time.
4. Do something that's actually easy even if i might not be "significant" from the "big challenges to getting this project working" POV. Maybe you've been frustrated for a week or two trying to solve the tough-nut-to-crack bit of the problem. Even your toy problem remains (what feels hopelessly) broken! Switch over to creating the GUI or something superficial but that is easily tractable yet yields something satisfying to you when you finish. Simply stepping away from the hard problem for a day or two can re-motivate you when you come back to the hard problem. That time can also give your mind time to process solutions in the background (many people--myself included--have an "a ha!" moment when not thinking directly about a hard problem). And you are still being productive, moving towards the end goal. You had to make a GUI anyway at some point. Might as well be when you are stuck on the hard thing and feeling frustrated.
Getting good at breaking down problems took me many years. I credit my physics education as being particularly helpful (training thinking of problems & solutions in their extremes and always connecting solutions back to "does it make sense"). But much of the above is also learning my own psychology of how I work and what/when/how I am motivated to work and in the best position psychologically to solve a problem. I expect this isn't too different for many people, but the details can vary from person to person.
Thank you for the extensive explanation. The problem I mentioned starts rather earlier: say I have X big tasks. I need to split them (applying your described process or otherwise) into smaller tasks. BUT now I'm looking at X x2 tasks: the original X ones, each one getting another task of splitting it into smaller ones. The whole stack becomes only more overwhelming like this...
A big part of the idea with my system is that you only identify 5 tasks at a time. Anything more then that and it becomes overwhelming. So the idea is to peel off the first 5 actionable tasks from your project(s), deal with those before thinking further about the project.
Yes this implies having a general sense of how to accomplish the project and the tasks involved, but no it does not mean you need to have a master plan with every step mapped out. Every 5 steps you get to re-assess and course correct.
