The Ready-Set-Do! Backstory

My Introduction to Getting Things Done®

Ready-Set-Do! got its start after I was introduced to David Allen’s book Getting Things Done by a former professor of mine a few years ago. I had used other productivity workflows before, but none like this one that cleared my mind enough to focus and get things done. Initially I was very skeptical and ‘put off’ reading the book for fear that it would upset my current system of getting things done; or worse, result in me having to “get used to” something else. But eventually my curiosity got the better of me and I read the book. There were many things I immediately connected with, such as the idea that this could get me better organized. Other ideas in the book, however, seemed foreign and irrelevant to me. It was only after initially setting up my office space with only one inbox and filing things into their appropriate folders (e.g. Actionable/Next Actions, Projects, Waiting For, Read-Review, Agendas, etc.) that I started to get more optimistic about the workflow: “Hey, if this can get me this organized this quickly perhaps it can actually help me get more done!”

Those were the first ‘baby steps’ into the GTD® workflow. It took me close to a year to master the core GTD® habits of getting my inbox to empty, processing things one item at-a-time, doing less-than-2min actions immediately, defining next actions by location context (e.g. @ Home:…, @ Office:…, @ Phone…, etc.), getting clear on projects, doing my daily and weekly reviews. and (one I’m still working on!) treating the hard lines of my calendar as HardLines. Like others, I did it not really believe I needed to do everything suggested in Getting Things Done®. It was only after I continually began seeing certain elements slipping through the cracks or my mind slipping back into taking over things it was supposed to have put into the trusted system that gets reviewed regularly that I realized “Yep, I actually have to do the Weekly Review weekly,” and “Yep, I actually need to review every element of my system — no stone unturned — if I want to maintain that clarity of mind that is the true treasure of the workflow.

Falling Prey to Temptation: Total Reduction & The “Perfect” Program

Once I got proficient at the GTD® workflow, I encountered that one issue that inevitably comes up: How do I balance and integrate the digital and paper-based inventories of my commitments and obligations? I’m great at processing paper and getting my paper-based inbox to empty and reviewing my physical Actionable and Read-Review folders and action lists, but what about all of the ‘stuff’ on my computer? What about all of those emails? What about the documents on my computer; how do I process those? At first I fell prey to the temptation to think that I could shoehorn all of my digital stuff into my paper-based workflow; and after that failed to be practical, to try the opposite. Once I realized total reduction of paper-to-digital or digital-to-paper was impossible, it didn’t take long for me to fall prey to the next temptation of embarking on a quest for the “perfect” program. I began looking through all of the blogs, user-groups, and productivity websites in order to find what would perfectly integrate my entire digital and paper-based inventories of projects and actions. At the time there were people talking about specific programs they could use on their handheld devices; there were web-based implementations of GTD® that would allow a person to create their action lists online. I played around with some of them but recalled that perpetual experience of mine in the digital age: Programs I entrust myself to that either get bought out by a larger company or just die off with no more software support. I would be left with files in a format I could no longer access because the program that created it was now dead. I’m sure there are many of you as well who have had the experience of trying to keep prehistoric files of yours on life-support using conversion programs and what not to keep them alive to no avail. It was during this time that I began thinking about putting folders on my computer desktop to match my physical folders for my GTD® workflow. And the thought of having one inbox on my computer to put undefined stuff and process it seemed like a great idea.

What About the File System Architecture?

That’s eventually what started the ball rolling. Initially it began as just a way of organizing the stuff on my computer to match my physical GTD® folders, but it eventually surfaced the thought of using the file system architecture (i.e. the names of files and the comments that are associated with them) to make my action lists. Since the mac operating system allowed one to see folders in “list view” I saw this as an appropriate way to see the names of files and to put their next actions in the comments field for each one. In addition, I began to see the value of this sort of digital implementation of the GTD® workflow: It would not get bought out by some larger company or fall off the deep-end with no more software support. Once I realized that file names and the comments associated with them could be used in this way I began to see this as a simple, reliable, and long-term solution for the implementation of my GTD® workflow.

Around the same time, I also recalled an experience I had five years earlier at a Macworld Expo conference. I sat in on a session about automating workflows with AppleScript® by Sal Soghoian. At that session I was blown away at what was possible to automate with applescript! He had programs and pictures dancing around his computer screen producing full 3-page layout brochures, uploading web-pages, changing his desktop background to the latest web-cam picture at places all around the world. Recalling this workshop I attended, it occurred to me that it might be possible to make some basic applescripts that could help me process the digital stuff in my computer inbox. Something that could walk me through the GTD® process for getting IN to empty (What is it? Is it actionable? Can you do it in less than 2 minutes? etc.) At first I was extremely intimidated by the prospect of having to learn a programming language like applescript, and I did not even think I would be able to pull it off. In previous years I had done some things with Hypercard (yeah, remember those days?!) so I was mildly optimistic. So I picked up a book on applescript for the sole purpose of trying to learn just enough to make this basic script for getting my inbox to empty. It started with a creation of the most basic of scripts – “Empty Your Head” that allowed me to quickly iterate new ideas I had to my Inbox, and it didn’t take long after that before the “Get Inbox to Empty” script also became a reality.

