The Productive Organizer

I have blogged about this iPhone Mindmapping software that is really good and how you can use it to incorporate into your GTD system.

Their Version 2.2 is currently in the approval stage and what i like about them is that they don’t rest on their laurels but are coming up with more and more ways to make this mind mapping software as functional as the desktop applications.

Here is a video showing how you can map relationships between related nodes.

What i really hope to is that they can come up with Tagging and Tag filtering of nodes. That will be awesome

Also check out:

GTD Series Part 6:Project Review through iThoughts Mind Mapping Software

Mind Mapping Software for iPhone:iThoughts Review

Introduction

This is part of a series where i talk about my GTD experience and  my setup.

Part 1 here talks about my plan and overview of my GTD system

Part 2 here talks about why i eventually chose iPod Touch 2G as my main to do list console

Part 3 here talks about why i choose Appigo ToDo for iPhone as my main task manager

Part 4 here talks about how to plan for big projects and smaller projects

Part 5 here talks about how to make use of Contexts, Tags to Execute your tasks

Part 6 here discuss about how you can review projects better using iThoughts mind mapping software

In today’s article i will share with  you how I normally go about planning for tasks, projects and sub-projects.

Where are we now?

Ok, so in Part 1 I have presented this workflow chart which is how i would illustrate my collection, planning, processing and execution model.

Today, I will talk a fair bit on project planning. I skipped the collection portion cause I think this is a more complex portion of GTD thus i would explain more on this first.

What Constitutes as Projects?

When you collected an idea, piece of information or a probem, you decide if it is actionable. If it is, the key to decide if it is a project or a simple actionable task is how much steps you need to execute to reach your successful outcome.

Remember, thinking about your successful outcome is important, just like defining clear and manageable goals, it keeps you on the right direction on what you are suppose to do.

Personally, that was what is described about projects, but to me there is no hard and fast rule. Why this is important is because you need to break a task down to actionable steps.

If it is too complicated, you do not know how to start the blardy task and you end up procrastinating on it.

So for task that is named:

“Get Son a new bicycle”

It can be a very simple actionable step, like go downstairs go to the nearest bike shop and buy the bike. That is, if you already know what you are looking for.  But most of the times it is not so simple.

That simple task normally consist of:

1. Ask Son what kind of bicycle he likes
2. Find out how much your family have to pay for the bike (budgeting)
3. Research on where to buy the cheapest bike on the internet
4. Give son a look at the bike see if he likes it
5. Find out what to look out for if it is the first time you are buying a bike
6. Go down and buy the bike
7. Wait for the bike to be delivered to you

So, you see, our task may not be that simple at all.

Another small problem that maybe isn’t that small

In life, most of the time don’t end up the way you wanted it to turn out. Take the example that in your work as an IT engineer, you are suppose to solve a problem on your IT system you are supporting.

So again, the simple task will go something like this in your normal to do list:

“Solve why the entries do not show up on the procurement page.”

It is a simple task, if you investigated and found that a bug in your source code will delete off these entries when the user view it. So Simple

Or it could be you investigated and turn out that the entries don’t come just from your system but goes to another system and then back to your system.

Then it becomes a bigger problem that could go something like

1. Find out from database whether the entries are there
2. If database entries are there, investigate at source codes to find out if there is a problem with the codes
3. If your codes do not have a problem, find out if the other system did give us the right entries to combine to ours
4. If they didn’t inform the engineers from the other system to investigate and get back to you
5. Engineer gets back to you say that the problem is related to them but they do not have the expertise to fix it nor the budget
6. Inform your boss about this and discuss with him
7. Set up a meeting between the manager of both projects
8. more shit stuff
9. more shit stuff

Yes, sometimes our lives can get quite bad in IT line. but it is a good illustration and our friends in other industry can attest that one small problem can remain small but most times they just get bigger and bigger and take longer and longer.

The above 2 serves as examples of why certain task, you have to break them down into projects with actionable steps. Had they remain as the original task entry, you will not see what needs to be done. I can list down the steps to this xamples well because i have experience with them, but sadly not everything is like that. Making them actionable and asking “What is the next action?” would enable you to kick start the engine to perform the work.

[Read the rest of this entry...]