jbrains.ca
Call us now 1 888 OK-JBRAINS (655-2724)
0
Getting Things Done-style Project Management
I use Getting Things Done as my primary system for tracking my life’s work. I have wanted to write a little about how to use GTD principles and practices to manage a project, so now I am. If you don’t know much about Getting Things Done, then I recommend reading about it, but at the center of the system is the Two-Minute Rule:
If you can do it in two minutes or less, then do it now; otherwise, file it as an action to do in the future.
This rule combines with another simple, powerful heuristic, which I apply to every task I might do.
For every task that comes your way, decide whether to destroy it, do it now (Two-Minute Rule), delegate it to someone else, or defer it to later.
Notice that “destroy it” comes first. If you don’t have to do it, and you don’t want to do it, then don’t do it.
I don’t like to create expense reports. I’d like to delegate this to someone else, but I don’t find that cost-effective. I’d like to outsource the solution, but I haven’t seen anyone get it right, particularly because of the way I handle multiple currencies. As a result, I choose to do it. Even if I outsourced the reporting part, I can’t quite outsource the receipt-gathering part. I have the receipts, and I need to put them somewhere. I decided to try outlining a dead-simple project to help me with this, and I chose to use it as a guinea pig for this series of articles.
I use OmniFocus as my action repository, so I started a new project and dumped out my ideas for this software product. That resulted in the following entries into OmniFocus:
I created three top-level actions: Spike, Release 1, and Future Releases. I have no need to be more specific at this time. I treat “Release 1″ as the Toyota version of the application, and defer everything use to “Future Releases”.
I use cars as the metaphor for feature service levels: Toyota, Lexus and Bentley. The Toyota version of a feature is safe, functional, but not pretty; Lexus add-ons are things I know customers and users want; Bentley add-ons are things I think customers and users don’t even realise they want, but will love and pay through the nose for. I teach this as part of Product Sashimi.
To start, I focus my detailed attention on the Spike, since without that, there’s no benefit to this product. I want to easily drag and drop receipts into my expense reports, and I suspect that’s not hard to do, but I don’t know how to do it. Within “Spike”, I create two actions: the kernel, which is the task I need to do before it makes sense to move on, and the others, which I could try in any order. To capture the dependency, I make the Spike action group sequential, but the Spike/Cool Stuff group parallel. In OmniFocus terms, this means I have to do “Drag and drop a single PDF” before all the “Cool stuff”, but I can do any of the “Cool stuff” in any order.
After focusing on the details of the Spike, I do a brain dump, push as much into “Future Releases” as I can, then make the top-level actions sequential: first the Spike, then Release 1, then Future Releases. To my delight, the actions in Release 1 don’t need to happen in any particular sequence, so I don’t need to identify a kernel task. This makes the kernel of the Spike the project’s “next action”, and I’ll focus on doing that first.
I have not added estimates, because I don’t care. I’m doing this project in my spare time on an “as I can do it” basis. I just want to get to a minimum useful version with a minimum of delay, so rather than estimate, I’m just going to ruthlessly defer work to “Future Releases” as I go. This means making as many convenient-for-the-system assumptions as I can. This is another key technique in Product Sashimi.
As far as I’m concerned, this project is ready to get underway. I wonder when I’ll actually get around to doing the Spike. At least I have an article to read.