After I created the “Get Inbox to Empty” script I began thinking further about how else I could utilize the File System Architecture for my workflow. And the more I continued thinking about it as a digital solution I was committed to, I started thinking of more thoughtful ways of integrating everything on my computer. That’s when the idea of using “alias files” to connect Projects and Actionables occurred to me. If I could clarify my projects in my Projects folder and break things down into one-step actionables with their next actions attached in their comments fields, then I could make alias files in the Actionable folder to their originals in the Projects folder. That way I could keep my Actionables and Projects synchronized without either of them encroaching on each other’s space. At first I did Projects with text files for Outcome Visioning and Brainstorming and had the folders of “Project Support”, “Moving Parts”, “Unmoving Parts”, and “Completed Parts.” Anything that had a next action in the comments field I would drag from the “Unmoving Parts” folder into the “Moving Parts” folder; and once in the “Moving Parts” folder, new aliases would be made to those project components in my Actionable and Read-Review and Waiting For folders based upon the comments specified for their next actions. But it didn’t take long before I realized this was not working. I went back to the Getting Things Done and the subsequent Ready For Anything books in search of how to best handle projects. That’s when I discovered the Mission-Critical, Key Milestones, and Deliverables elements of getting clear on projects (GTD, pg. 58-59) and so I added those as component folders for the projects. I also realized that I was not reviewing the Brainstorming and Outcome Vision text files associated with each project because they were “inside” of a file I had to double-click to open. With my commitment to using the file system architecture I began thinking about the possibility of creating the individual folders of “Primary Purpose”, “Standards”, and “Outcome Vision” and permitting myself to quickly iterate things to them the same way my “Empty Your Head” script had permitted me to quickly dump my ideas to my Inbox. And these changes made a significant jump in my ability to get my projects and actionables more synchronized and streamlined.

The Downside of “Lists” and the Power of One-At-A-Time

Eventually the other scripts evolved out of my own, practical experience of discovering what worked and what did not work for me. Among one of the most important things I discovered along the way was the value of processing things one item at-a-time. I noticed that when I looked at things in a list format — particularly with my Projects — that my mind would immediately go into comparing, prioritizing, and sorting the elements of the list and it would “freeze up” between two or more items. By processing one item at-a-time from the inbox and defining each one, etc. it takes away the added burden of having to decide between two or more items to process first. In other words, choosing two or three things out of the Inbox to process adds an ‘extra’ decision before either of them gets defined — namely, Which one do I process first? Once I recognized this I noticed that most of the other digital implementations of the GTD® workflow gravitated, naturally, to list managers. And my own file-system implementation of GTD® did so as well by displaying things with the “list view” of the Mac OS®. But what these all had in common was looking at more than one thing at-a-time; and thus when I would open up my Actionable folder and see the list of next actions attached to each file in the comments fields, I could sort them by location contexts (i.e. @ Home:…, @ Office:…, @ Phone:…, etc.) but I still found my mind freezing up between two or more items. That’s when I decided to start creating additional scripts that would allow me to leverage the power of one-at-a-time throughout my GTD® system to see if would help at all. And help it did! It certainly was more tedious to go through each item of a project, but the advantage of doing so was that my mind was able to focus on one element at a time to write down any new thoughts that one element might call to mind rather than having my mind spend its time — generated in large part as a result of the list format — thinking about sorting, prioritizing, comparing, and the like.

Needless to say, the scripts evolved into what you see today after much tweaking and experimentation. Every once in awhile the scripts would incorporate functionality that became more of an impediment than it was worth (such as when I had a time lock-out when processing my Read-Reviews; if I chose something to read in 15 minutes it would lock me out from doing anything else during that time; it only took a week to realize this was not going to work). But more often than not I would come to realize that greater functionality was needed (as was the case with creating the functionality for sub-projects). All along the way, though, I tried to constantly remind myself to keep things simple. The simpler and the more reliant upon the file system architecture, the more I and others could continue to maintain the system even manually by changing the names of files and the next actions in their comments fields.

Beyond Self: Ensuring Flexibility & Utility for Others

To this day I am convinced that the only two scripts that one really needs to take advantage of this digital implementation of GTD® are the “Empty Your Head” and “Get Inbox to Empty” scripts. Those two were immediately intuitive and the most useful to me; so useful, in fact, that I now can’t imagine using my computer without them. The rest afforded me the flexibility to do further things with what those two scripts had generated. And it wasn’t until about six months into working on the scripts and using them myself that I began to see them as something others might be interested in using as well. But once that occurred to me I began rethinking the scripts in a way that would offer the most flexibility to others besides myself. Thus in the beginning I had one giant, master script that would walk me through my own stuff, but I realized that separating them out individually into their own scripts (i.e. Get Some Actionables Done, Get Clear on Projects, Do Weekly Review, etc.) would afford others the ability to use only those scripts that they found the most useful.

Subsequently I began writing up the Read Me files, the Quickstart Guides, securing permissions from icon designers and the like, and having others I knew who were familiar with David Allen’s workflow try it out and give me feedback. Now that those things have been finished I have made it available to the public.

That’s it for the backstory. The future story has yet to be written. And it is my hope that users will provide feedback and suggestions for even greater simplicity, reliability, and functionality. I also see this digital implementation of the GTD® workflow on the mac working in combination with those of others. Some users may not like using the file system architecture for organizing their projects and sub-projects and would rather use something like OmniOutliner or NoteTaker or some other application for the mac. Those proficient enough in applescript could design plug-ins or accent scripts to bring elements from one’s Ready-Set-Do! desktop folders into their preferred program and vice versa. The more flexibility and possibilities there are for GTDers the better. For myself, I am committing my workflow to the file system architecture as its core. That, at least, is something I know is going to be here for the long-term. That’s why I wrote the scripts. And that’s what I’m hoping others will find, likewise, to be a simple and reliable approach to their own GTD® implementation and workflow. If you find that these scripts provide that for you, great! If not, let me know what can be improved. I look forward to your feedback as well as your own future backstories.

Join The 1,000+ Satisfied Ready-Set-Do! Users

Try It Now!